Open APIs

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

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

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

Hi guys,

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.

Best regards,

------------------------------
Frederic Thise
Proximus SA
------------------------------

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.

Hi all,

   The current version of the DG (not published yet but available for members on the TMF Github) does state the following:

Note that a query expression may be supplied with the subscription registration. The query expression may be used to filter specific event types and/or any content of the event.

I agree with @Anders Frederiksen , the default behaviour is that if you don't specify a filtering condition but you do have an active subscription you will receive all the notifications that are being send by the producer. 

Thank you,
Florin

------------------------------
Florin Tene
CityFibre
------------------------------