Best practices for improving order performance

You can implement best practices to improve the performance of all orders and additional best practices to improve the performance of orders that exceed 20 order lines.

To improve the performance of all orders, implement these best practices:
  • Extend out-of-box templates to use the minimum required elements and attributes. Ensure that you tune all out-of-box templates, such as templates for events, hold type conditions, manager overrides, user exits... For example, consider modifying the following templates:
    • Events. For example, modify the ORDER_CHANGE.ON_SUCCESS event template to include only the OrderHeaderKey attribute.
    • User exits. For example, if you are not using item details and order releases in your pricing logic, tune the YFSOrderRepricingUE template to exclude ItemDetails and OrderReleases.
    • Hold conditions. For example, tune the Order_Line_Hold_Condition.xml file to include only the following attributes: <OrderLine OrderedQty=""><<LinePriceInfo LineTotal=""/><Item ItemID="" UnitOfMeasure="" /></OrderLine>
    • Manager overrides. Tune Manager Overrides templates to include only the attributes that are required by validation rules. For example, tune a template to include only the following attributes: <OrderLine OrderLineKey="" OrderedQty=""> <SelectionCriteria CustomerType="" /> <Item ItemID="" UnitOfMeasure="" /> <LineOverallTotals LineTotal=""/> <Order BillToID=""> <PriceInfo Currency=""/> </Order></OrderLine>
  • If an event is not time urgent, configure the event to be asynchronous. To configure an event, extend the event template to include only the OrderHeaderKey, put OrderHeaderKey into a JMS queue, and start an integration server to process requests, such as calling getOrderDetails. This configuration allows the createOrder and changeOrder APIs to process time-sensitive requests synchronously and other requests, such as sending emails, asynchronously.
  • The changeOrder event template is modified to show modified lines, and the ORDER_CHANGE.ON_CANCEL event template is modified to show canceled or deleted lines. Tune these templates to show only the modified or deleted lines. Thus, when a UI calls changeOrder or ORDER_CHANGE.ON_CANCEL to refresh order lines on a page, only modified or deleted lines are displayed.
  • To display order details in a UI, avoid displaying order line elements and use getOrderLineList to show only the lines for the current page. For example, use getOrderLineList to display up to 30 lines per page.
  • To reduce the level of inventory locking, enable Hot SKU. For information, see Performance feature - hot SKU.
  • Increase the order audit batch size by setting the following properties:
    • yfs.yfs.YFS_ORDER_AUDIT.batchsize=100
    • yfs.yfs.YFS_ORDER_AUDIT_LEVEL.batchsize=100
    • yfs.yfs.YFS_ORDER_AUDIT_DETAIL.batchsize=100

    To override properties, use the customer_overrides.properties file.

Orders that exceed 20 order lines: best practices for improving performance

You can improve the performance of orders that exceed 20 order lines.

Note: By default, Sterling Order Management System Software defines orders that exceed 20 order lines to be large orders. However, based on your business needs, you can define large orders to be orders with any number of order lines. Use the LARGE_ORDER_SIZE rule in the manageRule API to set the number of order lines for a large order. When you set this rule, ensure that you specify EnterpriseCode and DocumentType.
To improve performance of large orders, implement these best practices:
  • Delay indexing of large orders by setting the DELAY_LARGE_ORDER_INDEX rule to "Y" in the manageRule API. When you set this rule, indexing is delayed for large orders only, which are defined by the LARGE_ORDER_SIZE rule in the mangeRule API. After you set the DELAY_LARGE_ORDER_INDEX rule, call the API and trigger the SSI_DELAYED_SYNC agent. Ensure that you specify an enterprise code and document type when you configure the DELAY_LARGE_ORDER_INDEX rule. The index is generated when the agent picks up the YFS_AWAITING_INDEX record for the order. For example, if you configure the agent to be triggered every 5 minutes, it might take at least 5 minutes before the order appears in the index.
  • Configure Sterling Order Management System Software to update inventory asynchronously for large orders.

Update inventory asynchronously

To improve response times for large orders, you can configure Sterling Order Management System Software to update inventory asynchronously. Typically, when an order is created or modified, the order APIs perform inventory updates synchronously. However, if you configure asynchronous inventory updates, the order APIs call the Large_Order_Inventory_Update_Publish service when a large order is created or modified.

To update inventory asynchronously, the Large_Order_Inventory_Update_Publish service pushes an XML message to a JMS queue. The message contains information about the inventory changes that are needed after the order is created or modified. The Process_Large_Order_Inventory_Updates integration server monitors the queue, picks up the message, and starts the Large_Order_Inventory_Update_Process service, which calls a custom API, updateInventoryForOrderModifications. The custom API performs the inventory updates that the order APIs ignored during order creation or modification.

Asynchronous inventory updates are triggered only for large orders and are restricted to the following order APIs:
  • confirmDraftOrder
  • createOrder
  • changeOrder
Figure 1 shows the process flow for asynchronous inventory updates.

Figure 1. Process flow for large order asynchronous inventory updates
A flow diagram depicting the process flow for large order asynchronous inventory updates.
To enable asynchronous inventory updates for large orders, follow these steps:
  1. In the Applications Manager, configure the Large_Order_Inventory_Update_Publish service and the Large_Order_Inventory_Update_Process service to use the same JMS queue. To configure a JMS queue for a service in Sterling Order Management System Software, follow these steps:
    1. From the Applications menu of the Applications Manager, click Application Platform.
    2. From the tree in the application rules side panel, double-click Process Modeling.
    3. Click the General tab. In the Process Types swimlane, right-click the General process type, and click Model Process. The Repository Details window and work area display for the General process type.
    4. Click the Service Definitions tab.
    5. Expand the Asynchronous Inventory Updates branch.
    6. Right-click the service, and click details. For example, if you are configuring the Large_Order_Inventory_Update_Publish service, right-click Large_Order_Inventory_Update_Publish. The Service Detail window displays in the work area.
    7. Depending on the service you are configuring, click JMS sender or JMS receiver and enter the values for the JMS queue parameters.
  2. Call the manageRule API to set the LARGE_ORDER_INVENTORY_UPDATE_SERVICE rule to "Large_Order_Inventory_Update_Publish". The organization code and document type are mandatory for this rule.
  3. For organizations that are not the default organization or orders that are not a sales order (0001), configure a hold that is resolved by the UPDATE_ORDER_INV_ASYNC transaction. Ensure that the hold prevents other transactions from being executed, such as the SCHEDULE transaction, and prevents inventory-related modifications from occurring on the order. Sterling Order Management System Software provides the PENDING_INV_UPDATE hold for the DEFAULT organization.
  4. Start the integration server by running the following command:

    <INSTALL_DIR>/bin/startIntegrationServer.sh Process_Large_Order_Inventory_Updates

Note:

Asynchronous inventory updates are not applicable for order line reservations.