Hi
I'll try to provide some clarity, apologies in advance if instead I muddy things up!
First and foremost, please remember that Open APIs are just that, APIs. They don't prescribe a specific implementation, of storage or functionality.
So now let's consider the APIs TMF638, TMF640, and TMF641:
- TMF638 - Service Inventory - allows maintenance of a persistent storage of Services.
- TMF640 - Service Activation/Configuration - has exactly the same model and operations as TMF638, but is intended to operate against the network itself.
- TMF641 - Service Order - manages the process of provisioning of services - the service order model embeds the Service model (using the reforvalue pattern)
We can imagine that an implementation of TMF641 (a SOM system, for example) will internally invoke both TMF640 and TMF638, in order to ensure that the inventory is updated with what was done on the actual network.
Regarding the storage of Service while being ordered, it's surely an implementation detail. The SOM may decide to store the tentative/in-process service internally, or to delegate the storage to the inventory while marking the service with an appropriate status to ensure (for example) that it won't be retrieved by BaU searches for active services.
Hope all of this makes sense.
P.S. I suggest you consider carefully the use of the word
stateless. Statelessness has nothing to do (in my opinion) with permanent storage of entities, but rather to the maintenance of internal memory state that requires consumers to be bound to a particular instance/process of a software unit. A CRUD entity software unit can be completely stateless. Consumer can create an entity by POSTing to one instance, and then update the same entity by PATCHing to a different instance, indeed the consumer should be completely unaware of which instance is handling its requests.
------------------------------
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: Aug 11, 2021 11:09
From: David Whitfield
Subject: Representing Services in TMF641
Hi @Kinshuk Kulshreshtha first of all thanks for your response!
In theory i am aligned to your view here and this is helpful given we have a number of different viewpoints on this internally.
In terms of follow up whilst the duplication of data accross different systems of record is bad for a number of reasons i'm interested in your view on the service order management system being stateless. Whilst i agree that Service Inventory management does own and record the state of a service my thought was that service order management would
- own the state of the order and the line items contained within it
- update the state of the service (via 638 patch) as the order lines/order progress through their lifecycle.
Interested on your thoughts on this and @Koen Peeters i wonder if you have thoughts on this too.
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: Aug 11, 2021 08:04
From: Kinshuk Kulshreshtha
Subject: Representing Services in TMF641
Hi David,
In my view, we should have only a single master system of record for every entity in the solution. TMF APIs should be used to retrieve the required entities from their respective system of records. Service Inventory Management System should be the master of Service Inventory and Service Order Management System should be the master of Service Order. In my view, the Order Management system should be stateless in nature and Service Inventory should provide the Statefulness to the transactions. So, when Service Order Management System receives a TMF641 to create a Service Order, it should call TMF638 POST to Service Inventory to create respective Service in Service Inventory and perform Design & Assign of the Service.
Similarly when the Service Order Management System needs the details of the Service Inventory, it should call TMF638 GET and retrieve all the required details from the stateful Service Inventory.
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
Original Message:
Sent: Aug 11, 2021 04:31
From: David Whitfield
Subject: Representing Services in TMF641
Hi community,
we are working through an implementation of TMF641 (and TMF 638) and can see that the following two resources seem the same. This makes sense as in 638 we are managing the service resource itself and in 641 we are managing a create/update/remove of the service.
The question is when it comes to an implementation of the two different applications 'Service Inventory Management' and 'Service Order Management' that sit behind these open API's it is envisioned that the data about the service is stored in both of the applications or is it considered that in an implementation of TMF641 only a link is stored and say when calling GET on a service order it is internally calling TMF638 to populate the rest of the service data?
Equally on a POST to the TMF641 API is it again internally calling TMF638 (say single line item with action = add) to create the service in its data store?
thanks
Dave
------------------------------
David Whitfield
TalkTalk Group
------------------------------