Open APIs

 View Only
  • 1.  622 Product Order

    TM Forum Member
    Posted Jan 05, 2021 14:02

    The ProductOrderStateChangeEventPayload contains only ProductOrder which is optional. However, the ProductOrderState field is inside the ProductOrder so in essence the event payload must include ProductOrder.

    ProductOrderitems are required in the ProductOrder, so does this mean that for an order that contains hundreds or thousands of line items, I have to include all of them in every state change event payload that is sent out?

    Could someone please point out where I'm mistaken, or else the rationale for this?

    Help is appreciated,



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


  • 2.  RE: 622 Product Order

    TM Forum Member
    Posted Jan 06, 2021 12:23
    Hello Lynn,

    For my perspective the event payload has not to include the complete productOrder -it could- but it is not mandated.

    The attribute(s) to be present in the event payload could be defined in the hub.

    If for example in the POST HUB you define :

    {"callback": http://in.listener.com,
    "query":"eventType = ProductOrderStateChangeNotification&fields=id,href,state"
    }
    ​


    When a productOrder has a state change, an event will be triggered to the listener and in the event payload you'll have only the productOrder id, href and the state.

    Hope it helps

    Ludovic



    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: 622 Product Order

    TM Forum Member
    Posted Jan 06, 2021 15:07
    Hi Lynn,

    I believe it makes sense to always include the entire object in events, particularly if you intend to have a micro-service based architecture.
    In such an architecture the xxxStateChangedEvent is intended as a workflow hook. Some micro-service will filter (using the hub) for a specific lifecycleStatus to trigger some action.
    If the event does not include the entire payload you will quickly find out that any workflow starts with doing a GET to lookup the entire productOrder.
    This extra GET can  be eliminated by having the complete payload from the beginning.

    Any savings you think to make by not including the full message are not worth it, once you realise that you are actually creating extra roundtrips between micro-services. The impact on the performance of the micro-services by not having the full payload will be very negative.


    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------



  • 4.  RE: 622 Product Order

    TM Forum Member
    Posted Jan 07, 2021 01:22
    Thanks Ludovic and Koen for these insights. I tend to agree with Koen, placing the entity contents in the event message means that downstream systems can get all the data without the need to go back to the owning system. Reduces fragility (less moving parts).
    There is a rider to this, if the entity is very large, and downstream systems don't need it all, you could use a different pattern, having a very lean event and then providing a dedicated GET that returns only the required data. In the Open API, this dedicated GET can be achieved using the fields directive, and with the V4 design guidelines, also with JSON Path (but only if the API implemented JSON path).
    Just to clarify Ludovic's point, it refers to the older, hub-based point-to-point notification pattern. It's not feasible when using a message bus (such as Kafka or Rabbit) wrapped with the Event API.
    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.
    ------------------------------



  • 5.  RE: 622 Product Order

    TM Forum Member
    Posted Feb 09, 2021 12:08
    Hi Jonathan,

    Regarding the latest answer in this thread, it's stated:
    (..)
    Just to clarify Ludovic's point, it refers to the older, hub-based point-to-point notification pattern.
    It's not feasible when using a message bus (such as Kafka or Rabbit) wrapped with the Event API.
    (..)

    This brought me two doubts:
    1)  Where can we find additional information around this TMF-message bus (such as Kafka) interaction?
    2) Does the "/hub/" endpoint presented on specs (such as TMF620, TMF630) will be deprecated?

    Regards,


    ------------------------------
    Marcos Donato da Silva
    Ericsson Inc.
    ------------------------------



  • 6.  RE: 622 Product Order

    TM Forum Member
    Posted Feb 10, 2021 11:17
    The Event API is published for early adoption here, unfortunately at this time only the swagger is available. 
    I think that the intention is to deprecate the hub endpoint, but I don't know when this will happen. It certainly cannot happen until the Event API is fully published.

    ------------------------------
    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.
    ------------------------------



  • 7.  RE: 622 Product Order

    TM Forum Member
    Posted Feb 11, 2021 14:46
    Hi Jonathan,

    I don't believe that it is the intention of the Event API to replace the HUB. It defines a model to define a topic and add to this both the endpoint for publishing events and a hub endpoint that works exactly as described in the other TMF APIs.

    I agree that once this API is published, the hub mechanism doesn't need to be explained in each API document separately. It is however not deprecating the functionality.

    Regards

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------