Open APIs

Dear colleagues,   could you please help me to figure out proper way handling instance state for in-progress orders.
Let't take TMF641 Service Ordering and TMF638 Service Inventory as an example:

Let's assume I have a service instance with id=#1234.
I create service order with "modify" action for Service #1234 . So in my request to serviceOrder resource , I have service order item with service sub-resource, having id=#1234 and new set of characteristics.
The order fulfillment takes some time. 
While order is in progress , in fact I do have 2 versions of state for service #1234. One - As Is unmodified (let's call it #1234-AsIs) and another ephemeral ToBe (let's call it #1234-ToBe) , relevant in context of our in-progress service order.

Now questions:

1. Which state GET on  TMF638 /service resource should return ?  (guess #1234-AsIs until service order completed)
2. Should #1234-ToBe  be represented by instance of service resource with different Id ? If yes,  won't it create a discrepancy between /service order POST request and response?
3. Which state of service TMF641 Service Order Events (e.g. Service Order State Change Event) should reflect ?  (guess #1234-ToBe) 

Is there any commonly agreed approach on above?

The same will be valid for Resource Order/Inventory etc.

​​​

------------------------------
Simon Kuzin
SingTel Optus
------------------------------

Dear colleagues, any idea on above?

------------------------------
Simon Kuzin
SingTel Optus
------------------------------

I concur with your assumption that for a modify action your serviceOrder is handling two service instances.
In that case both services have the same id they need another field to differentiate them. An alternative with different id for both service can be designed as well but I personally prefer keeping the same id for modifications
One way to achieve that is to uniquely identify a service with the combination id and version. In the current OpenAPI this version attribute is missing, but can be easily added as extension.
Both service versions have their own state. To make this work properly we need to add conditions to the states of services with the same id.
The first condition is that only one of the service can be active. Setting the new service to active should automatically set the previous service to terminated.
Setting the new service to active also sets the OrderItem to completed.
For each service instance there is a ServiceOrder handling the state transitions until it reaches active (unless the serviceOrder is cancelled).
There will also be a second ServiceOrder handling the state transition to terminated.
The serviceOrderItem array can contain the link to these serviceOrders. I give them the roles activator and terminator.

A serviceOrderItem with an add action only has an activator link
A serviceOrderItem with a modify action has both a terminator and an activator link.
A serviceOrderItem with a delete action only has a terminator link.
These links are documented on the Services rather than the ServiceOrders.

Based on the above assumptions, your questions can be answered as follows:
1/ GET should by default only return the instance with the active state
2/ if the same id is used:

• POST: creates a new version
• PATCH: operates on latest version
• DELETE: operates only on versions that are terminated.

3/ ServiceOrderStateChangeEvent should be send out for each state transition of a ServiceOrder or one of its ServiceOrderItems.
ServiceStateChangeEvent should be send out for each state transition of each version.
Regards




------------------------------
Koen Peeters
OryxGateway
------------------------------

Original Message:
Sent: Jun 08, 2022 05:19
From: Simon Kuzin
Subject: Instance State during Order execution

Dear colleagues, any idea on above?

------------------------------
Simon Kuzin
SingTel Optus
------------------------------