Open APIs

Expand all | Collapse all

TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

  • 1.  TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 25, 2021 09:15
    According to the swagger definition of TMF653 Service Test Management (I checked v3.0.0, 4.0.0, and 4.1.0), a consumer must answer the incoming notifications (POST to consumer interface "listener / xyzEvent") with an EventSubscription entity.
    I don't understand the point! What is it good for?

    The same entity is returned by the provider during the event registration by the consumer (POST to provider interface "/ hub"), which makes sense.
    Maybe it's a copy / paste mistake?

    ------------------------------
    Alexander Roock
    T-Systems International Services GmbH
    ------------------------------


  • 2.  RE: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 25, 2021 14:29
    Hi Alexander

    APIs are implemented by some software component. It is expected that the component will raise events as a result of "things happening", e.g. Service Test status changed (to complete, to failed, whatever)

    If some system (could be the consumer of the API or some completely different system) wants to know what is happening with the service test, it's natural that the system would subscribe to the events. The alternative, less healthy, would be that the system would poll (GET) continuously on the Service Test and examine the status.

    The Open APIs were originally designed with a point-to-point event subscription model (using the Hub), and this is what you see in the API swagger. More recently, a general Event API has been published (draft, beta) to abstract message publish and subscribe over a message bus (Rabbit, Kafka, etc.).

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



  • 3.  RE: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 26, 2021 02:25
    Hi Jonathan,

    thanks for your reply.

    Yes I understand the idea of this publish/subscriber interface for handling events.
    And I understand that the interested systems have to subscribe (using the hub) to the events first.

    But I still don't understand why the event listeners have to answer every incoming event with a subscription entity (I marked it red in the attached picture).
    The subscription entity is important during subscription phase but not for publishing the events afterwards.

    This information is useless for the publisher (events should be a fire and forget mechanism).

    So maybe I missed a point so that it all makes sense but I also did not find any explanation for that in the Word/PDF documentation.

    Thank you in advance.

    P.S.: Thanks for the information on the general Event API - I have to take a closer look at that.
    Why do I have to answer to events with more than just a 201?


    ------------------------------
    Alexander Roock
    T-Systems International Services GmbH
    ------------------------------



  • 4.  RE: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 26, 2021 03:52
    Suggest you take a look at the Design Guidelines Part 1 chapter 10.

    But basically the hub mechanism is using synchronous REST API to post the event, so it is natural for the provider to expect an HTTP response. Since the hub is point-to-point, the response will have to come from the subscriber to the message. And if you have multiple subscribers, you'll post to (and get a response from) each subscriber separately.

    When you use the new Event API to post event, you will still get a synchronous response, but this time from the message bus. Your downstream message subscribers will of course behave completely asynchronously, as expected.

    ------------------------------
    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: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 26, 2021 12:09
    I followed your suggestion and took a look at the guidelines again.
    In chapter "10.3 Publishing Events" it says: "Returns HTTP/1.1 status code 201 Created". So no body-part is described for the response-message to an event.

    So I suspect that it is actually a bug in the TMF653 swagger definition.
    Otherwise somebody would have to tell me why the publisher could be interested in "id", "callback", or "query" parameters at that time.

    Thanks again!

    ------------------------------
    Alexander Roock
    T-Systems International Services GmbH
    ------------------------------



  • 6.  RE: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?

    TM Forum Member
    Posted Aug 27, 2021 09:04
    Hi Alexander,

    The publishers use another enpoint for publishing events than the subscribers.

    Publishers publish to an /xxx/event enpoint. That endpoint should repond with 201 created status code. In our implmentation we provide the Event back with eventId and eventTime filled in. This provides improved consistency in (transition) architectures where multiple systems can create the same Notification type.

    Subscribers subscribe  to a /xxx/hub endpoint with a callback and a query. That endpoint responds with 201 created status code, Here again the response body should have the id generated to avoid clashes in id generation.

    The /xxx/listener endpoint describe in most TMF documents refers to the behaviour of the callback that was registered on the hub. For that endpoint the body returned is of no use for the event layer. the 201 Created only serves as acknowledgment of the message received.

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