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

IBM Sterling Order Management System – Hot SKU properties tuning

IBM Sterling Order Management has long been a leader in the e-commerce space. As most organizations move towards digital and marketplace platforms, order volume is increasing by many times yearly. For every implementation, the biggest concern is system performance. The inventory module is most critical area with respect to performance impact. The inventory module must maintain an accurate supply/demand and provide accurate ATP (available to promise).

IBM Sterling Order Management provides properties to increase system performance during availability check. By enabling properties which allow the system to minimize inventory locking, you’ll see substantial performance gains.

Business consideration

If your organization has a high peak order volume requirement for IBM Order Management software, you’re probably wondering how you can configure inventory properties to scale up the system. Can you meet these requirements without impacting system performance? Analyze following conditions before setting up the properties:

  • Number of concurrent transactions that require inventory locks.
  • Long inventory lock-holding times.
  • Presence of common inventory (SKU) in the orders of the concurrently running transactions.
  • Whether orders are real time or part of a batch.
  • Whether orders can be canceled or can be backordered at inventory lock timeout.

In this article, we’ll look at different use cases and explain how you can configure inventory properties, to meet business requirements. You learn how to get the most accurate availability picture without compromising system performance.

Properties to consider to tune the solution:

  • Hot SKU properties with or without the Optimistic Lock avoidance flag.
  • Old Hot SKU properties
Case study: High order volume

With a change in customer shopping habits, Organization A is increasingly focusing on online business. As a result, the organization sees very high order volume/throughput, or a sudden burst during peak holiday season.

Organization A projects a peak demand of up to 150k orders/hour (up to 750k order lines/hour) and common SKUs (Free Gift on $50 order) in most of the orders.

Objective: To process all orders in near real time and release to fulfillment node without any delay.

This is a unique case of very high transaction volume. This scenario causes inventory lock contention as the number of concurrently running inventory processing transactions (createOrder, schedule, release, and so on) are very high. To handle this high transaction volume, ensure that the system locks inventory only when required.

Key considerations
  1. Presence of common items: This is a key factor in deciding what type of optimization is required. For example, lock inventory every time or only at the low availability? In this use case, all the orders has one common item, our first choice would be lock item only at low availability. This ensures that the system avoids locking for most of the time. Use the property yfs.hotsku.lockOnlyOnLowAvailability as Y and yfs.hotsku.lockItemOnInventoryChanges as N. This enables the Optimistic Lock Avoidance feature.
  2. Multiple distribution nodes: If an organization has multiple fulfillment nodes (especially for the common item) additional tuning is required. To avoid further locking, consider using yfs.hotsku.useGranularLockingForItem. This creates lock records for a ship node – Item combination. Whenever availability at a ship node is low, a lock record is inserted for that Item-ship node. When the system is using the above node and the inventory is low, the system creates a lock record for the item-node combination.
  3. Requested quantity per order line: This is another deciding factor in setting up the inventory property (yfs. hotsku.qtyMultiplier). This property allows the system to determine the inventory level as high or low during the availability check. Organization A has a use case with ordered quantity less than 5 per order line, configure a lower value for yfs.hotsku.qtyMultiplier.
  4. Consider using the yfs.hotsku.updateInventoryAfterAPIOutput to reduce locking. If the update API is a part of large transaction, set this property as “N” , in this configuration inventory updates are only committed to the database at the end of the transaction. Note: By default this property is set to N and it is only applicable when yfs.hotsku.lockItemOnInventoryChanges is N.
Case study: Batch order processing

Organization B uses IBM Sterling Order Management to process batch orders. As a result, the organization sees a sudden surge of inventory transactions.

Organization B projects a batch of up to 200k orders with common items across orders. The order size is large with a multiple ordered quantity.

Objective: To process the complete batch within a specified time window.

This is a unique case of high transaction volume for a short duration. This scenario causes inventory lock contention as the number of concurrently running inventory processing transactions (createOrder, schedule, release, and so on) are very high. Also as the ordered quantity is high the system allocates a high quantity to a single order and potential of over-selling is also high in multi thread setup. Ensure that system acquires a lock while checking for availability.

