Open APIs

 View Only
  • 1.  TMF638 - Maintain services and serviceOrders

    TM Forum Member
    Posted May 18, 2020 10:38
    Hello,

    In the SOM layer, the TMF638 is playing a role to maintain multiple services in an inventory and, together with them, we have the link to the Service Orders via serviceOrderRef. This API can be consumed by a service orchestrator to instantiate or maintain a service. However, the same cannot be used for service orders and only a refID is maintained where multiple orders can be linked to multiple services.

    My question now is mainly focused on service order inventory guidelines..

    Would it make sense for having the same service inventory to maintain service orders?
    If so, is there any TMF API that could answer to these needs or should this integration be taken internally with non-standardized API's?

    Thanks in advance

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------


  • 2.  RE: TMF638 - Maintain services and serviceOrders

    TM Forum Member
    Posted May 19, 2020 06:34
    Hi Carlos,
    I think Service Inventory should not be used for storing Service orders, rather it should be an Service Order Inventory. Typical implementation of SOM keep the Order Inventory separate from Serice Instance Inventory.
    TMF suggests that the service instance can have a reference to Service Orders (1 to many).

    Since TMF 641 is used as the vehicle to initiate TMF 638 interactions, why do you think there is a need for non-standardized APIs to keep the relationship?
    I may not be getting your query completely correct.



    ------------------------------
    Varun Nair
    Telstra Corporation
    ------------------------------



  • 3.  RE: TMF638 - Maintain services and serviceOrders

    TM Forum Member
    Posted May 19, 2020 08:03
    Edited by Carlos Portela May 19, 2020 08:14
    Hi Verun,

    Thanks for your input. I understand your point and I think it makes sense.

    As you say, the TMF 641 can be seen as a vehicle to initiate the TMF 638 interactions. However, the TMF 641 is also the vehicle to trigger an instantiation on the Service Order inventory. That's why I am asking if it doesn't make sense to trigger two inventory API's on a TMF641 call: 638 for service and other one for service order inventory. In this case, as there's no service order invetory API available, it needs to be implemented on a non-standardized way internally. 

    Let me know if you got my point.

    Regards

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------



  • 4.  RE: TMF638 - Maintain services and serviceOrders

    TM Forum Member
    Posted May 22, 2020 07:57
    Hi Carlos


    TMF 641 defines the API and  also the defines the dependancy using serviceOrderRef.
    The implementation of this API(SOM layer) should take care of orchestrating the dependancy (pre-requisite, dependent-on etc..) besides persisting the relationships.
    Also SOM layer has to expose all the dependant serviceOrders for a given serviceOrder.



    ------------------------------
    Srikanth Minnam
    Qvantel Oy
    ------------------------------



  • 5.  RE: TMF638 - Maintain services and serviceOrders

    TM Forum Member
    Posted May 24, 2020 18:31
    Hi Carlos,
    641 Service Order Object should be part of the Service Order Inventory. You can use 641 API request itself to update the order inventory database instead of creating non standard API. HREF of the Service Order Object can be represented using TMF 641 URI pattern. 

    The Service Object is already represented in 638 API and can be used to update inventory, which you have already agreed.



    ------------------------------
    Varun Nair
    Telstra Corporation
    ------------------------------