Open APIs

Expand all | Collapse all

TMF641 - Operation GET

  • 1.  TMF641 - Operation GET

    TM Forum Member
    Posted Sep 08, 2020 09:53
    Edited by Carlos Portela Sep 08, 2020 09:59
    Hello all,

    I'm having some internal discussions on how should GET work on TMF641 API..

    When a Service Order is introduced in OSS via POST with an orderItem as ADD and the service with few characteristics behind it, how should a later GET (during inProgress) look like at orderItem level and its service behind?

    Option A: Expose exactly the same data that have been submitted for the item and the service. The only dynamic value at orderItem would be the "State". Service would not have any extra data than what has been submitted and even the lifecycle of the service would not be exposed.
    Option B: Expose an enriched version of the service with more than the submitted characteristics (if its the case after treating the order), Service Instance ID (not part of the POST), Service hasStarted/startDate/state, etc. For the orderItem, behavior should be the same of Option A, exposing dynamically the State.

    In my opinion we should have more service data exposed when we do a GET on the serviceOrder (Option B). We should be able to see the latest updates of the service lifecycle: last service state, startDate, etc.. However, I think we could argue about exposing the new enriched version of the Characteristics. I am not sure if consumer of the API should see exactly the same characteristics that they ordered or the updated version on the inventory.

    If Option A is the right one... we would need to always have both TMF641 and TMF640 integrated with BSS so that it can follow the lifecycle of the services of the order.. I think it makes the integration with any BSS more complex..

    (Looking back to this topic with help of Ludovic - post nr 12 to 16 -, I could indirectly understand that Option B should be the one but I would like to have it clarified)

    What do you think? Option B makes sense to the community? With or without enriched characteristics?

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------


  • 2.  RE: TMF641 - Operation GET

    TM Forum Member
    Posted Sep 08, 2020 10:52
    Hi

    In my opinion, GET by ID, and without other qualification, returns the requested resource in its current state. Your Option B. Why would we behave differently?

    If a particular API wants to allow "time travel" (aka history), then ways should be found to express that semantic, e.g. to provide a date input parameter in the query string, or perhaps a version. We have had some discussions within the Open API team about how to formalize this, but I don't know how mature we are yet. And of course, there is a cost to the API implementor, it needs storage to maintain the history, indices to allow the retrieval by date or version, etc.

    Specifically for an order (product, service, etc.) I'm not sure that there is value for history, but maybe you can come up with use cases. Other entities lend themselves more obviously to this, such as catalog entities (versioning), inventory (especially product inventory, it might be needed for settling disputes for example), and more.

    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: TMF641 - Operation GET

    TM Forum Member
    Posted Sep 08, 2020 11:39
    Edited by Carlos Portela Sep 08, 2020 11:40
    Jonathan,

    Your comment makes sense to me also.

    At the moment, we foresee an order inventory where we store the submitted order (original version).

    In my opinion, the standard GET should expose the livable version of the order (with service current state). However, we could imagine to implement a GET with a url parameter of "?version=original" for example where we expose the original submitted version.  To support this suggestion, we don't need even to manage versioning in the order inventory because this inventory stores only the original version while the "livable" version is in fact built on the fly by reading from the ServiceInventory (TMF638) and overwriting the service instance in the order.

    From your feedback, it seems that they are thinking the same way on the OpenAPI team discussions... when it gets mature, I would be interested to hear their conclusions. :)

    Thanks

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------