Open APIs

 View Only
  • 1.  TMF641 state diagram and order approval

    TM Forum Member
    Posted Oct 24, 2019 09:21
    Edited by Alexandre Meynaud Oct 24, 2019 09:22
    Hello all,
    Looking a the TMF631 ServiceOrder state diagram (same as OrderItem), we first see an "Accept Order" conditional block, which decides to set the Order state to "Acknowledged" or "Rejected".



    I believe that the Service Ordering Management system (TMF641 server) is responsible for this "Accept Order" decision, either as a manual or automatic (preferred?) processing.
    However, especially if this processing is manual, the approval step can take some time. But as an order creation is by definition asynchronous (see a previous discussion in this community forum), we are maybe missing an intermediate state value like "waitingForApproval"?

    Could someone explain what should be the expected behavior of the SOM system when receiving a POST /serviceOrder request, for example:
     
    1. Wait for the automatic/manual approval step to complete, and then only return the order, with an id and a state value set to either "Acknowledged" or "Rejected". In this case, the POST request becomes synchronous with the "approval" step. If the approval is manual, the POST response can even come back hours (or days) later.
    2. The request returns immediately the order, with an id but no state value.  (This is where an additional "waitingForApproval" enumerated value could be useful). The state can then change to "Acknowledged" or "Rejected" (and then other values) later, and the requesting BSS system is made aware of the change through notifications (if supported) or regular polling of the order resource (its id was returned previously).
    Cheers
    Alexandre

    ------------------------------
    Alexandre Meynaud
    Hewlett Packard Enterprise
    ------------------------------


  • 2.  RE: TMF641 state diagram and order approval

    TM Forum Member
    Posted Oct 24, 2019 10:10
    Hi ALexandre
    Firstly, you are perfectly free to add additional states to the core set of states defined in the specification - your implementation remains conformant.

    I could argue that the actual creation of the order in the SOM is synchronous, and it will either succeed or fail based on elementary (and quick) validations that the SOM decides to apply. With success, the order will be created with status Acknowledged, and then more detailed processing will result in status changes including perhaps rejections that might take time to carry out (including manual analysis).

    Let's hear what @Ludovic Robert has to say.



    ------------------------------
    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 state diagram and order approval

    TM Forum Member
    Posted Oct 24, 2019 10:52
    Hello

    I have same discussion internally within Orange about this Acknowledged state...
    My perspective is very similar to Jonathan one.

    SOM receives a POST serviceOrder. Nominally it has to provide a synchronous response with an id & state (alternative scenario leveraging monitor resource could be imagined but let park it in our discussion). Before to provide response, SOM could make surface control to check 'basic stuf'f: is there at least order item ? enum are respected ? if action add then I have a service Specification id, etc... depth of these controls could depends on implementation.
    • If fails - no resource created - Return code 400
    • If success - a serviceOrder resource is created, id-ed and state = Acknowledged


    Then at this stage we should be able to have additional check (Alexandre approval stage) - manual or automatic - to provide example: check if the servicSpec to be implemented exist and is valid in catalog, that the requested modification for an existing service is authorized by catalog, etc... If it fails and structurally SOM will not be able to deliver this ServiceOrder then I would like to go to rejected (And leveraging service state notification).

    So probably the defined states fit this pattern (and you can extend them as mentioned by Jonathan adding an acknowledged.waitingForApproval for example) but state transition should be (re)discussed.

    Hope it helps

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 4.  RE: TMF641 state diagram and order approval

    TM Forum Member
    Posted Oct 24, 2019 12:38
    Edited by Alexandre Meynaud Oct 24, 2019 12:39
    Hello Jonathan, Ludovic,

    Thanks for the quick reply. So we are pretty much in line with a simple creation pattern like:

    POST /serviceOrder, and only 2 main possible responses:

    • 400: bad request, e.g. syntax error, no item in order, no serviceSpecification, etc...
    • 201: Return an Order with an Id and in Acknowledged state

    Note that there is no such answer as: 201, Order with Id and a Rejected state, as it does not really make sense and overlaps with the "400" response.

    Then, Ludovic's example is interesting (and very common imho): "check if the servicSpec to be implemented exist and is valid in catalog, that the requested modification for an existing service is authorized by catalog"

    What should happen in this particular situation according to TMF? The options I see are:

    • SOM figures out the pb before attempting to provision the service:
      • The order state is set to Held (even if the diagram do not have a transition from Acknowledged to Held), waiting for the order to be modified with a valid catalog item? I guess this is done through a PATCH request, changing the serviceSpecification attribute. Once the Order is patched the state can go to inProgress. By the way, when an Order is in the Held state, reflecting a problem with the order and waiting for a correction, how do we provide additional information about the problem? Is there an "error message" or "reason for being held" attribute in the Order/Item to report such an information?
      • The order sate is set to Rejected or Failed (again, even though there is no state transition from Acknowedged to Rejected, but we can surely add transitions as well to the model) ? At this stage the Order cannot be modified further.
    • SOM attempts to provision the service (no beforehand check), so the Order state goes to inProgress, but the provisioning fails (bad catalog!) so the Order state switches to Failed?

    Maybe this is all implementation decisions, but I think it would be useful, for a common scenario like this (invalid or unknown catalog serviceSpecification), to have a recommended (not to say standard) state transition pattern.
    What do you think?
    Cheers



    ------------------------------
    Alexandre Meynaud
    Hewlett Packard Enterprise
    ------------------------------



  • 5.  RE: TMF641 state diagram and order approval

    TM Forum Member
    Posted Oct 25, 2019 01:51
    Hi,
    regarding the state 'Acknowledged' I would like to share my experiences: It makes sense, not to have the synchronous answer already with the Acknowledged state. The reason is, that not only these simple checks (if the ServiceOrder is following the swagger and enums definitions) but also a bit more validation against the Service Catalogue (which then needs additional calls). The third level of validation is (by the process) against the Service Inventory (e.g. if the ServiceOrder claims to modify something, which in fact does not exist in the Service Inventory). All those "basic checks" are API calls, though I would rather suggest, that after service order creation and the direct synchronous feedback (along with the "Created Event", there is a state "Created" which then can be checked by the service order process - and after the check asynchronously can come back with "Acknowledged" State Change Event or the "Rejected" State Change Event.
    Best Regards
    Adrian

    ------------------------------
    Adrian Ofterdinger
    Capgemini
    ------------------------------