Order orchestration: decomposition services

After an order has been validated successfully, order decomposition is the next step in the order orchestration process. The decomposition process is triggered by successful validation of an order. IBM® Sterling™ Order Management System Software application uses a set of services for performing order decomposition.

The list of services used in the order orchestration decomposition process are as following:
Table 1. List of services used in the order orchestration decomposition process
Service Name Description
TriggerDecomp Service to listen for message received from the validation service Or triggered to retry. The validation process sends the required order information to the decomposition process by invoking TriggerDecomp service. The TriggerDecomp service calls custom API, ProcessOrderDecomp.
ProcessOrderDecomp Custom API that performs the decomposition process. The custom API that prepares input for decomposition request and invokes business rules using InvokeDecompRules service as well as processes the decomposition response from the rules engine.

The ProcessOrderDecomp API calls the getOrderDetails and getItemList APIs to fetch the complete order information using an extensible template, getOrderDetailsForDecomposition. The output of the two API outputs is combined into one document.

The output of the ProcessOrderValidation API is sent to the mapping service, PrepareMappingForDecomp that can be implemented to transform the XML to a format understood by the rules engine.
PrepareMappingForDecomp This placeholder mapping service is provided to transform order data to a format understood by the rules engine to create the decomposition request.

After the decomposition message has been prepared, InvokeDecompRules service is invoked.

InvokeDecompRules Custom API to create input for decomposition and invoke rules engine using a common service, InvokeBusinessRule. This service builds the final request with header and data.
The output element from the InvokeDecompRules should be as follows:
<DecompOrderList OrderHeaderKey=“RootOrderKey” OrderNo=“RootOrderNo” EnterpriseCode=“Required”>
    <Order CustomerPONo=”{root OrderNo}” ShipToKey="{root ShipToKey}" ShipToID="{root ShipToID}" BillToKey="{root BillToKey}"
           BillToID="{root BillToID}" SellerOrganizationCode="{root SellerOrganizationCode}" OrderNo="Required" 
           OrderType=“ResourceOrder|ServiceOrder|ProductOrder” OrderDate="" EnterpriseCode="{root EnterpriseCode}" 
           DraftOrderFlag="N">
        <OrderLines>
            <OrderLine PrimeLineNo=“” SubLineNo=”” OrderedQty=“”>
                <Item UnitOfMeasure="" ProductClass="" ItemID=" "/>
                <CustomAttributes/>
            </OrderLine>
        </OrderLines>
        <ParentOrder OrderNo=“Required”/>
        <CustomAttributes/>
    </Order>
.
.
.
</DecompOrderList>

Required elements in bold and elements in brackets ({}) must be provided. If the @OrderType is not passed, it is defaulted to ProductOrder. If any attribute is not passed but can be defaulted from the parent order, such as @DocumentType, @EnterpriseCode and @BillToID, those attributes are fetched from the parent order.
ProcessDecompResponse Invokes multiApi to create orders and relationships. A custom API takes the rules engine output and invoke createOrder API for each of the child orders. The @OrderType attribute may be used for pipeline determination. Prior to calling createOrderAPI, a defaulting logic fills in any missing basic information using the original order.

A relationship map is created from the output document from the rules engine and the createOrder API output, which connects the OrderHeaderKeys of the created orders with the provided OrderNo from each order. This relationship map is used to call multiApi to create the relationships between the orders.

The Parent-Child relationships are created using the information available in the <ParentOrder> element. The original order is defined as the root level order, and orders can either specify it or another order in the output as their parent. If the parent of an order is not specified, or the order lists itself as its own parent, the parent for the order is defaulted to the root level order.

The <ParentOrder> and @OrderNo must refer to an order in the output from the rules engine. If the order it refers to cannot be found, an exception is thrown. And if there is a cyclic dependency, such as child order -> first parent -> second parent -> child order, an exception is thrown. The Order element XML is the same as createOrder XML and can contain any elements from this API, with the addition of the required <ParentOrder> element.
PostMsgToBuildPlanQ Service to post messages to execution or build plan queue.

Viewing decomposition services

To view the decomposition services, perform the following steps:
  1. From the Application Console menu, click Configuration > Launch Applications Manager. The Applications Manager opens in a new window.
  2. From the menu, click Applications > Application Platform.
  3. From the tree in the application rules side panel, double-click Process Modeling. The Process Modeling window displays in the work area.
  4. Select the Sales Order tab to view the corresponding process modeling tree for that base document type.
  5. In the Process Types swimlane, right-click on the Sales Order process type and choose Model Process. The Repository Details window and work area display for the process type.
  6. Choose the Service Definitions tab and expand the Decomposition service group.