Open APIs

 View Only
  • 1.  TMF668 PartnershipType API - Notification flow

    TM Forum Member
    Posted Aug 13, 2019 13:40
      |   view attached
    Dears,

     Currently as part of TMF Open API implementation in REST specification, we are developing each of those specification  and TMF 668 is one of them

     We had a question regarding the notification flow.   In the design/spec document we have seen about the hub register flow and  publish notification flow. However there was no   info on when those notification is created.

     Example let's assume that whenever new  Partnership is created then subscribers in the hub needs to be informed about new Partnership which has been created. 

     What we have done is that when the new partnership is created, we are  creating a new event entity with event type = create partnership and event body as the snapshot of the newly created  partnership.

    The event is then dispatched to messaging queue system ( Kafka,ActiveMQ) to process notification in asynchronously way.

     The JMS listener then listen to the event and query the registered subscribers from the hub repository and publish the message to the consumer who are registered for those type of notification.

     We could like to know if the approach taken is correct one ?? or do  we have any reference architecture  for implementation of notification flow use case ?

     Also do we need to persist the notification message generated for any fallout scenario in case ?

    The reference diagram created by  us is attached, could you please check with any available analyst and let us know comment on the same ?

    Attached is high level  design which we are trying to implement for integrating the PartnershipType  entity and Event entity.  

     Let me know if there is any reference architecture artifacts which can be referred.

    Regards,
    Sanu


     



    ------------------------------
    sanu Sasidharan
    Infosys
    ------------------------------


  • 2.  RE: TMF668 PartnershipType API - Notification flow

    TM Forum Member
    Posted Aug 14, 2019 11:05
    Hi Sanu
    To my unpracticed eye, this flow looks sensible. The expectation is that the API implementation will raise the relevant event as it happens, e.g. in your case when a partnership is created you raised this creation event.
    Also I like that you delegated the event handling to a separate component.
    But it would be ideal to reach out to the Open API chief architect @Pierre Gauthier to get his feedback on this.
    Hope it helps​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: TMF668 PartnershipType API - Notification flow

    TM Forum Member
    Posted Aug 16, 2019 01:10
    Thanks  @Jonathan Goldberg..

    Hi @pierre gauthier

    Could you please check on this and let us know if the implementation is right?

    The notification flow is common across most of the TMF specification. Currently  The hub registry and message consumer part we have  decoupled.
    Let me know in case you need any more details on our implementation. 

    FYI 
    @Dave Riches   ​​​​ @Rhea Chamberlain​  @Rani GS




    ------------------------------
    sanu Sasidharan
    Infosys
    ------------------------------



  • 4.  RE: TMF668 PartnershipType API - Notification flow

    TM Forum Member
    Posted May 01, 2020 08:28
    Hi @Jonathan Goldberg
    ​​​
    We are thinking about implementing same as above for 641 notification between COM and SOM. But one of the architects believes that it will break with the TMF specification, since the original notifier won't get the response that the client was able to understand the event, but instead just the acknowledgement that event is on queue and will be sent.

    Basically we  have SOM -> HUB -> KAFKA <- HUB -> COM, so SOM will not be notified synchronously if COM cannot receive the event. So question is: "Does that break the standard?"

    Kind regards
    Torben

    ------------------------------
    Torben Holmbæck
    TDC
    ------------------------------