Hi Matt and Gordon,
I appreciate that you want to represent the desired and actual state of the services, and use the difference to drive the required work.
What is unclear is how you want to represent the actual and desired states of services in the results of TMF638 and TMF640 retrieve/list calls.
You could have an interpretation where the TMF640 retrieve/list calls return the actual state and TMF638 returns the desired state, so that you can compare; but as I read the standards, that interpretation is not really supported by the text.
On the other hand, you are right that the resource model of the two APIs do not appear to have sufficient information to represent both actual and desired state of a service.
Clearly, TMF wants to ensure that an implementation MAY want to separate the representation of actual state as reported by TMF640 (e.g. by fetching information directly from a HLR/HSS), from the persisted inventory representation.
But I don't think that TMF intends to mandate that an implementation of TMF640 MUST NOT have its own persisted representation.
So if an underlying implementation, for whatever reason, does have its own persisted representation of both the actual and desired states of the services, and you want to support both TMF638 and TMF640 based on that single implementation, then the question arises what the difference should be between identical calls made towards one or the other API.
Retrieve/list:
- Are the TMF640 calls forbidden from returning desired states?
- Are the TMF638 calls forbidden from returning actual states?
POST/PATCH
- When a TMF638 call changes the desired state, is it forbidden for the underlying system to act on the difference between actual and desired that may arise from this?
- When TMF640 call changes the state, then transiently, during the activation (or if it fails), the actual state will differ from the desired one. Is TMF640 forbidden from returning the desired state, so it is only allowed to return the actual state?
Your suggestions are sensible:
If you offer TMF641/TMF638 then you don't expose TMF640
If you offer TMF640 POST/PATCH then you don't need to expose TMF638
There are, unfortunately, operators who require that all three APIs must be exposed simultaneously for the same services, and even that TMF640 POST/PATCH can be used for external activation requests on services that are simultaneously under the control of TMF641, also making internal requests to TMF640.
I cannot point to anything in the API definitions themselves that supports the suggestions. So this is not just a "theoretical" problem.
Peter
------------------------------
Peter Bruun
Hewlett Packard Enterprise
------------------------------
Original Message:
Sent: Jun 07, 2024 17:31
From: Matt Beanland
Subject: TMF640 vs TMF638 GET/LIST API
Hi Gordon,
Our recommended way to implement TMF638 is to always have it return the 'actual' or current service. This is the service you have, refreshed from the resource layer.
If the service was manipulated by TMF641 POST then the TMF641 serviceOrder.serviceOrderItem.service would show your intended service fragment. Similarly TMF640 POST/PATCH conveys a service intention, which either specifies or updates the expected or desired service. With TMF641 GET order the service fragment shows what you've asked for, but in service order events we like to show the service as it actually is at that moment.
In a world where service updates are reliable and fast this distinction between expected and actual may not matter so much, but we have found that:
- Telco operations are often complex, unreliable and/or long running, which makes them subject to further amendment of intention or change in 'delivery recipe'.
- To use or compose a service you need to know when the work of a service is actually done, and often what you now have
- 'Inventory' needs to contain persistent expected and actual, at least internally to a network domain
- Service events on the actual should only be generated when work is actually done
- If you offer TMF641/TMF638 then you don't expose TMF640 and the TMF638 GET should only ever show the service you actually have.
- If you offer TMF640 POST/PATCH then you don't need to expose TMF638 if you expose TMF640 GET as actual service.
Further:
- We maintain a persistent expected service view (generally this is only visible within the network domain), each order/patch is a partial update to this service
- We difference expected and actual services to generate the outstanding or difference service, which drives the work required, as this work is done this updates actual service view which advances until there is no essential difference.
- We are very clear how we signal when work has actually been done, this allows reliable consumption/composition
Hope this helps. We are talking further about our expected/actual/outstanding approach at DT Ignite.
Best Regards,
Matt
General
Original Message:
Sent: 6/3/2024 6:52:00 PM
From: Gordon Bolt
Subject: TMF640 vs TMF638 GET/LIST API
I have a question on the relationship between the GET (LIST) services APIs for TMF640 and TMF638.
From the API User Guides:
TMF640 describes the operation: GET /tmf-api-/ServiceActivationAndConfiguration/v4/service
This operation list service entities.
Here's an example of a request for retrieving services from the network.
TMF638 has a very similar operation: GET /tmf-api/serviceInventory/v4/service
This operation list service entities.
Here's an example of a request for retrieving multiple services.
The key difference seems to be that 640 is retrieving from the network. This is also explained in the discussion in TMF640 and TMF638 that TMF638 is an IT (database) component. Whereas TMF640 interacts directly with the network... However, in an actual implementation I would expect that both APIs are being served from databases, but perhaps different databases or views of the data.
When both of these APIs coexist, is the expectation that the TMF638 response and the TMF640 response are the same? Or is the TMF638 response a superset of TMF640 such that 638 has a complete view of the inventory while 640 is limited to the live/operational network view that has either been created through TMF640 POST or is directly discoverable from the network? Or is there a better way to think about these?
Thanks for any insights.
- Gordon
------------------------------
Gordon Bolt
Ciena Corporation
------------------------------