Migrating the runtime environment

The runtime environment is your application running in production, in contrast to other phases of the application lifecycle.

Before you begin

Before migrating the development environment, make sure you have migrated your customization in the correct environment.

About this task

When you migrate your runtime environment, you have two possible solutions:

Transition with outage

In this case, you switch off the previous version, prepare V8.8.1, and then switch on V8.8.1. This case is possible only if you can accept an outage, during which no request or event is processed.

Transition with no outage

For stateless and remote workloads: Start your V8.8.1 run times, load them with your migrated assets and artifacts, and then change your infrastructure so that all new queries are directed to the V8.8.1 servers. The queries that are already started use the previous version until the operations are complete.

For stateless local workloads: The calling applications must be repackaged with the V8.8.1 code. In this case, both versions of the same application must coexist for a short time, and the load balancer must be able to route workloads to both versions. You can progressively shut down all previous instances of the application until only V8.8.1 applications take over the load.
For stateful workloads: Client applications and event senders cannot be subjected to a process or period of transition inside a specific context. Every interaction started with a previous version must finish with this version. Every new interaction can start with V8.8.1, so that, after a while, all interactions started with previous versions end, and you can shut down these servers.

Note:

The current RuleApp format is fully compatible with V8.7.0 and upwards when you use the classic rule engine. For RuleApps created in a version before V8.7.0, you must rebuild your migrated projects, test them, and then redeploy new RuleApps. This compatibility means that you can operate design time and production runtime migration in parallel. In the run time, you do not have to wait for project migration and redeployment. You can export the content of the Rule Execution Server persistence layer and upload it to the V8.8.1 persistence layer. In the meantime, you can build your migrated projects, test them, and redeploy them.

Rulesets that use the decision engine prior to V8.8.0 are not compatible with V8.8.1. You must redeploy these rule projects to produce a new archive and deploy this archive to Rule Execution Server. If you do not regenerate your archives, a warning is displayed in the Ruleset View of the Rule Execution Server console, and you cannot use the Test Ruleset or Retrieve HTDS Description File features.

Procedure

Install Operational Decision Manager V8.8.1.
Migrate your development environment.
Complete the following steps that are relevant to your configuration:
1. Make copies of your previous version’s databases. All data is compatible with V8.8.1, and as a result you can copy your rules and events runtime databases and all appropriate data to the new release.
2. Redeploy the Rule Execution Server modules for the new version on application server you use in production. See Configuring.
3. Regenerate any previously deployed decision engine archives and redeploy them.
4. Deploy the V8.8.1 event runtime archive file to WebSphere® Application Server.
Deploy any new versions of your rules (RuleApps) and execution object model (XOM) archives to the V8.8.1 Rule Execution Server persistence layer as needed.