Thanks for the update Jonathan - good point regarding business version versus history pattern, it explicitly adds a consideration that I was not explicitly thinking about. For now, I will resist the temptation to spend half the day whiteboarding stuff but its certainly an aspect to bear in mind.
Original Message:
Sent: Dec 10, 2023 02:41
From: Jonathan Goldberg
Subject: Product Order of type Modify - implications on the Product Inventory
Just to clarify on the history pattern (which is being reviewed internally by the Open API team, hopefully publishing in the not too distant future):
- The history pattern deals with revisions. It prescribes a dedicated, read-only, end-point to access all the revisions of an entity.
- The pattern is just that, a pattern. An implementation of an Open API needs to decide if to implement the history pattern, and if so how (presumably using extra persistent storage).
- The history pattern implies that revisions are created automatically for every change (the implementation must decide what is considered a "change", e.g. a PATCH operation invocation, an internal change due to event/time passing, etc.)
- The history pattern is not intended to replace explicit business versioning, such as we have in the catalog APIs. In business versioning, the consumer is in control and decides when a new version is to be created. It is entirely possible that a given catalog entity version might have multiple revisions.
Specifically for the Inventory APIs (product, service, resource), it's not clear (to me) what is more appropriate, using the history pattern or rather adding a explicit business versioning.
------------------------------
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: Dec 07, 2023 07:16
From: Julian Hodges
Subject: Product Order of type Modify - implications on the Product Inventory
I agree, there should be one active instance of the specific product inventory item. There should (IMO) be multiple instances / versions of the data that represent it over time - that could be concretely implemented in various ways of course.
------------------------------
Julian Hodges
TO BE VERIFIED
Original Message:
Sent: Dec 07, 2023 06:57
From: Sri-Jagadish (Jag) Baddukonda
Subject: Product Order of type Modify - implications on the Product Inventory
A new PI Instance should not be created and there are good reasons for it. This is a change on an existing asset / Product Inventory Instance and BW upgrade is just one possible change.
The Asset / Product Inventory is an instance of the Product Offering with it's structure. So the BW values that are to be changed should have been defined in the Product model first. One can maintain the historic version of the PI Instances for every customer but at given point of time, there will be only one active PI instance against the customer account for that Product Offering.(Assuming the customer has not purchased the same Product offering twice.)
These changes need to be done only via 637 which is called during the orchestration process for PATCH. The GET is used earlier in the process.
------------------------------
Sri-Jagadish (Jag) Baddukonda
Bell Canada
Original Message:
Sent: Dec 06, 2023 02:55
From: Axel Marc Schmitz
Subject: Product Order of type Modify - implications on the Product Inventory
Dear community,
When creating a product order of type Modify, - say i want to modify a characteristic (bandwidth f.ex) of an existing asset - with correspond change in price etc. What should be the behavior during fulfillment on the inventory. Since I am essentially changing the customer's product - I would assume that I would update the status of existing asset into "Pending Terminate" and create a new asset into "Pending Active". Then, once fulfillment completed, I would have a Terminated Product and an Active Product - allowing to see the history of the inventory item without having to reconcile against order history.
Simply patch'ing the asset feels wrong to me.
Does anyone have some thoughts on this?
Br
Axel
------------------------------
Axel Marc Schmitz
Capgemini
------------------------------