TM Forum Community

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id. 

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION
------------------------------

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD
------------------------------

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign
------------------------------

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD
------------------------------

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Are there any further thoughts on this?​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD
------------------------------

Original Message:
Sent: Oct 23, 2022 18:31
From: Kanika Aggarwal
Subject: Listener and hub Queries

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

I slightly differ with Jonathan & Sergey.

In My View though the Originating system (in this specific example the Retail POS system) is the primary party interested in the state/status changes in the order, we should not limit the notifications from the centralized order Management system just to the originating system. The Order Management System can generate notifications that could be consumed by any system that registers interest in the event. The way the consuming system of the notification acts upon the the notification may depend on whether the consuming system is the originator of the order or just another party interested in the order. The Digital Engagement channel could use this notification for presenting the ordeder status on the dashboard when the customer logs in next time or any similar use cases

On Sergey's point, If we solely  rely on APIs to query on status (for example order status in this case) we may be compromising on the customer experience. In this example if the digital engagement platform need localized intelligence to present the relevant information to the customer when the logs in and the notification will help in building that intelligence and context. Once we have the context the platform can always call the golden source and pull in the information to be presented. 

This is my thought, please let me know if you differ

Thanks
Ajith


------------------------------
Ajith Lenin
Verizon Communications
------------------------------

Original Message:
Sent: Nov 15, 2022 17:36
From: Kanika Aggarwal
Subject: Listener and hub Queries

Are there any further thoughts on this?​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 23, 2022 18:31
From: Kanika Aggarwal
Subject: Listener and hub Queries

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

I slightly differ with both Jonathan and Sergey

Agree with Jonathan that the system that originated the order is the primary party interested in the status notifications, but there is value add in other systems receiving the notifcations as well.  For example the Digital Engagement platform will need the updates to show the order status when the customer logs in next time. In  my view The centralized  order management system should generate the notifications and the interested consumers and can consume the notifications and take actions based on their need.

On Sergey's point on pulling the information by calling an API., Information can be pulled using APIs but systems need localized intelligence and context to make decisions and the notifications will help in building that context. For example in this case, The the digital engagement platform can make the decision on whether to present order status or not based on the notifications received when the customer logs in next time. It can rely on API calls for information but the decisioning have to be based on localized intelligence.

These are my thoughts, please let me you if you differ

Thanks

------------------------------
Ajith Lenin
Verizon Communications
------------------------------

Original Message:
Sent: Nov 15, 2022 17:36
From: Kanika Aggarwal
Subject: Listener and hub Queries

Are there any further thoughts on this?​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 23, 2022 18:31
From: Kanika Aggarwal
Subject: Listener and hub Queries

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Thanks Ajith for your input.
Since the original request in this thread was asking about the hub and listener pattern, I replied in the same vein. You are absolutely correct that in a distributed deployment there could be many potential consumers of events, and in this case it would be more appropriate to use the Event Management API (as I mentioned in one of my replies above).

------------------------------
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: Nov 21, 2022 04:40
From: Ajith Lenin
Subject: Listener and hub Queries

I slightly differ with both Jonathan and Sergey

Agree with Jonathan that the system that originated the order is the primary party interested in the status notifications, but there is value add in other systems receiving the notifcations as well.  For example the Digital Engagement platform will need the updates to show the order status when the customer logs in next time. In  my view The centralized  order management system should generate the notifications and the interested consumers and can consume the notifications and take actions based on their need.

On Sergey's point on pulling the information by calling an API., Information can be pulled using APIs but systems need localized intelligence and context to make decisions and the notifications will help in building that context. For example in this case, The the digital engagement platform can make the decision on whether to present order status or not based on the notifications received when the customer logs in next time. It can rely on API calls for information but the decisioning have to be based on localized intelligence.

These are my thoughts, please let me you if you differ

Thanks

------------------------------
Ajith Lenin
Verizon Communications

Original Message:
Sent: Nov 15, 2022 17:36
From: Kanika Aggarwal
Subject: Listener and hub Queries

Are there any further thoughts on this?​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 23, 2022 18:31
From: Kanika Aggarwal
Subject: Listener and hub Queries

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

Thanks Jonathan, I completely agree

------------------------------
Ajith Lenin
Verizon Communications
------------------------------

Original Message:
Sent: Nov 21, 2022 05:17
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Ajith for your input.
Since the original request in this thread was asking about the hub and listener pattern, I replied in the same vein. You are absolutely correct that in a distributed deployment there could be many potential consumers of events, and in this case it would be more appropriate to use the Event Management API (as I mentioned in one of my replies above).

------------------------------
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: Nov 21, 2022 04:40
From: Ajith Lenin
Subject: Listener and hub Queries

I slightly differ with both Jonathan and Sergey

Agree with Jonathan that the system that originated the order is the primary party interested in the status notifications, but there is value add in other systems receiving the notifcations as well.  For example the Digital Engagement platform will need the updates to show the order status when the customer logs in next time. In  my view The centralized  order management system should generate the notifications and the interested consumers and can consume the notifications and take actions based on their need.

On Sergey's point on pulling the information by calling an API., Information can be pulled using APIs but systems need localized intelligence and context to make decisions and the notifications will help in building that context. For example in this case, The the digital engagement platform can make the decision on whether to present order status or not based on the notifications received when the customer logs in next time. It can rely on API calls for information but the decisioning have to be based on localized intelligence.

