Overview of the inventory process flow

In the Sterling Order Management integration with IBM® WebSphere® Commerce, Sterling Order Management maintains, and provides inventory information to, the WebSphere Commerce Inventory Cache. The two systems interact with each other through APIs and services that are supplied as part of the integration.

The following diagram and description explains these services and the inventory process flow.

Inventory Process Flow

The following steps describe the Inventory Process Flow diagram.

When a Web shopper on the WebSphere Commerce Store website is browsing items for availability, this shopper might want to have these items shipped or might want to pick them up in a store.

  1. If the Web shopper wants an item to be shipped, WebSphere Commerce first checks local Inventory Cache for availability of that item.

    Sterling Order Management periodically communicates inventory changes to the WebSphere Commerce Inventory Cache. Sterling Order Management uses the Real-Time Availability Monitor (RTAM) time-triggered transaction, which is configured in the Service Definition Framework (SDF), to publish inventory information when inventory levels change within specified thresholds. To publish this information, RTAM invokes the REALTIME_AVAILABILITY_CHANGE event, which in turn invokes the SCWC_sendInventoryChanges service to update the WebSphere Commerce Inventory Cache.

    1. If the inventory is available, WebSphere Commerce provides this availability information back to the shopper.
    2. If the inventory is not available, WebSphere Commerce makes a synchronous call to pull inventory information from Sterling Order Management by issuing the getInventoryAvailability request, which is mapped by the IBM WebSphere Enterprise Service Bus mediation module to the monitorItemAvailability API.

    When the shopper adds an item to the cart, WebSphere Commerce rechecks inventory, considers the ordered quantity and the inventory quantity, and displays the corresponding inventory status. Regardless of status, the shopper can add the item to the shopping cart.

  2. If the Web shopper wants to check availability and pickup items in a store (Buy-Online-Pickup-In-Store, or BOPIS), WebSphere Commerce ignores its local Inventory Cache and calls the getInventoryAvailability outbound service directly. In this scenario, the findInventory API is called to obtain the real-time availability of the inventory in the store.
  3. When the Web shopper adds items to the cart and proceeds to check out, WebSphere Commerce needs to reserve inventory for items in the cart. In this case, WebSphere Commerce calls the processInventoryRequirement request, which is mapped to the reserveAvailableInventory API. The results of the call are sent back to WebSphere Commerce.
  4. The cart is locked when the shopper is checking out. If the shopper decides to delete a reserved item from the shopping cart, WebSphere Commerce calls the processInventoryRequirement request, which is then mapped to the cancelReservation API. This service cancels the inventory reservation.

    If the shopper abandons the cart, the cancelReservation API is called only if the expiration period is defined in the Sterling Order Management Global Inventory Rules.

  5. Apart from this shopping scenario, WebSphere Commerce can pull inventory information from Sterling Order Management when criteria for item availability are not met in its local Inventory Cache. In this case, WebSphere Commerce makes a direct API call for monitorItemAvailability so that it can update the WebSphere Commerce Inventory Cache.

When all of the Web shopper’s inventory activities are finished, the shopper is ready to order items.