Typical sharded deployment

You can review a scenario in which a typical sharded deployment might be used.

Many large corporations now do business through multiple channels, and have large databases as well as a high volume of customers and stores. For example, consider the following scenario.

A corporation deploys in single-instance sharded mode, and sells its products via a call center, the Web, and stores. It has hundreds of retail stores located in different geographic regions, and each geographic region has its own separate application server instance. In addition, it has separate application server instances for each of its channels. The corporation currently operates using a third-party database vendor, but wants to gradually transition to using a Db2® database vendor. The corporation may have a catalog of 100K items and process 120K orders every hour with an average of three order lines per order.

This type of complex deployment poses many challenges in the form of performance, scalability, channel visibility, fault tolerance, and data management. IBM® Sterling Order Management System Software addresses such challenges by providing support for the following:

• Search server – A server that provides indexing capabilities that, along with parallel processing, identify the colony in which an order exists.
• Promising server – A server that provides a consolidated picture of availability and inventory updates at the business level for all participating fulfillment channels and organizations, allowing multiple enterprises to share a single view of inventory and to make accurate promises.
• Database sharding – Provides the capability to split a database into smaller, faster, more easily managed parts called shards that can be spread across multiple servers. This enables a corporation to configure data based on business requirements, such as its stores or customer base, and to scale to very large volumes.
• Parallel processing framework – Provides sorting, pagination, and parallel processing capabilities within a managed container environment, and returns the consolidated results back to the original API call.
• Support for multiple database vendors (for example, Oracle and Db2) within a single deployment instance.

The following diagram shows a typical sharded deployment for a US company that sells its products via the Web, a call center, and stores. The company has hundreds of retail stores throughout the US, and maintains a single catalog for all of its stores in the Master data shard. The Configuration, Statistics, and Metadata data are shared across colonies, but Transaction data is stored by geographic regions for each colony, as follows:

• The Transaction 1 database contains transaction data for stores on the east coast (stores 1-100).
• The Transaction 2 database contains transaction data for stores on the west coast (stores 101-200).
• The Transaction 3 database contains transaction data for stores in central US (stores 201-300).
• The Transaction 4 database contains transaction data for stores in southern US (stores 301-400).

The company stores and maintains its inventory and availability-related configuration and information in a Promising server, which is deployed externally. In addition, it uses a Search server, which is also deployed externally, to identify the colony or colonies in which an order exists.

A typical API process flow

The following diagram shows a typical flow when an API , such as getOrderList, is called.

The getOrderList API goes through the following process transaction flow:

1. Authentication - Users are authenticated before they are allowed access to the Sterling Order Management System Software system.
2. Authorization - Authorization is performed to determine whether the user has access to the getOrderList API and whether the system can continue processing the API with the input document that was sent to the system.
3. Colony determination - The system processes the input to identify colony determination. If the Search index server is enabled, the system makes a call to the Search index server to identify the shard or shards. If the Search index server in not enabled, the system identifies that processing is required for all the shards in the system.
4. Parallel processing within a managed container - Orders for the getOrderList input criteria might require retrieving data across one or more shards. For each shard identified, the system spawns separate threads in parallel within the application server. Each thread is a getOrderList API call to the specific identified shard.
5. Business processing - Each getOrderList API thread executes the API to retrieve data from the specific identified shard. The API execution involves running the business logic, calling out to the Promising server for inventory updates and availability calculations, applying access policies, and retrieving applicable data from the shard.
6. Aggregation, sorting, and pagination - The system handles the aggregation, sorting, and pagination of the data returned from the multiple threads spawned from the application server for each shard.

The consolidated getOrderList API result is returned back to the original API call to complete one API transaction.

Notes:

• In an order update, an API call may pass the enterprise code, document type and order number, but not pass the Store fact. If a Search server is enabled, the system uses the Search server to determine the colony Id. However, if the Search server is not enabled, the system makes calls to all colonies in parallel to retrieve data.
• Instances occur when related orders need to be retrieved, such as a sales order for a return order. For example, a customer may purchase a shirt via the Web and a pair of shoes from Store 1, but want to return both items to Store 2. In such a case, the return order can belong to a different colony from that of the sales order. When retrieving such data for related orders, only the primary key fact is used to perform the colony lookup.