These are my thoughts, please let me you if you differ

Thanks

------------------------------
Ajith Lenin
Verizon Communications

Original Message:
Sent: Nov 15, 2022 17:36
From: Kanika Aggarwal
Subject: Listener and hub Queries

Are there any further thoughts on this?​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 23, 2022 18:31
From: Kanika Aggarwal
Subject: Listener and hub Queries

Thanks @Jonathan Goldberg and @Sergey Varnavsky. These appear to be two strikingly different approaches.

In one, it is expected of provider to be aware of consumer's identity and it's ability to match the events to the originating system.
While in second approach it is expected of consumer to be aware of orders it created and then potentially drop the events it is not interested in while provider publishes all the events to all the consumers/originating systems.

TMF641 v4.1 suggests that externalId is an ID given by the consumer to facilitate searches and doesn't explicitly say anything about how it can be used in notifications. Does it mean that it is left to the interpretation by the standard for provider's implementation to follow either of the two approaches?
​​

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: Oct 21, 2022 03:03
From: Sergey Varnavsky
Subject: Listener and hub Queries

Dear Jonathan,

Thanks for a good point raised, and thorough explanation provided.

There could be another view on this problem - 622 response from the central order management system provides a unique order ID (preferably - globally unique, but at least in scope of OMS), and calling system (ePos or any other system that captures the order) should store this ID along with its own order identifier.
Thus any external system may query an order status at any time, and be sure that exactly desired order status is reported - imagine if external systems don't care about their order ID global uniqueness? How many orders may OMS find by such non-unique external ID?

Getting back to the topic-stating question - I assume that notification provider should send events with identifiers that provider owns, not with consumer's external IDs.

Have a great day!

------------------------------
Sergey Varnavsky
Nexign

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------

hi Jonathan,
I have a follow up question on this. When we are trying to create the hub, the hub resource has a callback url 

{ "callback": "http://www.tmforum.org/aListener", "id": "5880", "query": "event.alarm.alarmType=QualityOfServiceAlarm", "href": "//hub/ 5880" }

Is this callback url the url of the listener who has registered to this hub, if so then what is the callback url that we are providing when we are registering a listener. My understanding on this process is as below
1) A topic is created by the publisher or with the event bus
2) a Hub is registered for the given topic for the subscribe to subscribe to that given topic via hub
3) A listener then registers to that hub with the endpoint (is this endpoint wherein a listener post their callback url provided when we do a get of the hub as a callback url)

------------------------------
Shubham Mittal
ServiceNow, Inc.
------------------------------

Original Message:
Sent: Oct 20, 2022 03:53
From: Jonathan Goldberg
Subject: Listener and hub Queries

Hi Kanika

A great question. Let's consider (for example) multiple digital commerce systems (retail PoS, self-service) feeding product orders via TMF622 POST into a central order capture system owned by the telco. Then presumably the self-service system would not want to receive notifications on orders initiated by the PoS system.
So it would be the responsibility of the central order capture system to send hub responses to the originating system. This requires that the product order storage should include the identity of the originating system. We have a pattern for this called ExternalIdentifier, but it has not yet been included in ProductOrder.

More generally, the software system callback endpoint should be directly relateable to the owner attribute in ExternalIdentifier, so that the system raising the events can match the event to the originating system.

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: Oct 12, 2022 05:50
From: Kanika Aggarwal
Subject: Listener and hub Queries

Hi @Jonathan Goldberg,

Regarding "The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems."

Is it possible to support for callback endpoint to receive events only for the entities it created/updated? Does API support that?​

Thanks
Kanika

------------------------------
Kanika Aggarwal
VOCUS PTY LTD

Original Message:
Sent: May 17, 2022 03:26
From: Jonathan Goldberg
Subject: Listener and hub Queries

Thanks Andreas for your answer. I'll provide some additional info:
The Open API design pattern prescribes events that are raised as part of an API implementation, typically as a result of operation invocation (e.g. entityxxxxcreated, entityyyyystatuschanged, etc.). We have two paradigms for handling these events:

• hub and listener - This is a point-to-point paradigm. The software system that raises events (typically an implementation of an API) publishes a hub end-point. Software systems that want to subscribe to the events register at the hub, giving a callback endpoint as part of the registration. The event raising software system will invoke each callback endpoint to communicate the events to the subscribing systems.
• event queue - This is a distributed paradigm. TMF688 (event management) allows event providers to raise events, and event consumers to subscribe to events, wrapping queue or messaging systems (Kafka, Rabbit, 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: May 17, 2022 01:44
From: Andreas Schlueter
Subject: Listener and hub Queries

Hi Shivan,
the listener is a service (Observer in GoF pattern) provided  by another system to be notified by the SOM service. It is registered at the hub (Observable) to be invoked when a notification is due. The id is the id that the hub assigns to the listener and which can be used e.g. to de-register the listener later.

Regards,
Andreas

------------------------------
Andreas Schlueter
NTT DATA CORPORATION

Original Message:
Sent: May 16, 2022 09:18
From: Shivam Chauhan
Subject: Listener and hub Queries

I am pretty new with the TMF 641 APIs.

I follow the tmf swagger.

1 - What is the difference between listener api and hub api.
2- Does the id present in response of listener is same as hub api response id.

I attached the response.
#General

------------------------------
Shivam Chauhan
Zensar
------------------------------