Open APIs

Expand all | Collapse all

622 Product Order

  • 1.  622 Product Order

    TM Forum Member
    Posted 12 days ago

    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 12 days ago
    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 11 days ago
    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 11 days ago
    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.
    ------------------------------