Open APIs

 View Only
Expand all | Collapse all

Event vs api

  • 1.  Event vs api

    TM Forum Member
    Posted Nov 26, 2020 16:19

     Is there guidance on whether resources should only be created by direct calls to a POST api or whether events could be used for that purpose?

    Using 622 as an example

    1. Is the productOrderCreateEvent simply a notification that the productOrder resource has been created? 

    2. Or can it be used as a directive, to trigger resource creation in an external system?

    Are we meant to look at the event and the api as interchangeable for certain operations (create, delete)  on a resource or are there differences in semantics that are important to acknowledge?



    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------


  • 2.  RE: Event vs api

    TM Forum Member
    Posted Nov 26, 2020 16:30
    In a related question, can two systems have their own representation of the same resource? Where both systems implement the same TMF specification? 
    If we look at 622, the product Order is a resource that is relevant to both customer OM as well as buying. What is the thinking about how these two systems collaborate on the same resource? Does each provide an implementation with their own "view" of the resource?

    Tagging @Ludovic Robert as I know this is your area of expertise.​

    thanks for your thoughts,

    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 3.  RE: Event vs api

    Posted Nov 27, 2020 06:15
    Hi Lynn!

    I think you can do whatever you want and what is helpfull for you business. From my point of view the creation, modification oder deletion of the productOrder resource is done by direct calls. The events keep the consumer of the api informed about the status and provide data to other systems which need this. 

    For example: In you CRM-System you want to have an overview of all productOrders. So you can subscribe to you Order Management Systems and use the events to create a view for the Sales and CC Representatives which order a certain customer have and in which status they are. In you CRM-System the action of consuming the event could lead to an own representation of the resource (or maybe it's only a part of it with a link to the Order Management System).

    So I think both of our example are correct. But the for the System which is responsible of orchestrating the order process and which is the master of the order itself, the direct calls are way. 

    And to your second question. Could you give a little bit more details about the use case? What to you mean with "buying". Do you talk about that you have to order a product by another CSP because the product you sold is build from products another CSP provide to you?

    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------



  • 4.  RE: Event vs api

    TM Forum Member
    Posted Nov 27, 2020 13:23
    Thanks Daniel - your interpretation matches mine but I wanted to establish whether the other option (using events to trigger) was possible or not.

    If we take a scenario like you describe where another system listens for the create event, and creates its own representation of the product order resource, what does that system say about their support for TMF 622? there is a difference between participating in a spec by listening to events and actually implementing the apis. What does that system tell customers in terms of their support for TMF 622, or other specs they may be a participant in?

    My second question really is captured in this scenario where two systems collaborate on a resource.

    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 5.  RE: Event vs api

    TM Forum Member
    Posted Nov 29, 2020 09:18
    Hi Lynn, Daniel

    From a formal perspective, a software unit that consuming events (e.g. TMF622 order entity events) is not considered as implementing the API itself. The fact that some software listens to an ProductOrderCreate event (for example) doesn't mean that the software will now create a ProductOrder - it might be listening to the event for other purposes (e.g. to transform into a ServiceOrder for possible future provisioning).

    But you have raised an interesting discussion here, especially as regarding entity ownership. We can indeed conceive of multiple software systems that implement the same API to model various phases in an entity life-cycle. Consider for example a payment. We might (perhaps) have a software system within the Telco domain that takes details of a payment, using the payment management API, but then this system might use the very same API to pass the payment on to a payment gateway. So who "owns" the payment? And we can imagine in the Service domain multiple systems that implement the Service Order API at different levels of abstraction/decomposition of the service order.

    So I don't think there is a simple answer, but maybe other colleagues on the community have different opinions.

    Anyway hope it helps.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 6.  RE: Event vs api

    TM Forum Member
    Posted Nov 30, 2020 14:58
    I am aligned to Jonathan's view that the component supposed to action on the API procedures should implement the API. I also think that the same component should own the possible outcome from the action as well. 
    This model of multiple systems collaborate on the same resource resource may work well in a well-controlled environment, where there is clear ownership of data objects and boundary well set. Such controlled environments will have a controlled exposure of its services and will be able to manage authorisation, handle race conditions especially during multiple systems trying to change the object at the same time etc. and will have a common roadmap for API & systems evolution. Outside this controlled environment, I believe it will create highly complex scenarios.


    ------------------------------
    Varun Nair
    Telstra Corporation
    Note: This is an opinion based on my research and not an official TMF response.
    ------------------------------



  • 7.  RE: Event vs api

    Posted Nov 30, 2020 16:02
    Thanks for the discussion. It was really helpful. https://solarpanelcostprice.com.au/solar-inverters/

    ------------------------------
    Alex Johnson
    TO BE VERIFIED
    ------------------------------



  • 8.  RE: Event vs api

    Posted Nov 30, 2020 16:02
    Thanks for the discussion. It was really helpful.

    ------------------------------
    Alex Johnson
    TO BE VERIFIED
    ------------------------------



  • 9.  RE: Event vs api

    Posted Dec 01, 2020 00:15
    From a formal perspective, a software unit that consuming events (e.g. TMF622 order entity events) is not considered as implementing the API itself. The fact that some software listens to an ProductOrderCreate event (for example) doesn't mean that the software will now create a ProductOrder - it might be listening to the event for other purposes (e.g. to transform into a ServiceOrder for possible future provisioning).

    Jonathan I agree. My example was meant as this "other purpose". Like you want to have a minimal copy of the order in your CRM to increase user experience (load time for example), but the responsible component for managing and modifying the order itself is still the component who implements the API. However, you could think to implement the flow behind the api in different ways. You could use a distributed solution with microservices and using pattern like the saga pattern. But I don't think that it is sufficient here only working with the events defined in the TMF OrderAPIs. And this is no recommendation to do so, just an example. 

    Lynn, you question about conformance seems important to you. What is the reason behind this question? But let's have a second look at my CRM-Example and extend it with an argumentation:

    *Dear Customer: If we use the TMF API 622 and you implement a listener for you CRM this will increase the non-functional requirement of changeability. Because now if you replace the components behind the TMF 622 but keep the TMF 622, you don't have to make any changes in your CRM. If you instead would use a vendor specific API, this replacement cause you a lot more effort. 






    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------



  • 10.  RE: Event vs api

    TM Forum Member
    Posted Dec 01, 2020 12:47

    The fact that some software listens to an ProductOrderCreate event (for example) doesn't mean that the software will now create a ProductOrder - it might be listening to the event for other purposes (e.g. to transform into a ServiceOrder for possible future provisioning).


    It does makes sense that a system listening to ProductOrderCreate event may create an internal resource in response. But using the service order example provides a slightly different use case in that there is a TMF spec for the service order. Is there any change to that pattern when there is TMF spec for the resource the other system will create?

    Does SOM listen for the ProductOrderCreate event to trigger creation of it's service order (and leave it in a not started or waiting state) or does it expect that when a product order is ready to be provisioned, that the upstream system sends a POST /serviceOrder to SOM? I would have thought the latter but I suspect the answer is "whatever works for your organization based on who does the transformation" but I wonder what others are doing generally speaking for this downstream cascading of orders that have a TMF spec. We could imagine a layer below SOM than handles the resource order.

    Lynn



    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 11.  RE: Event vs api

    TM Forum Member
    Posted Dec 01, 2020 12:58
    Hi Lynn

    Perhaps my example was inappropriate, since it could be expected that an implementation of Product Order (an order handling component, say) could invoke the Service Order API directly against a SOM, as you point out, rather than relying on events.

    But this does not change the general point I was trying to make - a software unit that listens to events from a TMF Open API and acts on them does not mean that the software unit conforms to that Open API. Currently, conformance is measured only against the exposed API operations, not by downstream event processing.

    Other uses events could include:
    • replication to data warehouse/data lake
    • SLA measurements
    • reconciliation and data quality measurements
    Thanks for engaging in this interesting discussion :) .

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 12.  RE: Event vs api

    TM Forum Member
    Posted Dec 01, 2020 14:13
    Thank you Jonathan - this has been very helpful!!

    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------