Think 2021: New tools have the developer ecosystem and IBM building together Learn more

Use IBM Order Management for complex sourcing requirements

Sourcing is the process of determining from which node or supplier to ship a product. In a simple use case, where there is a single shipping node, then you can predefine that node to ship products. No sourcing configuration is required. If there isn’t a predefined node, then sourcing configuration is required to identify the fulfillment node.

Use IBM Order Management to meet complex fulfillment requirements with minimal customization logic and without impacting system performance. IBM Order Management provides the following sourcing and scheduling options, which help your organization meet most common requirements:

  • Date-based fulfillment optimization
  • Priority-based fulfillment optimization
  • Cost, shipment fulfillment optimization

Some complex requirements need additional configuration and logic.

This article demonstrates how to configure default sourcing and scheduling rules to meet a few complex requirements. You will learn how to:

  • Minimize extension, customization, and user exit implementations
  • Improve performance
  • Meet complex sourcing requirements
Case Study 1: Complex sourcing

Sourcing objective

An organization has two nodes types: distribution center and store. There are 3 distribution centers and each has different priority, from 0 to 2. All Store nodes have the same priority, 3. This priority is lower than any distribution center.

When optimization is set to Priority:

  1. The system uses the scheduling rule configuration. Weighing is determined based on the weighting of the Node priority, and the weighting of distance. If the distance weighting is set to 0, then distance is not used to calculate priority.
  2. If there are multiple locations with the same priority, the system selects a location based on minimal number of shipments.
  3. If multiple locations have inventory for the order, then the system selects the location that is closest to the shipping address (provided that the ship date is the same across all locations).


Requirement: When possible, fulfill from a distribution center. If not possible, check for inventory in stores. If inventory is filled from stores, then minimize the number of shipments.

Business expectation

To minimize the number of shipments, the sourcing logic selects store 2.

Item A: Required quantity 8
Node Priority Availability Expected allocation
DC1 0 2 2
DC2 1 3 3
DC3 2 0
Store1 3 2
Store2 3 10 3
Priority-based fulfillment optimization

The priority-based optimization logic has the following sequence: Priority, Cost, Number of Shipments, Date. To optimize sourcing, the distance is weighted. In the following scenario, the system chooses both store 1 and store 2.

Priority-based fulfillment optimization

Item A: Required quantity 8
Node Priority Availability Allocation
DC1 0 2 2
DC2 1 3 3
DC3 2 0
Store1 3 2 2
Store2 3 10 1
Cost, shipment fulfillment optimization

The cost, number of shipments-based optimization has the following sequence: Number of shipments by cost, priority, date. Based on this sequence, the system selects Store 2 and skips all distribution centers.

To meet business requirements, consider additional options related to shipment and priority.


Item A: Required quantity 8
Node Priority Availability Allocation
DC1 0 2
DC2 1 3
DC3 2 0
Store1 3 2
Store2 3 10 8


Enable Cost-based fulfillment optimization — The option uses optimization logic configured based on landed cost (Cost of Node type, Node Priority, Number of shipments, Shipment delay and so on).

Cost-based fulfillment optimization

You can define a real cost or use dummy cost parameters.

Options to consider:

  • Node handling Cost factor: Depending on the priority of the Node, you can configure the lower cost for the highest priority Node type. In our scenario, the distribution center has a lower cost per shipment compared to Store. Since the system will calculate a higher cost for the shipment at a Store, the distribution center is given preference (Req # 1). Handling cost
  • Convert Node Attribute into Cost: Depending on requirement, you can configure values to convert Node attributes into cost to calculate correct cost to get preference to any sourcing need. For example, Shipment Delay Cost can be configured to provide preference to the product availability date or for date-based sourcing. If there is a longer delay, the system will give lower preference to that node (Req # 3). Convert Node Attribute
  • Node Priority Cost: The Node Priority Cost Factor converts the node priority level to a currency, such as dollars, and determines the importance of the node priority cost in the overall cost calculation for sourcing at the node (Req # 1).
  • Use Node attribute Costs Per unit basis: This setting allows the system to calculate the cost based on each unit. When there is a tie on the Distance and Number of Shipments, the system gives higher preference to the node which fulfills more units (Req # 2).

These examples illustrate how you can implement complex sourcing requirements by using dummy cost factors.

Case Study 2: Performance enhancement

Sourcing objective — Source the orders to any node within a given radius.

IBM Order Management provides flexibility to ship or source individual lines from different nodes. To do this, the system calculates the distance of all shipnodes for every line. Then, the system filters nodes within X miles. That is, the system lists the Nodes, then calculates the distance to the Ship To address, and filters out nodes.

The system calculation takes between 20-30ms per line. For large orders, the total time will degrade system performance.

Solution design consideration

To improve performance, implement the getSourcedFromNodesExternallyUE user exit and Ehcache.

Sourcing sequence

As part of the solution, the system reads the ShipTo Zipcode and calls the getSurroundingNodeList API to list all eligible nodes. The list is saved at JVM level (Ehcache). All subsequent calls will read the node list from cache.

Note: In one implementation, there was a 10-fold improvement in calculation time (3-4ms).

Case study 3: Performance enhancement

Sourcing objective

Source the orders to the closest node ZipCode. The coordinates are not maintained within IBM Order Management.

The calculation of distance between ShipFrom and ShipTo locations for each order line can be external to IBM Order Management.

Enable the YFSGetDistanceUE user exit to implement any external API to get the distance or zip-code coordinates. The system invokes the YFSGetDistanceUE user exit for x*y times per order where x is the number of sourcing nodes (configured in the sourcing template), and y is the number of order lines.

This implementation is not scalable. The API performance will degrade unless the organization uses smart sourcing.

Solution design consideration

IBM Order Management can obtain latitude and longitude coordinates from the YFS_PERSON_INFO table (and secondarily from the YFS_ZIP_CODE_LOCATION table). If you pass latitude and longitude to the Order create message by using the PersonInfoShipTo element, then the system can get the ShipTo and ShipFrom coordinates from the YFS_PERSON_INFO table. By using these coordinates, the system calculates the distance. As a result, scheduling can select the appropriate node to source from.