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.
------------------------------
Original Message:
Sent: Aug 25, 2021 04:25
From: Alexander Roock
Subject: TMF653 Service Test Management - client has to respond with EventSubscription to incoming events - Why?
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
------------------------------