as the query part of the Hub in each API or TMF688 is similar to the "filtering" part of the list operations (filter, fields, etc.), the default behaviour should be to handle it that way.
It means, for me, that if you don't specify event types in your query, you expect to receive all event types that may be sent at any point in time.
Original Message:
Sent: Mar 21, 2023 09:11
From: Anita Rawat
Subject: TMF622 Notification mechanism
Hi Jonathan,
Thanks for sharing your opinion on this query and I hope via the JIRA ticket more clarifications would come on this topic.
As of now we are planning to support by maintaining a dedicated list as supplier at our side so that we do not publish events towards the buyer that they have not asked for. This would also avoid unnecessary event flows towards the buyer. Later when the Buyer wants or requests to have another kind of event/notification then that could be added in the list that supplier is maintaining to enable that event flow as well.
------------------------------
Anita Rawat
Proximus SA
Original Message:
Sent: Mar 21, 2023 08:31
From: Jonathan Goldberg
Subject: TMF622 Notification mechanism
Hi Anita
This is an excellent suggestion - I personally am not aware that it is addressed in the design guidelines or indeed anywhere. So I plan to open a JIRA issue to get the Open API team to clarify its position.
Let's suppose that if you don't specify a notification type you'll get all notification types, including new ones that might appear in the future. This means that the notification consumer will receive events that it was not necessarily prepared to receive, and so will have to be coded in a defensive/resilient way so as to ignore notifications that it doesn't understand. Which of course is good coding practice anyway.
On the other hand, if not specifying a notification type means getting only the known types, it means that the provider needs to store the explicit list of all current types against this consumer's registration.
In short, I don't know which is better.
------------------------------
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: Mar 20, 2023 11:21
From: Anita Rawat
Subject: TMF622 Notification mechanism
For TMF622, When the buyer does the registration via the POST /hub and does not indicate the event type in the 'query' for which the registration is required
Does this mean that the buyer wants to register for all the notifications available in that TMF(example all 8 kind of notifications in TMF622 if one
is using POST /hub of TMF622)
Or does it mean that the Buyer will be registered to only events that are supported by that TMF by the receiver/seller.
For example the seller only supports
'productOrderStateChangeEvent' in 2023 but later in 2024 the seller starts supporting 'productOrderAttributeValueChangeEvent' also. In this case does the buyer have to come again with the
post /hub request again towards the seller or should it be automatically handled by the seller as the buyer had already requested to register for notifications in 2023 without indicating the event types which meant the buyer needs all kind of event notifications?
POST /api/hub
Accept: application/json
{"callback": "http://in.listener.com"}
Please suggest.
------------------------------
Anita Rawat
Proximus SA
------------------------------