Single-instance nonsharded deployment

You can choose a single-instance nonsharded deployment configuration.

IBM® Sterling Order Management System Software offers support for single-instance deployments that contain:

  • A single database containing all Configuration and Transaction data
  • A cluster of application servers with a single Enterprise Archive (EAR)
  • One or more enterprises

In this configuration, all extensions can be defined by enterprise. These include code extensions, user exit implementations, events, templates, menus, and extensions to the user interface. Each enterprise can have its own sourcing rules, pipelines, tasks, and so on. In addition, this type of deployment offers isolation of configuration; that is, if one enterprise's configuration changes, the others are not affected. In a single instance, all the data is centrally located, so you can upgrade the entire instance together and consolidate database maintenance tasks.

The following illustration shows an example of a single-instance, nonsharded deployment:

A flow chart of a single-instance, nonsharded deployment

As this illustration shows, in a single-instance, nonsharded deployment, Configuration and Transaction data reside within the same shard. This shard is shared by three enterprises: E1, E2, and E3. It has a cluster of nodes in an application server and one EAR.

Following are the advantages and limitations of this single-instance, nonsharded deployment.


  • Enterprises can participate with each other, sharing inventory and sourcing rules.
  • Nodes, such as ship nodes, can be shared across enterprises.
  • Enterprises can inherit rules from another enterprise within this same Configuration shard.
  • Each enterprise can have its own code extensions, events, templates, extensions to user interfaces, menus, and user exit implementations.
  • Each enterprise is configured separately. For example, E1 can have its own sourcing rules, pipelines, tasks, and so forth. This isolation of configuration means that you can deploy and move data by enterprise in the Configuration Deployment Tool (CDT).
  • All enterprises are under a single point of control. For example, you can start and stop agents and monitor processes from one place.


  • In this current deployment, enterprises cannot upgrade independently by enterprise, because Transaction data is not isolated by enterprise. It is in a single-instance, nonsharded deployment.
  • As more enterprises are added, more database capacity is needed and increased hardware expense can result.

    There is a finite threshold for growth in a single-instance deployment. Also, if you want more isolation for your enterprise environments, you can consider having multiple instances of the deployment.