Open APIs

Hey team, (Not sure why the previous post is not uploaded.)

Per TMF637 Product Inventory (PI), we have several questions about what the exact payload of these events and when these event(s) will be published.

Let's say, there are several cases which might trigger ProductAttributeValueChangeEvent and ProductStateChangeEvent.

Case 1:

For a PATCH request with `status` field ONLY, the ProductStateChangeEvent should be published. 

1. What is the exact payload of this event? With changed `status` field ONLY? When we say "changed", it means the field's value is different from db before Patch.

Case 2:

For a PATCH request with any other fields except `status` field, the ProductAttributeValueChangeEvent should be published. 

1. What is the exact payload of this event? With changed fields ONLY? For example, if the patch request for `name` and `description`, the event should involve these 2 fields ONLY.

Case 3:

For a PATCH request with any other fields along with `status` field,

1. Which event should be published? Or both of them should be published?
2. What is the exact payload of this event(s)?

------------------------------
Shangfeng Liu
LotusFlare
------------------------------

Hi Shangfeng

Firstly, please note that the first time anyone posts in this community, their post is subject to approval - that's probably why you didn't see the post immediately. After you get approved, you can continue to post without restriction :) .

Regarding your query, the authoritative place to go is the design guidelines (TMF630, or the new in-progress DG for version 5 TMF763). My understanding from creating examples for API specs is:

• The event payload for status/state change is minimal - @type, id, href, and the actual status property (status, state, lifecycleState, or whatever it is called in the specific entity)
• The event payload for other changes is the smallest possible representation that you can make for the change in patch merge format, together with @type, id, href
• If the change was to status and to other properties, then both events should be published.

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

Hi Shangfeng,

Here my response is about TMF688.

On our side we took a different approach: whatever the event to POST (through createEvent on the topic) is, the full payload of the resource included (service, resource, product, etc.) is always provided. For example, for a ServiceStateChangeEvent, the full service with full supportingResource and serviceRelationship is posted.

We do that because we expect the field selection to occur at Hub level. In the TMF630 part 1 (V4) section 10.4 Content type filtering, you can see that in the query part of the Hub, you can not only specify a filter but also the fields element (for field selection). Field selection can only be performed if the full payload is passed to TMF688.

It can also have a big advantage at performance level because when a listener receives the event, if the full payload is not passed, he probably has to perform a GET operation to retrieve the full resource (in my case the full service). If all listeners for the same event do that, then it will have a performance hit on the system which is not the case if the full payload is passed at first. The dispatching of the event to the registered listeners will apply the field selection defined for each listener's Hub.

Best regards,

Fred

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