Open APIs

I have always struggled to understand the difference between the role of TMF640 (activation and config) and TMF638 (service inventory). Up until the last release of these API's I have worked with the theory that 638 provided the as-ordered view where 640 provided the actual configuration. 

I notice now however that in the latest releases (18.5.0) these API's now have identical URLs for GET/POST/PATCH and DELETE. Adding to my confusion the two documents differ however in terms of the payloads they return. I am not sure that that can make sense. Is this an error?

I have searched for more information relating to the context for 638. It seems logical to me that a 640 can CRUD on a service (or resource) and in so doing interacts with the service instance itself whereas the 638 was keeping a copy of the configuration as it was at a point in time. This arrangement could save hits on the service that may have impacted the performance of that service.  But when and what would have issued the call to 638 to establish that "inventory record"? Would it have meant that after each 640 a client must then issue a 638 request? And how is it (as per examples shown in older versions of the 638 document) that the ID and hrefs returned by the 638 were of the service and not of the service inventory record?

My apologies if I am missing something and wasting everyone's time.

------------------------------
Stuart Batten
Telstra Corporation
------------------------------

Hi Stuart,

I will attempt to explain the different service provisioning related API using an example.

Assume that our company sells e-link services virtual ethernet connections between two edge routers.

The service order management will receive a service order (TMF-641) which has an orderItem to add one CFS with serviceSpecification "eLink". The service order management will validate the order and create a CFS in the service Inventory (TMF-638).

In the serviceDesign phase the service order management will use the service catalog (TMF-633) to find out how this CFS is designed. The catalog will indicate that this CFS requires two RFS with serviceSpecification eLinkRouterConfig. The service order management will create these RFS in the service inventory (TMF-638). It will also update the CFS with the relationship to the RFS and update the status of the CFS to indicate that the serviceDesign is completed (TMF-638).

On the startDate of the serviceOrder the order management will update the CFS status to indicate that activation is pending. (TMF-638) It will also update the status of the RFS to the same status (TMF-638). When the status of an RFS is pendingActive, the order management will for each RFS collect information from the CFS (using relationships) and Resources (the routers) and will call the router configuration NMS (TMF-640) with this information.

When the NMS confirms the configurations are active on the routers, the service order management updates the status of the RFS to active (TMF-638). When all RFS are active also the CFS is set to active (TMF-638) and the service order is set to completed.

I hope this short story explains the use case sufficiently.

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------

Thanks for such a clear explanation. I was struggling to find meaning of all these services and this explanation cleared all my doubts as well.

------------------------------
monika kushwaha
Infosys
------------------------------

Original Message:
Sent: Jun 10, 2019 07:37
From: Koen Peeters
Subject: 640 and 638

Hi Stuart,

I will attempt to explain the different service provisioning related API using an example.

Assume that our company sells e-link services virtual ethernet connections between two edge routers.

The service order management will receive a service order (TMF-641) which has an orderItem to add one CFS with serviceSpecification "eLink". The service order management will validate the order and create a CFS in the service Inventory (TMF-638).

In the serviceDesign phase the service order management will use the service catalog (TMF-633) to find out how this CFS is designed. The catalog will indicate that this CFS requires two RFS with serviceSpecification eLinkRouterConfig. The service order management will create these RFS in the service inventory (TMF-638). It will also update the CFS with the relationship to the RFS and update the status of the CFS to indicate that the serviceDesign is completed (TMF-638).

On the startDate of the serviceOrder the order management will update the CFS status to indicate that activation is pending. (TMF-638) It will also update the status of the RFS to the same status (TMF-638). When the status of an RFS is pendingActive, the order management will for each RFS collect information from the CFS (using relationships) and Resources (the routers) and will call the router configuration NMS (TMF-640) with this information.

When the NMS confirms the configurations are active on the routers, the service order management updates the status of the RFS to active (TMF-638). When all RFS are active also the CFS is set to active (TMF-638) and the service order is set to completed.

I hope this short story explains the use case sufficiently.

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------