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
------------------------------
Original Message:
Sent: Oct 24, 2019 10:52
From: Ludovic Robert
Subject: TMF641 state diagram and order approval
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
Original Message:
Sent: Oct 24, 2019 10:09
From: Jonathan Goldberg
Subject: TMF641 state diagram and order approval
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.
Original Message:
Sent: Oct 24, 2019 09:21
From: Alexandre Meynaud
Subject: TMF641 state diagram and order approval
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:
- 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.
- 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
------------------------------