Hello Peter,
Yes you're right about the implementation of the server on the listener side.
About the events themselves it is true that they are generic (the entity is passed). The subscriber can pick only a subset of the attributes when it subscribes via the HUB (specifying the expected attributes).
We are working on this event topic for the next release.
For example we will leverage the json-patch grammar in the informationRequired event.
To give you an couple of examples on the Quote API (but the pattern will be the same)
Information required example:
{
"correlationId": "qs1-k33",
"description": "QuoteInformationRequiredEvent illustration",
"domain": "Commercial",
"eventId": "966",
"eventTime": "2021-09-27T07:43:59.059Z",
"eventType": "QuoteInformationRequiredEvent",
"priority": "1",
"timeOcurred": "2021-09-27T07:43:59.059Z",
"title": "QuoteInformationRequiredEvent",
"event": {
"quote": {
"id": "5252",
"href": "https://host:port/quoteManagement/v4/quote/5252",
"@type": "EntityRef",
"@referredtype": "Quote"
},
"informationRequired": {
"informationRequiredPath": [
{
"op": "add",
"path": "agreement.id"
},
{
"op": "add",
"path": "contactMedium"
}
]
}
},
"@baseType": "Event",
"@type": "QuoteInformationRequiredEvent"
}
State change example:
{
"correlationId": "333-fd6",
"description": "QuoteStateChangeEvent illustration",
"domain": "Commercial",
"eventId": "569",
"eventTime": "2021-09-27T07:43:59.059Z",
"eventType": "QuoteStateChangeEvent",
"priority": "1",
"timeOcurred": "2021-09-27T07:43:59.059Z",
"title": "QuoteStateChangeEvent",
"event": {
"quote": {
"id": "9693",
"href": "https://host:port/quoteManagement/v4/quote/9693",
"@type": "Quote",
"state": "approved",
"itemStateChange": [
{
"itemId": "1",
"state": "approved"
},
{
"itemId": "2",
"state": "approved"
}
]
}
},
"@baseType": "Event",
"@type": "QuoteStateChangeEvent"
}
Hope it helps,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Feb 01, 2022 09:54
From: Peter Levart
Subject: TMF620 basics: notification event types
Hi,
I'm exploring the TMF620 API v4.1.0 and have a few questions I would like to ask. In the Swagger API definition there is a part that is tagged with "notification listeners (client side)" with paths that start with "/listener/...". I'm assuming the server-side of this part of API has to be implemented by the clients of the TMF620 API and is meant to be a "sink" for events emitted by the TMF 620 service. There are several different events that can be posted for each "entity". For example, for ProductOffering there are the following events:
ProductOfferingCreateEvent
ProductOfferingAttributeValueChangeEvent
ProductOfferingStateChangeEvent
ProductOfferingDeleteEvent
Those events don't differ in structure much (if at all). So I'm asking about the meaning of the different events if each of them may carry the same payload - the ProductOffering. I can imagine the meaning of ProductOfferingCreateEvent and ProductOfferingDeleteEvent, but what is the difference between ProductOfferingAttributeValueChangeEvent and ProductOfferingStateChangeEvent ? Are there any constraints about what one can or can't change vs. the other? Any recommendations?
Thanks,
Peter
------------------------------
Peter Levart
Marand Software
------------------------------