Openslice Service Orchestration and Order Management - OSOM
OSOM is a service responsible for:
- Service Order Management (SOM)
- Service Orchestration (SO)
It uses open source Flowable Business process engine (https://www.flowable.org) .
A Service Order follows the states as defined in TMF641 specification:
When a new order is created, it goes into the Initial state. It is stored in the repository and triggers an Event.
Administrators are notified usually from the Ticketing System of a new order. They login to Openslice and change the State of the order either to ACKNOWLEDGED or REJECTED. If ACKNOWLEDGED they can Propose a startDate, add Notes, and add any additional service items
A process checks every 1 minute for ACKNOWLEDGED orders.
It retrieves all orders that are in ACKNOWLEDGED state and if the start date is in time it will initialize the process by settingn the order in IN_PROGRESS state. Finally the Start Order Process will start.
Start order process
This process for now is a draft simple prototype to make a simple orchestration via NFVO. Here the actual Services (TMF638/640 model) are created and attached to Service Order and Service Inventory.
We expect here to check which tasks can be orchestrated by NFVO and which by human. We create the equivalent Services(TMF638/640 model) for this order.
- During check it should decide to create Service(s) for this service order O1 and send it to ServiceInventory
- The Services(TMF638 model) are assigned to the Order O1 In supportService List
- Each OrderItem OI1 is related to one serviceSpecification
- Each ServiceSpecification has also related serviceSpecRelationships
- So if we receive an order O1 for a ServiceSpec A which relates to 3 specs(2 CFS, 1 RFS) we do the following:
- Create a Service S_A(TMF638 model) for ServiceSpec A for Order O1
- We create also 3 Services S_C1, S_C2 and S_R1 equivalent to the serviceSpecRelationships (2 CFS, 1 RFS)
- At this point the order will have 3 supportingServices refs(S_A, S_C1, S_C2) and 1 supportingResource(S_R1)
- The 3 supportingServices and 1 supportingResource correspond to total 4 Services in ServiceInventory
- Service S_A will have:
- startMode 5: Any of Manually or Automatically by the managed environment
- State: RESERVED
- Services S_C1 and S_C2 we decide that cannot be orchestrated then they have
- startMode: 3: Manually by the Provider of the Service
- State: RESERVED
- Service S_R1 will have
- startMode 1: Automatically by the managed environment.
- State: RESERVED
There will be two instances of task "User Task Manual Complete Service" each for Services S_C1 and S_C2. The task is Transient for now. It displays only the services that are not automated! Here is a flow for future:
- We wait here for human decision.
- From API we get a result: a. If set to ACTIVE/TERMINATED then we complete the task b. In any other state we stay in this task until it is resolved as in step a c. The Status of ORDER O1 is also updated to PARTIAL
There will be an instance of NFVODeploymentRequest process each for Service S_R1. (see later)
- This process is related with the NFVO orchestration
- It will send a msg to NFVO(s?) for a specific deployment request
All services in "Order Complete" are in a status:
- Depending on the result the service S_A is either ACTIVE or TERMINATED
- The Status of ORDER O1 is also updated to COMPLETED or FAILED
A Service follows the states as defined in TMF638 Service Inventory specification:
This process is related with the NFVO orchestration It will send a msg to NFVO(s?) for a specific deployment request Then it checks the deployment status. It will wait 30 secs each time until the deployment is running (or failed)
Check In Progress orders process
Every 1 minute the "Check In Progress Orders" process is executed checking if a supported Service changed state (i.e. to ACTIVE) then the whole Order will change state (e.g. go to COMPLETED)