Order orchestration workflow spawning a rule-based order
You can review the high-level order orchestration workflow of a rule-based order.
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:
OnSuccessevent of the
ORDER_CREATEtransaction. 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_PROCESStransaction is a derived
OnStatusChangeevent is configured to place a message in the decomposition queue.
- If the validation fails, the
ORDER_PROCESStransaction is called to change the order status to Suspended (Awaiting Validation) and an exception of ExceptionType as OrderValidationException is created using the createException API.
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
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’
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
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.