Open APIs

Β View Only

  • 1.  Open api TMF 638 asynchronous support and batch (multiple) payload support

    Posted 6 days ago
    Edited by Akin Pillot 5 days ago

    I have reviewed TMF638 for service management, but I have some concerns regarding its implementation in our service APIs (for example, enabling services like call forwarding).

    We are implementing TMF638 with asynchronous backend provisioning (using SQS).
    When we call POST /service, provisioning is still in progress, so we initially return a non-active state (such as reserved or inactive).

    However, during CTK testing, the immediate GET after POST fails unless the service state is returned as active.

    My questions:

    • What is the recommended TMF-compliant approach in this scenario?
    • Should we return active immediately (optimistic activation)?
    • Or is there a proper way to handle asynchronous provisioning that is compatible with CTK?

    Additionally:

    We also need to support enabling multiple services in a single request.

    • Can we send an array payload (multiple services) in a single request in TMF638? Is this supported as per the standard?
    • If supported, how does this behave during CTK execution, especially for PATCH operations?
    • Will CTK handle multiple updates in a single PATCH request, or does it strictly expect one service update per request using a single service ID?

    • What if two service in same payload one is active and other is failed due to some reason or validation? how manage response structure partially success responses?

    Also:

    • Is there any TMF CTK or standard approach available to support multiple/bulk execution (for creating or updating multiple services in one request)?



    ------------------------------
    pranay patel
    TO BE VERIFIED
    ------------------------------



  • 2.  RE: Open api TMF 638 asynchronous support and batch (multiple) payload support

    Posted yesterday

    Hi Pranay,

    TMF638 is intended to be purely an inventory API, and as such it is not constructed to support provisioning of services. The interfaces that deal with provisioning are TMF640 Service Activation Management, TMF702 Resource Activation Management and TMF664 Resource Function Activation Management.

    Take a look at those and think about how you might utilize them in your architecture - as they are much better suited for provisioning and activation.

    There are broadly 2 approaches:

    1. Run the provisioning transaction, and if it succeeds, update the inventory with a TMF638 call.
    2. Record the intended change in the inventory with an additional state, run the provisioning instruction and if it succeeds change the actual state on the inventory using TMF638.

    The second has the benefit that anyone retrieving from the inventory will see which services are undergoing change.



    ------------------------------
    Peter Eksteen
    Product Manager
    CIENA Blue Planet
    ------------------------------



  • 3.  RE: Open api TMF 638 asynchronous support and batch (multiple) payload support

    Posted yesterday

    Hi Peter, thanks for the clarification.

    In our case we are using TMF638 only for service enable/disable (provisioning is handled by separate APIs), but:

    • We support batch processing (up to 50 in payload, and 50k–100k via file upload)
    • So execution is asynchronous in backend

    πŸ‘‰ During CTK tool tmf compliance testing:

    • After POST, PATCH/GET is triggered immediately
    • But backend processing for service activation is still ongoing (POST service taken but process run on backend)

    πŸ‘‰ In this situation:

    • We cannot practically allow PATCH on services which are not yet enabled

    So:

    πŸ‘‰ How should this be handled in a TMF-compliant way?

    • Should we still accept PATCH and return 200 (even if processing not completed)?
    • Or is it valid to reject PATCH while service is under processing?

    Also:

    πŸ‘‰ Even if we move to TMF640, the same async behavior will exist, so CTK failure would still happen.

    So what is the recommended way to handle this conflict between asynchronous processing and CTK expectations?



    ------------------------------
    pranay patel
    TO BE VERIFIED
    ------------------------------

    Original Message


  • 4.  RE: Open api TMF 638 asynchronous support and batch (multiple) payload support

    Posted yesterday
    Edited by Peter Eksteen yesterday

    One way of handling it - but really only possible via TMF640 - is to create the services (each service in designed state created by TMF640), on success of each service - update the state to active for that service.

    For northbound systems it would be best to use the Hub subscription mechanism to get updates on TMF638 state changes - so that northbound systems know when each service is in active state.

    TMF638 is the prescribed way to create services (and you could use it from the TMF640 activation process to create each service, update each service).

    Other clients can still use TMF638 directly to query or update (non-configuration changing) attributes of the service.

    I should add: the TMF API's are NOT explicitly designed to do batch handling, but they do allow multiple entries in the payload - and as it is in the body of the HTTP request - you should be okay.

    ------------------------------
    Peter Eksteen
    Product Manager
    CIENA Blue Planet
    ------------------------------

    Original Message


Related Content