Open APIs

 View Only
  • 1.  TMF640 create service

    TM Forum Member
    Posted Jun 20, 2024 09:10

    I have a few questions about intended use of TMF640 (please forgive my ignorance):

    1. The "Create Service" call is used to provision a service in the network, that gets submitted as an input - is that correct? The "create" verb makes it a bit confusing: I assume it means "create a service of a specific type in the network, for which I am providing a description in a form of a collection of characteristics and their values".
    2. How do I make a "Create Service" call asynchronously so that I can retrieve the response (much) later?
    3. Along the same lines: what is the best way to monitor status of service provisioning, for which the "Create Service" call was made?

    Thanks!



    ------------------------------
    Dmytro Vostrikov
    Netcracker Technology
    ------------------------------


  • 2.  RE: TMF640 create service

    TM Forum Member
    Posted Jun 20, 2024 09:27

    Hi Dmytro

    1. As for any REST API, we are limited by the verbs that HTTP makes available. So POST, which is Create in REST semantics, is what we use. And indeed POST in TMF640 is intended to create (and activate) a new service in the network. The input (request body) is the Service to be created (provisioned), described by its characteristics and perhaps features.
    2. If your implementation is asynchronous, you are expected to return a Monitor entity on the POST response, and then use the Monitor to poll the status of the request. This is described in summary in the user guide for TMF640.
    3. Same as 2

    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.
    ------------------------------



  • 3.  RE: TMF640 create service

    TM Forum Member
    Posted 28 days ago

    Hi Dmytro,

    Yes, it is confusing - but they key is align with the view that TMF640 is supposed to manipulate a Service (not the record of a service, but the actual service).

    So the POST (create) here is intended to instantiate the service in the network - whatever that may entail.

    Similarly PATCH (modify) is intended to change the service in the network

    and of course DELETE is intended to remove the service from the network.



    ------------------------------
    Pieter Eksteen
    Ciena Corporation
    ------------------------------



  • 4.  RE: TMF640 create service

    TM Forum Member
    Posted 27 days ago

    Hi Dmytro,

    Below Information Guide can be refer around this topic

    1. IG1224 NaaS Transformation (Section 2& 3 in particular)
    2. IG1228 ODA/API Call Flow (Use Case TMFS008)


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



  • 5.  RE: TMF640 create service

    TM Forum Member
    Posted 27 days ago

    @Dmytro Vostrikov asks about asynchronous use of TMF640, for which @Jonathan Goldberg provided the relevant documentation references.

    To be clear, since your question is from an API consumer standpoint, the API producer will have chosen whether or not to implement asynchronous operation. You will know it is an asynchronous operation if the Status Code of the response is 202 Accepted. In this case a Location header should be included with the URL of a monitor resource which you may poll (GET)  to get progress updates and know when it is complete. You may also subscribe to notifications.



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 6.  RE: TMF640 create service

    TM Forum Member
    Posted 27 days ago

    Excellent! Thanks Vance for providing the technical details that I omitted!



    ------------------------------
    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.
    ------------------------------