Order orchestration workflow spawning a rule-based order

Edit online

You can review the high-level order orchestration workflow of a rule-based order.

Figure 1. Order Orchestration Workflow
order orchestration workflow

A complex rules-based order that is broken down into multiple child orders with inter-dependencies between them mainly goes through the following three stages of processing in the IBM® Sterling Order Management System application:

Validation

When an order of OrderType as 'CustomerOrder' is created in IBM Sterling Order Management System, it is sent to an external Rules Engine system, such as Operational Decisions Manager (ODM) for validation. An SDF service is invoked on the OnSuccess event of the ORDER_CREATE transaction. The service posts a message to the validation queue and an integration server triggers the order validation process by calling a custom API.
  • If the validation is successful, the order status is changed to InProgress by the ORDER_PROCESS transaction. The ORDER_PROCESS transaction is a derived ChangeOrderStatus transaction. The OnStatusChange event is configured to place a message in the decomposition queue.
  • If the validation fails, the ORDER_PROCESS transaction is called to change the order status to Suspended (Awaiting Validation) and an exception of ExceptionType as OrderValidationException is created using the createException API.

Decomposition

A validated order is sent back to the rules engine for obtaining the decomposed set of executable orders. When a message is dropped into the decomposition queue, an integration server picks up this message and triggers the order decomposition process by calling a custom API. The custom API prepares an input document containing order details as well as item details and builds an input request to make a remote API call to an external rules engine system, such as ODM.

The response received from the remote API is then processed and the createOrder transaction is called to create all the decomposed orders in the IBM Sterling Order Management System application. These decomposed orders are persisted in IBM Sterling Order Management System application as sales orders with parent-child relationship among them. At the end of the order decomposition process, a message is dropped into the build plan execution queue.

Execution and Fulfillment

When a message is received in the execution queue, an integration server triggers the order execution process by calling a custom API. The custom API creates the input document to make a remote API call to an external rules engine system, such as ODM to fetch the order execution sequence.

The response received from the rules engine is processed and the order execution sequence is persisted in the IBM Sterling Order Management System application.

Custom API implementation processes these dependencies and identifies the order with no dependencies as the order that are eligible for fulfillment process. To start fulfillment of eligible orders, the status of the eligible decomposed orders is changed to ‘Ready For Fulfillment’ using the ORDER_PROCESS transaction. All orders that are in ‘Ready For Fulfillment’ status are eligible to be picked up by any fulfillment system. Once the fulfillment system has finished processing these orders, it has to call IBM Sterling Order Management System to change the status of such orders to ‘COMPLETED’ using the ORDER_COMPLETE transaction. The ORDER_COMPLETE transaction is derived from changeOrderStatus and OnStatusChange event is activated and configured to invoke EvaluateOrderDependency service that updates dependency flag on relationships of all other orders that are dependent on the completed order.

A message is posted to the queue by invoking PostMsgToEvaluateDependencyQ service for each such updated order. An integration server picks up this message and calls a custom API that evaluates whether this order has no more pending dependencies. If the order is a decomposed order, its status is changed to "Ready For Fulfillment". If the order is a customer order, its status is changed to Completed, which ends the process.