Provide consistent and accurate availability information to customers
Deploying the Promising and Inventory Hub
This content is part # of # in the series:
This content is part of the series:
Stay tuned for additional content in this series.
Promising and Inventory Hub allows your organization to provide a single source of truth so that you can make accurate promises to customers. Customers view a retailer as a single brand. Customers expect seamless integration across all retail channels, including websites, physical stores, mobile stores, and call centers. Because a single customer’s shopping experience can cover numerous channels, it is essential to provide consistent answers to availability inquiries, regardless of the channel and touch point the customer is interacting with. Traditionally, promising and inventory capabilities have been deployed as part of an order management system. As a retailer acquires additional businesses and overall volumes increase, a single deployment model might not be able to address business and IT needs. Retailers need to share inventory among multiple channels and newly acquired businesses, expand their marketplace presence, and provide multiple fulfillment options, while minimizing inventory stored in warehouses.
Most order management deployments are single-instance deployments, as shown in Figure 1. In this deployment, order management is deployed together with the Promising and Inventory Hub in a single instance. Data for orders and for inventory reside in a single database. In such a deployment, the mid-tier application server cluster is horizontally scalable. If you increase the size of the cluster, you can handle higher volumes. However, the database can potentially become a bottleneck if volumes significantly increase. A deployment based on shards can reduce bottlenecks.
Figure 1. Single instance deployment
In a shard-based deployment, as shown in Figure 2, orders can reside in multiple database instances (also called shards), but they can be accessible within a single deployment instance. Orders are split into different shards based on the enterprise of the order. For instance, orders with the WEB enterprise might go to a WEB shard, but orders with the RETAIL enterprise might go to a RETAIL shard. Multiple enterprises that reside in different shards can share the configuration data because all configuration data has a dedicated common shard in a given deployment. In this example, configuration data resides in a separate shard called CONFIG that is shared by both enterprises: RETAIL and WEB.
Figure 2. Shard-based deployment
A current limitation of a shard-based deployment is that inventory information must reside in the same instance as order data. If two enterprises need to share inventory, they must reside in a single shard. Deploying a separate Promising and Inventory Hub addresses this limitation.
Additional benefits of deploying a separate Promising and Inventory Hub include:
- Independence of upgrade – You can run the Promising and Inventory Hub instance on a different Sterling Selling and Fulfillment Suite version from the instance on which the order hub is deployed. However, there are some limitations on the compatibility of Sterling Selling and Fulfillment Suite.
- Easier to size – You can size the hardware requirements for the Promising and Inventory Hub more accurately, because it has no order processing and does not store orders in the database.
- Single source of availability – You can expose the services from the Promising and Inventory Hub to other business channels that use legacy or other order management systems. Exposing such services has no impact on the Sterling order hub, because it runs in a separate instance.
- Reduced inventory locking – In a single-instance deployment, inventory item records are locked for the duration of each order transaction. The duration depends on many factors, such as the size of the order, delays due to integrations to external systems, and so on. When a Promising and Inventory Hub deployment is used, order transactions from the order management system instance call inventory APIs in the Promising and Inventory Hub. The inventory locks are held only for the duration of the inventory API processing. When the inventory API completes, the inventory locks are released.
Architectural view of the Promising and Inventory Hub
You can deploy the Promising and Inventory Hub independently from order management and other related systems, as shown in Figure 3.
Figure 3. Independent Promising and Inventory Hub
The Promising and Inventory Hub has the following responsibilities:
- Maintaining supply and demand data for all business units or channels
- Providing services for all availability calculations
- Maintaining all sourcing and scheduling configuration rules
- Publishing availability information to e-Storefronts
However, the Promising and Inventory Hub does not have the responsibility to maintain any orders.
The Order Hub has the following responsibilities:
- Maintaining orders
- Scheduling and releasing orders
- Calling out to the Promising and Inventory Hub for all availability inquiries
- Calling out to the Promising and Inventory Hub for all inventory updates
e-Storefronts have the following responsibilities:
- Accepting availability information from the Promising and Inventory Hub
- Calling out while making reservations to the Promising and Inventory Hub
When you use the Promising and Inventory Hub availability and inventory services, all your channels can share the same inventory, regardless of which system queries for availability. There are well-defined and documented APIs that provide fulfillment options to address various customer requests, such as:
- “Can I pick an order up tomorrow in a store near my home?”
- “Why is this product not available until two weeks from now?”
- "How much back-ordered demand was created during a promotional sale?"
Warehouse updates of supply availability are loaded into the Promising and Inventory Hub. All demands are modeled as inventory reservations, because there is no order information present. During promising inquiries, availability is calculated as follows:
- Demand (from reservations) is subtracted from supply.
- Sourcing and scheduling constraints are applied.
- Optimizations are applied to provide the best fulfillment options to the customer or to provide multiple fulfillment options from which the customer can select.
Promising and Inventory Hub is an instance of Sterling Order Management. Typically, a customer installs two instances of Sterling Order Management. One instance is used as an Order Hub, where orders are created and fulfilled. Another instance is used as the Promising and Inventory Hub; it maintains inventory and availability configurations. Installations for these two instances are identical. Follow the product installation guide when you install.
Alternatively, you can have a single instance of Sterling Order Management and use it as the Promising and Inventory Hub, without installing another instance for order management. This option might appeal to you if you want to deploy the Promising and Inventory Hub without changing or impacting your order processing flows.
After you install two order management system instances, you must configure integration between the systems. Integration consists primarily of two parts:
- Availability checks
- Demand and supply updates
When orders are scheduled and released, the system checks for availability and determines the optimal promise for an order (ship node, shipping date). Schedule and Release agents run on the order management instance and call YFSGetExternalAvailabilityUE synchronously. The user exit calls the reserveAvailableInventory API on the Promising and Inventory Hub. The reserveAvailableInventory API makes all the sourcing determinations and creates reservations to ensure that the promise is blocked and no other order can consume the already promised supply. Similarly, during a createOrder API call, if order line reservations are present, order management calls the Promising and Inventory Hub and creates corresponding reservations on Promise and Inventory Hub.
Other APIs on the Order Hub might include inquiry APIs, such getPossibleSchedules or getFullfilmentOptionsForLine. These APIs also call a YFSGetExternalAvailabilityUE. On the Promising and Inventory Hub, however, the call is mapped to the findInventory API, because reservations do not need to be updated. To differentiate between two API calls on the Promising and Inventory Hub, the XML that is input to the user exit can use the IsIntendToUpdate attribute. This attribute conditionally calls the reserveAvailableInventory API or the findInventory API. Make all availability checks synchronously.
Supply and demand updates
As orders flow through the pipelines and as order changes are made, order status changes generate demand and supply updates. The mapping between status and supply and demand types is maintained in Order Hub under status inventory types. All APIs that cause order status changes raise the following events:
Make demand changes on the Promising and Inventory Hub by using the reserveItemInventory API. Use the adjustIventory API on the Promising and Inventory Hub to reduce supply (for instance, during shipment confirmation). To maintain data integrity, when an operation adjusts the supply and demand on the Order Hub, the adjustments must also be made on the Promising and Inventory Hub in a single transaction boundary. You can write a custom API to process these requests within a single transaction boundary. Alternatively, you can implement only the EXTERNAL_DEMAND_CHANGE event. With this event, a demand change that is due to a shipment confirmation sets the ConfirmShipment attribute to Yes. When the ConfirmShipment attribute is Yes, you can reduce both the demand and the corresponding supply.
The order management hub can make supply and demand update calls that are either synchronous or asynchronous. Figure 4 summarizes the integrations required between the order management hub and the Promising and Inventory Hub:
Figure 4. Integrations between hubs
Integration options for managing workload
All promising APIs make a callout to YFSGetExternalAvailabilityUE and raise an EXTERNAL_DEMAND_CHANGE event. In most implementations, you can avoid some of the callouts to reduce the overall load on the Promising and Inventory Hub.
One way to reduce the load is by reserving all orders as part of an order creation service. When orders come from various channels, they are first reserved using the reserveAvailableInventory API on the Promising and Inventory Hub. After orders are reserved, there is no need to check for availability during the scheduling or release processes. You must implement YFSGetExternalAvailabilityUE to return the promise request as available, based on the order line reservations that are passed in the input XML <Reservations> element to the user exit.
When only ONHAND inventory is considered for promising and no procurement orders are used, you do not need to update demands during schedule and release. The ScheduleOrder API goes to the Promising and Inventory Hub only for orders that do not have order line reservations. However, this scenario is an exception, since most orders have Order Line Reservations. With a simplified integration, the Order Management Hub can call out to the Promising and Inventory Hub in the following places:
- During the original reservation in the create order service
- During the release process (this is optional) to change the demand type from promised to allocated
- During shipment confirmation to reduce demand and supply
This approach has limitations, but it can be used in many customer implementations.
In a traditional installation, all order updates and inventory updates occur as part of the same transaction boundary. As a result, the entire API completes successfully or it gets rolled back. For instance, you cannot have a scenario where demand gets created in a database, but the order does not get created.
In a distributed deployment, there is a potential for demands to be updated even though order updates did not go through successfully, and vice versa. Figure 5 shows the interactions that occur during a Schedule transaction. Similar interactions occur in other API calls, such as the createOrder API.
In Figure 5, the numbers 1-8 indicate key places during the execution of an API where failures could occur. At the end of each transaction or API call the system issues a commit, at which point all changes are committed to database or JMS queues.
- If the failure occurs before a call to the Promising and Inventory Hub (before point #1), then the entire API is rolled back. There is no processing on the Promising and Inventory Hub.
- If the failure occurs on the Promising and Inventory Hub during reserveAvailableInventory API execution (between points #2 and #3 in Figure 5), then data on that server is rolled back. Because the call is synchronous, the API call on the order management hub is also rolled back.
- If the failure occurs on the order management hub during reserveAvailableInventory API execution (between points #2 and #3 in Figure 5), the order API is rolled back, but the Promising API succeeds. As a result, a demand exists on the Promising Server but a corresponding order does not exist. One option for handling such demands is to pass an expiration date to the Promising and Inventory Hub during the reservation. Each reservation is created with an expiration time (for instance, 1 hour). Unless a subsequent update to the reservation occurs within that time, an inventory purge removes the demand. This option requires a system to raise an additional event during the order update (point #5). As part of the event, the expiration date is moved to a high date, so that the reservation never expires.
- If a failure occurs during order update, after the ReserveAvailableInventory call is complete (between points #3 and #5 in Figure 5), then any order changes are rolled back, but promising changes are committed. Use a solution similar to the one described in the previous bullet to correct the inventory.
- After order updates (when point #5 is reached in the execution of the API), the system raises the ON_DEMAND_CHANGE event and publishes the message into the queue. At the end of the API execution on the order management side (at point #8 in Figure 5), a commit occurs on the database and on the queue. The message is read asynchronously from the queue and the expiration date of the reservation that was already created is adjusted to a high date. If the commit fails, order changes are rolled back, similar to previous failures.
- If a failure occurs during a reserveItemInventory API call (between points #6 and #7 in Figure 5), then the message on the Promising and Inventory Hub is not processed and is left in the queue. Assuming persistent queues, the integration server picks up the message again after the configured time interval and attempts to reprocess it. However, these failures do not impact the order processing, because the message on the Promising and Inventory Hub side is processed asynchronously.
Figure 5. Interactions during a Schedule transaction
Configuration and master data
All promising, scheduling, and inventory configurations, such as sourcing rules, scheduling rules, and available-to-promise (ATP) rules, are defined in the Promising and Inventory Hub. Configurations related to orders, such as order pipelines, payment configuration, and others, are defined in the order management instances. You must ensure that common configuration data, such as organization or ship nodes, are kept in synch with the order management system and the Promising and Inventory Hub. Also, depending on the implementation, you might need to ensure that master data is replicated. Replicated data includes:
- Item, if item attributes are used for promising or inventory
- Customer, if the customer scheduling preferences are defined
Use the Configuration Deployment Tool to extract data from one instance to replicate to the other instance.
Configuring performance and availability
The Promising and Inventory Hub is a critical resource to one or more channels. To protect the availability of the hub, ensure that your solutions architecture addresses the following requirements:
- Performance and scalability
- High Availability
Performance and scalability
The performance recommendations and best practices for traditional order management system deployment also apply to the Promising and Inventory Hub. In addition, consider these recommendations when you develop your deployment architecture:
- Create different application clusters for each channel, so you can isolate workloads by their source. This configuration allows for easier monitoring, management, and tuning. For example, you can create a cluster for all promising and inventory transactions from the web channel, a second cluster for transactions coming from the order management application, and additional clusters for other purposes.
- Ensure that there are sufficient computing resources to process the transactions from all channels during peak periods.
- Due to the integration architecture there is a potential for a high number of demand update messages to move between order management hub and the Promising and Inventory Hubs. Demand messages are put asynchronously into a JMS Queue. A single JMS Queue might not be able to handle such large number of messages. To avoid this scalability issue, instead of using a single queue, you can define multiple queues and distribute messages either using round robin logic or randomly. Order hub puts demand messages into multiple queues, while the Promising and Inventory Hub retrieves messages from all the queues.
Failover and high availability
You can use traditional approaches to ensure the availability of the Promising and Inventory Hub. These approaches can range from using active/passive standby databases using DB2 high availability disaster recovery (HADR) to active/active using DB2 pureScale® or IBM PureData Systems®. Similarly, the agent and application servers can be protected using clustering and horizontal scaling.
There are some limitations with distributed deployment of order management and Promising and Inventory Hubs, based on the Sterling Selling and Fulfillment Suite 9.2 release.
- Provided services and delivery services are currently not supported.
- Item-Based Allocation Agent is currently not supported.
- You cannot use Sterling Warehouse Management System in distributed deployment. Inventory has to reside together with order and shipments for Warehouse Management System to work.
- Some data has to be replicated between the order management instance and the Promising and Inventory Hub instance, as mentioned in the Configuration and master data section. Replication using the Configuration Deployment Tool is supported only if both instances run the same version of Order Management.
- Demand details cannot be maintained on the Promising and Inventory Hub.
- Pure inventory APIs such as the getSupplyDetails API do not work on the order management Hub. As a result, inventory screens in the Order Management console must be accessed from the Promising and Inventory Hub.
- Currently, there is no tool to export inventory from the order management hub and import it to the Promising and Inventory Hub. You must create a custom solution to migrate an existing order management deployment into the distributed deployment described in this article.
- Inventory node control, which is triggered when a backorder from a node occurs, requires a separate integration that is not covered in this article.
The Promising and Inventory Hub provides a single source of truth for all inventory and availability calculations. It enables organizations to make accurate promises to their customers regardless of interaction platform. The Promising and Inventory Hub also enables organizations to respond more rapidly to business demands and helps their IT departments to scale their solutions to significantly larger volumes than a traditional single instance deployment.
- Visit the IBM Sterling Selling and Fulfillment Suite Version 9.2 information center to learn about:
- Evaluate IBM products in the way that suits you best.