Open APIs

 View Only

  • 1.  Positioning of TMF640

    Posted Jan 28, 2021 08:20
    Hi,

    I've got query on positioning and need of 640 after reading of 640-Service Activation, 641-Service Order, 638 - Service Inventory management. Can the API community share the guidelines defined while defining APIs ? That'll help.

    1. 641 has "Activate" as target state for Service which does provide option of Activation/Configuration. This is same functionality as of 640. So, Is 640 subset of 641 ? 
    2. If answer to qn-1 is No ,  What are guidelines in selection of 641/640 ? i.e. In which scenarios should they use. I would like to present 2 scenarios of B2B world. Customer wants to add a new location for getting new products, Other is In-life change i.e. Customer wants to make changes to multiple RFSs to achieve a business outcome

    Thanks in advance.

    ------------------------------
    Bhanu Sirigiri
    BT Group plc
    ------------------------------


  • 2.  RE: Positioning of TMF640

    Posted Jan 29, 2021 11:04
    Hi Bhanu

    We had within the TMF API team a lot of discussion on this topic. Probably @jmayer@mayerconsult.ca ​​coud provide you some direction.

    From my perspective:
    TMF641:
    • is intent base by describing a request to a service operation
    • allows to find, retrieve, create modify, delete a service order
    • Service order is a distinct resource than service. A service order describes a group of operations on service – one service order item per service.
    • An action at the level of the service order item describe the operation to be done on a service
    • Separate status on order/order item that on the service itself. Delivery progress could be tracked at service order/SO item levels
    • Capability to describe relationship between not yet existing services (based on items relationship)

    TMF640
    • is a REST operation directly on the service entity itself.
    • allows to find, retrieve, create, modify, delete directly one service
    • The operation is unitary – only one service could be managed
    • No status on the operation itself. Only service state is managed (except if Monitor resource is used)
    • No date or mechanism to have a follow-up on action progress (except if Monitor resource is used) but notification could be trigger on service change
    • Relationship could be describe but relationship target must exist in inventory

    Hope it helps
    Ludovic

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



  • 3.  RE: Positioning of TMF640

    Posted Jan 31, 2021 07:15
    Hi Bhanu

    Adding to @Ludovic Robert's answer:
    • Ludovic is correct that TMF640 operates on the service entity (without an order), but here's the crucial thing, to my understanding it operates on the entity in the network itself, i.e. directly on the switch or whatever other hardware/firmware/software expresses the instantiation of the service. This as distinct from TMF638, which operates on the entity in the service inventory database (persistent storage).
    • Since it can be expected that an operation directly on the network may take time, the API explicitly supports the asynchronous monitor pattern, whereby an initial response to e.g. POST returns no data regarding the entity, with HTTP 202 (accepted), and a monitor entity can be used to get updates from the network. This in contrast to most APIs, where there is a tacit assumption that the provider will provide an immediate synchronous response with the entity (200 or 201 for POST) and then entity events can be used to track continued progress, e.g. for Service Order TMF641.
    • We could expect that both TMF640 and TMF638 could be invoked internally by an implementation of TMF641.
    • Additionally, TMF640 could be invoked directly by a consumer for services where self-provisioning is supported, e.g. changes to service parameters with no financial implications. Less likely for initial provisioning of the service, but quite possible for subsequent changes.
    ​​Hope it helps

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------

    Original Message


  • 4.  RE: Positioning of TMF640

    Posted Jan 31, 2021 16:46

    Hi Bhanu,

    One of the best practice suggestions for selecting TMF640/TMF641 is included in IG1224 NaaS Service Fulfillment Guidelines (v2 published and v3 is draft).

    Feel free to join the IG1224 call and present your use case.

     



    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------



  • 5.  RE: Positioning of TMF640

    Posted Feb 01, 2021 04:49
    Thank you @Ludovic Robert @Jonathan Goldberg  @Abdul Majid Hussain for your insightful responses. These definitely helped me in strengthening my thoughts and proposal.

    I'm summarizing my views as follows. Please suggest if there are any deviations from TMF principles.

    Section 3.4 of IG1224 NaaS Service Fulfillment Guidelines v3.0.0 DRAFT - Open Digital Architecture Project - TM Forum Confluence covered the use cases that I had in mind too. The Type-2 sub-variants of a & b are common in service provider environment and confusion comes on which route to take. To bring consistency, I think it is logical to expose TMF641 as consistent API to northbound BSS and other Digital channels for partners/etc. @Ludovic Robert provided the differences between these APIS in clear form. My summarized take after reading the response and IG1224 is as follows.

    • I think Intent really wins for TMF641. Most of changes in SP environment will be based on Intent i.e. by a collection of changes on a collection of resources. I see TMF641 winning here too.
    • In both TMF641/640, the common approach to track the outcome of requested change is by using "Monitor Resource". But, TMF641 has an additional route to fetch it using "Service Order" which is it's advantage. This also makes life easy for "Auditing"  & for Analytics/Informatio
    In either case, like @Jonathan Goldberg said, TMF641 can internally invoke other TMF641/640 provided by underlying ODMs provided by software products.

    Thanks in advance.

    ------------------------------
    Bhanu Sirigiri
    BT Group plc
    ------------------------------

    Original Message


  • 6.  RE: Positioning of TMF640

    Posted Feb 01, 2021 08:29
    Edited by Sri-Jagadish(Jag) Baddukonda Feb 01, 2021 09:33
    The simplest way is to say that 641 invokes 640. 
    641 is a the Service Order with the appropriate action code (ADD, DEL etc) and based on the "Service" and the corresponding Action code, 640 can be invoked by the target function to change the status on the Service entity itself.
    This also brings up an interesting discussion on  - changes to the Service entity via a Service Order i.e. result in changes to the Service Instance and hence after the Product Order that triggered all these changes is closed the Service status for that unique Customer identifier should have been updated.
    Hence when the TMF 637 is invoked, these changes with the right state should be visible / fetched. So the synchronization of these states should have happened internally or the Product Inventory is kept at a high level.

    ------------------------------
    Sri Jagadish Baddukonda
    CSGI
    ------------------------------

    Original Message


  • 7.  RE: Positioning of TMF640

    Posted Feb 04, 2021 14:48
    Hi,

    All 3 API play a role in the orchestration of service orders.

    A typical service order orchestration would work as follows.
    A TMF641 Service order contains one or more services potentially with relationships between them that help in deciding on the sequence of events.
    The services in the TMF641 order are typically Customer Facing Services.

    The first stage of the service orchestration is the order validation.
    The service order will first go through a syntactical validation (conformance validation of the POST message according to a supperset of the rules defined in TMF641B).
    This step is followed by a semantic validation using the TMF633 ServiceSpecification, semantic validation differs for the different actions defined on the service order items, but typically includes checks if all mandatory characteristics are provided and if the values provided are in line with specification.
    If anything is not inline with the specification a stateChanged notification "Rejected" is sent.
    If all is well, the CFS are now created in the inventory using TMF638. The stage is ended by sending a stateChanged notification "Acknowledged".

    The second stage of the service orchestration is the service design. This stage might start immediately or can be delayed by the requestedStartDate.
    It starts by decomposing the CFSs in the required RFSs, followed by allocating the supporting resources. The RFS are now also created in the inventory using TMF638.

    The third stage is service activation. As soon as the resources are available TMF640 is called for each RFS.

    I hope this scenario gives some clarity on this subject.

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



Related Content