Staged upgrade
Upgrades are time-consuming and complex, however there is an approach that you can implement to reduce downtime. You can perform a strategic upgrade of Sterling Order Management System Software Release 10.0 with minimal disruption to the production environment by using a staged rollout upgrade.
Staged rollout upgrade is a zero downtime upgrade method that is available as an option for those who want to upgrade with very little disruption to their original deployment and the services that are provided to the customers. To upgrade in stages, you must already be running the version 9.3 or later of Sterling Order Management System Software.
With the staged rollout upgrade, you can distribute the production version of your application only to a certain percentage of users. Certified updates of the supported version are first released and tested by a small percentage of users before it is made available to all the users through the production repositories. The rollout process ensures that the potential issues with an update are discovered at a small scale, and if required, a potential workaround can be added. Once a larger percentage of the users are comfortable with the functioning of the new updates, the roll-out process is started.
The following sample figure describes how the data flow can be controlled to minimize the impact on the overall business.

- Enterprise OMS Servers V1 and Enterprise OMS Servers V2 are the two Sterling Order Management System Software enterprise instances that run in parallel.
- Enterprise OMS Servers V1 and Enterprise OMS Servers V2 are separate instances that are deployed individually.
- The load balancer acts as a filtering on the top of the deployment and ensures that it controls the access to the new version.
- The filtering ensures that only a fraction of the overall orders flow through the new version.
Agent Multiversion Support
When dealing with multiple instances of OMS servers, it can be very difficult to rollout a production release to all OMS servers at the same time. Instead, it is preferable to deploy a release in a few number of OMS servers only for the purpose of proof of concept of a feature or functionality. Once the release is stable in these few OMS servers, they would rollout the same release in remaining OMS servers in a phased manner. Our product should provide the flexibility for running application servers or agent servers across multiple versions at the same time. The multi version agent support is also useful for the rollout of upgrades or Fix packs in Sterling Store application. So the requirement is to have ability to support rollout for agents.
As a part of the solution for Stage rollout is, the basic requirement for stage rollout is multiple versions of OMS instances need to process data from the same transaction schema.
- Transactional data should be tagged by their RollOut Version.
- Agent servers must be aware of the RollOut Version of the transaction data and process transactional data that matches the Agent’s Rollout Version.
The agent, Multi Version support addresses this requirement.
- com.yantra.ycp.agent.server.YSCAsyncRequestProcessor
- com.yantra.omp.agent.YFSSendInvoiceAgent
- com.yantra.omp.agent.YFSRequestCollectionAgent
- com.yantra.omp.agent.YFSExecuteCollectionAgent
- com.yantra.omp.agent.YFSCloseOrderAgent
- com.yantra.omp.agent.YFSOrderMonitorAgentEx
- com.yantra.omp.agent.YFSSendInvoiceAgent
- com.yantra.omp.agent.YFSScheduleOrderAgent
- com.yantra.omp.agent.YFSCreateChainedOrderAgent
- com.yantra.omp.agent.YFSReleaseOrderAgent
- PAYMENT_EXECUTION
- PAYMENT_EXECUTION.0003
- PAYMENT_COLLECTION
- PAYMENT_COLLECTION.0003
- CLOSE_ORDER.0001
- CLOSE_ORDER.0002
- CLOSE_ORDER.0003
- CLOSE_ORDER.0005
- CLOSE_ORDER.0015
- CHAINED_ORDER_CREATE
- CHAINED_ORDER_CREATE.0005
- CHAINED_ORDER_CREATE.0006
- SCHEDULE.0001
- SCHEDULE.0003
- SCHEDULE.0005
- SCHEDULE.0006
- RELEASE.0001
- RELEASE.0005
- RELEASE.0006