Open APIs

Expand all | Collapse all

TMF641 Service Ordering Management API

  • 1.  TMF641 Service Ordering Management API

    TM Forum Member
    Posted 9 days ago

    Hi!
    Usually BSS Product Management Platform is creating CFS service orders and BSS knows the references with CFS and physical goods(resources)

    I am a little bit confused with following

    TMF641 ServiceRestriction sub-resource has

    supportingResource

    A list of resource references (ResourceRef [*]). A list of supporting resources (SupportingResource [*]).Note: only Service of type RFS can be associated with Resources.

    supportingService

    A list of service references (ServiceRef [*]). A list of supporting services (SupportingService [*]). A collection of services that support this service (bundling, link CFS to RFS).

     

    Is it BSS responsibility to decompose both level CFS and RFS services(link CFS to RFS) and use Service Catalog and Service Inventory data for that?

    Or it is still service order management systems responsibility to add this information (PATCH serviceOrder)

     

    Inspecting TMF641(ServiceOrdering) and TMF645(ServiceQualification) their resource models look similar.

    So our OSS architects figured out that BSS Order Management have to take  service qualification resource information and add it as an input while creating service order. So service order management do not need Service Catalog for decomposition and OSS starts the work as BSS predefined.

    Could anyone explain how to understand  this API spec?



    ------------------------------
    Kind regards,
    Reet Meier
    Solutions Architect
    Telia Eesti
    ------------------------------


  • 2.  RE: TMF641 Service Ordering Management API

    TM Forum Member
    Posted 8 days ago
    Hi Reet
    My understanding is that according to the Open API model, the BSS layer (order capture and handling) is responsible for decomposition of Product to Service. This is expressed by the fact that the Product Catalog (TMF620) has pointers to the ServiceSpecs that would be instantiated to implement a ProductSpec. This would be done in various business processes, including:
    • Checking serviceability - the BSS layer would decompose the product view to service view in order to invoke the Service Qualification API
    • Submitting order - the BSS layer would decompose the product view in a submitted product order to the service view for network provisioning by the Service Order API
    There is no expectation that the BSS layer would do internal service decomposition (from CFS to RFS), that would be in the OSS layer (e.g. in a Service Order management component)

    You could reach out to @Ludovic Robert for additional clarifications.

    Hope it helps​​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: TMF641 Service Ordering Management API

    TM Forum Member
    Posted 8 days ago
    Hello Reet, Jonathan

    I globally agreed with Jonathan. First, the product catalog has the productSpec to CFSSpec relationship.

    BSS layer 'calculates' during (product) order fulfillment the CFS to be instanciated (or modified) and then leverage TMF641 ServiceOrder to describe CFS-action to the SOM.
    The SOM will determine which RFS to be use for each CFS of the service order. Then, at this point it depends on you SOM/OSS architecture (and exposed capabilities) - In some case you'll trigger resource level action (leveraging resource order API or resource Activation & Configuration API) - in some other case you'll have to send RFS level action (and in this case you could use TMF641 again but at 'RFS' level).

    I'm sure The ODA team could provide more relevant comments on this topic.

    About serviceQualification, I envision it more in pre ordering phase use....meaning that during order capture (or before) you'll use this API to identify eligible servicesSpec in order to filter relevant  proposed productSspec/productOffering (using again the catalog information).

    Hope it helps.



    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 4.  RE: TMF641 Service Ordering Management API

    TM Forum Member
    Posted 7 days ago

    Hello
    Thank you Jonathan and Ludovic
    . It helps.

    I got the answer that I have expected.  We will use only CFS specs references we get from product catalog and create service orders on them.

    We have discussed that service qualification done in pre-ordering phase usually does not change during ordering . So if it is not expired by some network event or other reason we can use it as backbone to design and book technical resources in SOM processes. Of course only those on which customer has selected offerings and characteristics.



    ------------------------------
    Reet Meier
    Telia Eesti AS
    ------------------------------



  • 5.  RE: TMF641 Service Ordering Management API

    TM Forum Member
    Posted 3 days ago
    Hi Robert

    The approach toward 641 usage is well defined, but there is one question on which you may be able to help.

    For the decomposition from Product to CFS  to take place the catalogue, or  published CFS  must be available in the BSS or commerce layer, what if we want to keep commerce and production ( as per the ODA ) completely separate and use the SOM for decomposition based on 622 ? This would keep  the BSS independent of any service characteristics whatsoever.

    In short what is mean by ' "calculates"  the CFS ? ' as this information is available in the service catalogue ? In order to maintain independence between BSS and SOM we can either have the product pointer in the SOM or the service pointer in the BSS , either would work right?    It depends where the decomposition would take place.

    As for the rules, again we have a separation of concerns between commerce and production , so the dependencies would be handled in each respective area.

    Your thoughts?

    Regards

    Peter Skoularikos
    Telekinetics






    ------------------------------
    Peter Skoularikos
    Telekinetics
    ------------------------------



  • 6.  RE: TMF641 Service Ordering Management API

    TM Forum Member
    Posted 14 hours ago
    Hi Peter,

    Probably ODA team could provide better outputs. From my perspective, and given the fact that a productSpec is build from one CFSSpec (it restricts it) I tend to think that the decomposition will be done in the BSS in the order fulfillment component (retrieving CFS in catalog bijectivly from ProductSpec for add or reading the inventory link product to service for other order action). Doing this decomposition in BSS will also provide you some flexibility has managing severals SOM and then sending separate service order for one product order (it is trick if you do the decomposition in SOM).
    I you look of today open apis you'll find alignement with this pattern: serviceSpec is retrievable from productSpec - service from product but not the reverse way.

    Hope it helps
    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------