TM Forum Community

 View Only

  • 1.  Guidance on using service.state with POST Requests in TMF641 Workflow

    TM Forum Member
    Posted 7 days ago
    Edited by Marlon Almazan 7 days ago

    Hi TM Forum community,

     

    We're working on a scenario where the Cross Domain Network(XDN) layer interacts with the ODM using TMF641. After certain actions are performed within ODM, synchronous responses are sent back to XDN.

    The workflow is expected to complete in three stages, and our current implementation involves:

    • A POST request from XDN to ODM
    • Followed by two PATCH requests to update the service state

    1. POST(serviceOrderItem.action=add, service.state=Reserved)
    2. PATCH(serviceOrderItem.action=modify, service.state=Designed)
    3. PATCH(serviceOrderItem.action=modify, service.state=Active)

    We'd appreciate guidance on:

    • Whether this use of service.state transitions via POST/PATCH requests aligns with TMF641 best practices
    • Any constraints or considerations we should be aware of when using POST/PATCH for state progression
    • Recommendations for modeling this workflow more effectively

    Please let me know if further context is needed.

     

    Thanks & Regards,

    Akshat


    #OpenDigitalArchitecture

    ------------------------------
    Akshat Shukla
    BT Group plc
    ------------------------------



  • 2.  RE: Guidance on using service.state with POST Requests in TMF641 Workflow

    TM Forum Member
    Posted 7 days ago
    Edited by Abel Ruiz Huerta 7 days ago

    Hi Akshat,

    I wouldn't say that updating the services being provisioned should be done through TMF641. I'm still missing some details to understand the use case you're describing fully, but let me try to clarify my point:

    • If the service state changes are meant to occur during the activation process, they are part of the provisioning flow. In that case, the Service Order Management component would be responsible for updating the service as part of the provisioning process via the TMF638 API. These changes can then be notified back to the XDN through event notifications. In other words, I don't think the XDN should explicitly set the service state in this scenario.

    • On the other hand, if we're talking about state changes after the service has been activated (i.e., once the original service order has been completed), then you should issue subsequent POST requests to the TMF641 API to trigger the necessary modify actions and update the service states accordingly. If there's no specific business logic associated with the state change, you could technically perform PATCH operations directly against the service from the XDN - though I find that approach a bit rough.

    I recommend taking a look at the use cases described in the IG1228 How to Use ODA guide, particularly TMFS008, which illustrates a complete end-to-end service provisioning scenario. You can find it here:
    https://www.tmforum.org/resources/technical-specification/tmfs008-use-case-service-and-resource-order-management-for-postpaid-mobile-subscribers-v3-4-0/

    Hope this helps.
    Thanks and best regards,



    ------------------------------
    Abel Ruiz Huerta
    alvatross
    ------------------------------

    Original Message