TM Forum Community

 View Only

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

    Posted Oct 30, 2025 08:18
    Edited by Marlon Almazan Oct 30, 2025 09:26

    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

    Posted Oct 31, 2025 05:14
    Edited by Abel Ruiz Huerta Oct 31, 2025 05:14

    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


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

    Posted Nov 19, 2025 15:35
    1. Does your approach align with TMF641 best practices?
     
    POST for Service Order Creation: Yes, creating a new Service Order with serviceOrderItem.action=add and initial service.state=Reserved is consistent with TMF641. The POST should represent the intent to add a service.
    PATCH for Updates: Using PATCH to update the Service Order or its items is allowed in TMF641. However:
     
    PATCH is typically used to update the order resource (e.g., status, attributes), not necessarily to drive the service lifecycle directly.
    The service state transitions (Reserved → Designed → Active) are usually managed by the service inventory or service activation system, not by the order itself. The order reflects progress via its order item state (e.g., Acknowledged, InProgress, Completed).
     
     
    So, while your approach works technically, it's slightly mixing order state and service state responsibilities.
     
    2. Constraints and Considerations
     
    Idempotency: PATCH requests should be idempotent. Ensure that repeated PATCH calls don't cause unintended side effects.
    State Model: TMF641 doesn't define the internal service lifecycle; it focuses on the order lifecycle. If you expose service.state in the order payload, make sure it's clearly documented as informational, not authoritative.
    Atomicity: Each PATCH should represent a valid transition. Avoid skipping states unless your business rules allow it.
    Synchronous Responses: TMF641 supports synchronous responses, but for long-running processes, consider asynchronous callbacks or notifications (TMF642/TMF640).
     
    3. Recommended Modeling
     
    Use Service Order Item State for Workflow:
     
    Acknowledged → InProgress → Completed
     
     
    Delegate Service State Changes to Service Inventory (TMF638):
     
    The order triggers service creation/modification, but the actual state (Reserved, Designed, Active) should come from the service inventory API.
     
     
    Alternative Pattern:
     
    POST Service Order (action=add)
    PATCH Service Order Item to reflect progress (InProgress, Completed)
    Use TMF638 for service state transitions (or internal orchestration).


    ------------------------------
    Chirag Raval
    Lead Consultant
    Infosys Ltd
    ------------------------------

    Original Message


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

    Posted Nov 28, 2025 07:24

    Hello,

    Sorry, I think I didn't explain myself well. At no point am I suggesting updating the service by performing a PATCH directly on the service order. To modify an item in the inventory, a new order should be created with the action set to 'modify' (or 'delete', or any other action depending on the specific case). It is the Order Management component that, as a result of executing its order-handling processes, will trigger the requests to the inventory to update those items.

    Regards,



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

    Original Message


Related Content