Hi everyone!
I agree with Koen.
Specifically, using TMF638, a modify/patch of a service, in the service inventory, to the state of "Terminated" keeps the object in the inventory for as long as someone wishes (could be years). This action should, however, de-allocate all resources that were assigned to this service, so they become available resources for other service instances.
Another event which should arise from the service inventory state transition to "Terminated" is the trigger of
TMF640 (Service Activation & Configuration) "DELETE" operation(s). Generally speaking, you want to completely remove everything that was previously activated for this service.
Obviously, this logic works well when the serving application of TMF640 is an Activation system (equivalently whether they are stateful or stateless).
It is possible that Jonathan asks the question in the context of a multi-tier service inventory architecture where we sometimes see implemented a customer-facing service inventory and a resource-facing service inventory, both managed by different organizations in a Service Provider (IT versus Networks folks, as an example). Generally, the Activation function would fall in the same environment as the resource-facing service inventory function.
It could be that both organizations wish to retain their respective service instances in "Terminated" state in their respective service inventories.
How does the customer-facing system invoke the resource-facing system for actions (which may be viewed as activation actions)? In that case, it could be that the API between the two systems, respectively owning the customer-facing versus resource-facing inventories, may benefit from using the Service Order API (TMF 641) (where you would invoke the "terminate" operation on the resource-facing service) instead of the Service Activation & Configuration API. Within the resource-facing service system, following a service state transition to "Terminated" (in the RFS inventory), the Activation API could be invoked, towards the Activation function, with a proper "DELETE" operation.
Cheers,
Stéphan
------------------------------
Stephan Pelletier
STEPHAN PELLETIER CONSULTING INC.
------------------------------
Original Message:
Sent: Jun 28, 2019 01:55
From: Koen Peeters
Subject: TMF640 Service termination
Hi Jeremy,
I believe you are correct to use a DELETE for the TMF640 API. TMF640 (Service Activation & Configuration) is intended to be interfacing to some NMS platform to create and terminate the service. Some NMS can be license restricted on the number of services. You typically do not want to pay license after the customer is gone.
Jonathan is describing a use case for TMF638 (Service Inventory) where indeed you want to keep track of historical information regarding services. Many countries even have laws to define the retention time for this type of information in the inventory. We should however not mix up both API's which serve a very different purpose.
Regards
Original Message------
Hi Jeremy
I think it would very inadvisable to terminate (or disconnect, or whatever) a Product or a Service by a REST DELETE operation. The purpose of DELETE is to remove the REST resource (logically or physically) from persistent storage. You would expect that after a DELETE, an attempt to GET the resource would give you a 400 Not Found (or similar).
But a disconnected product or service should still be present in storage, and even visible e.g. to service reps.
Consider the following use case to justify this:
- Customer requested termination of his mobile line 212-777-1234
- Four weeks later, the customer realizes that she wants service back
- Under the regulatory terms, customer is entitled to receive their original number for a period of up to 90 days
- So customer's mobile line is re-established.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------