Open APIs

 View Only
  • 1.  Events/notifications for recovery scenarios

    TM Forum Member
    Posted Jan 04, 2022 02:55

    Hi all,


    We are using different TMF APIs and currently investigating various recovery scenarios when the "server side" is not available either for planned maintenance or as a result of an outage.

    Are there any generic API patterns to handle it, letting the consumer know about communication events? A possible way may be to use generic notifications having logic of "losing communication"(applicable for a planned event) or "communication restored". As the TMF 688 Event API is already a generic mechanism, maybe some generic events can be defined?

    Of course, this can always be implemented at the application layer, but may be more efficient as an API pattern.

    Any thoughts on this?


    Best Regards,

    Yuval Stein





    PLEASE NOTE: The information contained in this message is privileged and confidential, and is intended only for the use of the individual to whom it is addressed and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please contact sender. Thank you.

  • 2.  RE: Events/notifications for recovery scenarios

    TM Forum Member
    Posted Jan 05, 2022 01:40
    Many(*) of the Open APIs include a lastUpdate attribute which should be set to the current time of the last modification. Recovering from a communication loss can then be accomplished by querying on that value:

    GET /productCatalogManagement/v4/productOffering?

    (*) IMHO all resources should include this attribute.

    Vance Shipley

  • 3.  RE: Events/notifications for recovery scenarios

    TM Forum Member
    Posted Jan 07, 2022 12:00
    Hi Yuval,

    The solution to this depends on the capabilities of the middleware used for the API infrastructure.
    If this middleware supports storage of messages, it can respond with 202 Accepted to indicate that the message is stored but not yet transmitted to the server application.
    The stored messages can then be played to the server when it comes back online.

    Best Regards

    Koen Peeters