To handle this scenario, ensure that the system locks inventory during availability/promising calls.

Key considerations
  1. Presence of high ordered quantity: This is a key factor in deciding what type of optimization is required. For example, lock inventory every time or only at the low availability? As in this use case, all orders have a higher quantity per line, we should not enable the locking only at low availability i.e Do not enable the OLA. Use the yfs.hotsku.lockOnlyOnLowAvailability as N and yfs.hotsku.lockItemOnInventoryChanges as Y. This disables the Optimistic Lock Avoidance feature and enables the traditional Hot SKU feature.
  2. Number of abnormal locks: This factor contributes towards the time system takes to turn a SKU hot. Organization B has a large order size and each transaction holds a lock for a longer duration, so it is advisable to keep this property as low as possible to turn the SKU hot. Configure yfs.hotsku.numberOfAbnormalLocksForSwitchToHotSKU as 1, the system turns the SKU hot starting second abnormal lock.
  3. Requested quantity per order line: This is another deciding factor in setting up the inventory property (yfs.hotsku.qtyMultiplier). This property allows the system to determine the inventory level as high or low during the availability check. Organization B has a use case of higher ordered quantity per order line, configure a higher value for yfs.hotsku.qtyMultiplier.
  4. BackOrder during sourcing/scheduling: Ensure that there is no requirement to cancel the order during sourcing/scheduling. The system should cancel the order only via Order Monitor. Fine tune the performance with following properties yfs.hotsku.useTimeOutLocking and yfs.hotsku.assumeUnavailableOnLockTimeout. By using these two properties you can reduce the lock contentions.
  5. Hot SKU item map size: Set the correct Hot SKU Item map size. Depending on yfs.hotsku.numRequestsInTrackingWindowToKeepAsHotSku and yfs.hotsku.maxItemMapSizeInMemory, system evaluates the map and keep only the latest items (up to the map size) in the map. If the organization has a large number of Hot SKU items, thenyfs.hotsku.maxItemMapSizeInMemoryset at a higher value. For example, setyfs.hotsku.maxItemMapSizeInMemory = 50000` to further increase the performance.
Case study: Low to medium order volume

Organization C wants to enable IBM Order Management with a large number of fulfillment nodes (500+). As a result, the sourcing logic is heavy and needs to be tuned to enhance performance.

Organization C projects a peak demand of up to 15k orders/hour (up to 45k order lines/hour) and can be sourced from any any Store, Distribution Center, or Vendor

Objective: To source the order from any available node, without respect to distance, shipment or cost.

This is a unique case of a heavy sourcing logic. The system needs to perform an availability check across multiple nodes. Order volume is less but the transaction boundary can be at higher side.

To handle this scenario, ensure that system locks inventory during availability/promising calls.

Key considerations
  1. Number of abnormal locks: This factor contributes towards the time system takes to turn a SKU hot. Organization C has a large transaction size and each transaction holds a lock for a longer duration, so it is advisable to keep this property as low as possible to turn the SKU hot. Configure yfs.hotsku.numberOfAbnormalLocksForSwitchToHotSKU as 1, the system turns the SKU hot starting second abnormal lock.
  2. Availability across nodes: As system is calculating availability across all nodes once, set the following property as yfs.hotsku.useAvailabilityAcrossNodes as Y. This allows the system to acquire the lock for a hot SKU only when the availability across all nodes is below the safety level.

Note: If the distribution group in a sourcing rule has high number of nodes then for OLA, the above property setup as Y and granular locking is enabled system creates records for all item-node combination records in INV_INVENTORY_ITEM_LOCK.

Explanation: Hot SKU feature with optimistic lock avoidance

Before checking for inventory availability, the transaction checks the INV_INVENTORY_ITEM_LOCK table to see if a record is present for the SKU, Node, and demand type combination that corresponds to the demand that the transaction eventually creates. If there is a record for RESERVED demand in this table, and an order is being scheduled, which uses the SCHEDULED demand type, locking does not occur. If there is no record present, then the transaction does not lock during availability checks.

Example 1: OLA with granular locking

yfs.hotsku.lockOnlyOnLowAvailability=Y
yfs.hotsku.useGranularLockingForItem=Y
yfs.hotsku.useAvailabilityAcrossNodes = Y

Locking for Inventory Updates: No Locking Locking For Availability Check: Locking on INV_INVENTORY_ITEM_LOCK table

Consider the sourcing config sequences: DG1 has 3 Nodes (Node1,Node2, Node3) DG2 has 2 Nodes (Node4, Node5)

Item1 has high availability

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
——————- ———– ———- ————————-

Transaction 1: As availability is high (no records in the INV_INVENTORY_ITEM_LOCK table), system does not lock the item and calculate the availability. If the availability is low across DG1 then system inserts a record in the table for all the Nodes from DG1. As availability across DG2 is not low, system wont insert any record for Node4 and Node5.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 20 Node1
201908090238024314277816 RESERVED 20 Node2
201908090238024314277816 RESERVED 20 Node3

The above also means, if a request is required to check availability only at Node4 or Node5, it does not lock and proceed without any locking of inventory item for availability check.

Transaction 2: As availability is low for DG1, system locks the record of SKU-DemandType-Node(s) in INV_INVENTORY_ITEM_LOCK while calculating the availability for Node1-3. If system doesn’t find availability from DG1 then it checks in DG2 (without any locking). If the availability is even low across DG2 then system inserts a record in the table for all the Nodes from DG2.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 20 Node1
201908090238024314277816 RESERVED 20 Node2
201908090238024314277816 RESERVED 20 Node3
201908090238024314277816 RESERVED 20 Node4
201908090238024314277816 RESERVED 20 Node5

Transaction 3: During availability calculation if system determines a high availability for Node3 then it deletes the record for Node 3.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 20 Node1
201908090238024314277816 RESERVED 20 Node2
201908090238024314277816 RESERVED 20 Node4
201908090238024314277816 RESERVED 20 Node5

Thus, granular locking only locks the record in INV_INVENTORY_ITEM_LOCK if the availability is low on all the nodes being referred in current transaction. Else if does not lock for availability check.

Example 2: OLA without granular locking

yfs.hotsku.lockOnlyOnLowAvailability=Y  
yfs.hotsku.useGranularLockingForItem=N  
yfs.hotsku.useAvailabilityAcrossNodes = Y

Locking for Inventory Updates: No Locking Locking For Availability Check: Locking on YFS_INVENTORY_ITEM table

Consider the sourcing config sequences: DG1 has 5 Nodes (Node1,Node2, Node3, Node4, Node5 ) Note: Hot SKU OLA (without Granular locking) works well only with single distribution group. If the organization has multiple distribution groups then useGranularLockingForItem needs to set as Y only.

Item1 has high availability

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
——————- ———– ———- ————————-

Transaction1: As availability is high (no records in the INV_INVENTORY_ITEM_LOCK table), the system does not lock the item and calculate the availability. If the availability is low across DG1 then system inserts a record in the table. It creates the record without any ship-node.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 10

This also means that if the current availability call is required to check availability at only 1 node which has low inventory for that SKU, the lock record is inserted and any transaction can now lock. However, this determination happens for each demand separately.

Transaction2: If the availability for item becomes 0 across nodes, the record in the table is updated with purpose 11.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 11

If the lock record is observed with purpose 11, availability calls stop locking again as item is assumed to be unavailable now.

Transaction3: During availability calculation if system determines a high availability for all the nodes, then it updates the record purpose to 10, if the existing state was with purpose 11.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
201908090238024314277816 RESERVED 10

Transaction4: During availability calculation, now if availability is high and system finds the record with purpose 10, then it deletes the record.

INVENTORY_ITEM_KEY Demand Type Purpose Ship Node
——————- ———– ———- ————————-

Therefore, the Hot SKU OLA (without granular locking) works best with single sourcing sequence DG with potential all nodes. If availability checks can have different DGs, ship nodes, and so on then locking is not optimized.