According to your development phases, you can set up different Rule Execution Server environments
(for example development, QA, and production).
About this task
Most likely, the development of your decision management
system requires more than a single deployment of Rule Execution Server. The
development lifecycle of a decision service application can include
stages for implementation, testing, deployment, and maintenance. Typically,
you need an environment for your development team, one for your QA
team, and another one for in-production applications. When you configure Rule Execution Server in
a single cell, it is good practice to isolate the rulesets that you
use on each server and ensure that the execution units (XUs) do not
interfere with each other.
Consider the following guidelines
to set up your different environments in a single cell.
Procedure
- Set up different data sources.
- Deploy and configure a XU for each environment.
- Deploy the Rule Execution Server console
for each environment.
- To set up a data source for each environment, use unique
JNDI names.
For example: jdbc/resdatasourceEnv1 and jdbc/resdatasourceEnv2
- To deploy the Rule Execution Server console
for each environment, proceed as follows:
- Modify the
deployment descriptor of the Rule Execution Server EAR
or WAR management archive: in the web.xml file,
uncomment the JMX_XU_QUERY_PART parameter and
specify
xuName=xuEnv1.
- Deploy the Rule Execution Server EAR
or WAR file to the server.
In the resource, reference
settings in the application server:
- Set the JNDI for the data source as:jdbc/resdatasourceEnv1.
- Set the JNDI name for the XU as: eis/ConnectionFactoryEnv1.
- Repeat to deploy the Rule Execution Server console
for the other environments.
- If you deploy to a cluster, synchronize your changes across
the cluster after you complete the configuration.
- Call the XU instances to register the XU with the Rule Execution Server console.