Migrating to Rule Team Server v7.0 and v7.1
How do I migrate to Rule Team Server (RTS) v7.0 and v7.1?
This document focuses on migration from RTS v6.x to v7.0 and v7.1. For migration to WebSphere Operational Decision Management v7.5, refer to Migrating from JRules to WODM.
Before proceeding with migration, determine how you use Rule Studio and RTS for managing your rules. If your use case falls under Scenario 3 as described in Migrating to JRules v7.1 (RTS is the source of truth for your rules), then continue to follow the recommendations in this document.
RTS v7.0 and v7.1 incorporated certain design changes that require special consideration when migrating from v6.x. Start by reading the documentation Migrating from JRules 6.x, especially How to migrate from JRules 6.x and Migrating rule projects for rule authors.
Before starting RTS database migration, make the following changes:
- Make sure no rule names in v6.x end with a space.
- Make sure that no rule properties (like status) have null values. If they do have null values, run a query to assign non-null values to the properties (for example new for the status property).
- Ensure the priority property is migrated properly, if migrating to v188.8.131.52 or earlier.
When migrating the RTS database, refer to the documentation for RTS database migration and Troubleshooting for RTS database migration.
- Make sure that the persistence locale that uses two letters (such as fr) will be changed to the form that uses four letters (such as fr_FR), as required by v7.1 and later.
- Use the ant tasks to create the migration role and generate the migration script for the correct version.
- If migrating from v6.1, use gen-migration61-role and gen-migration61-script.
- If migrating from v6.5, use gen-migration65-role and gen-migration65-script.
- If migrating from v6.6, use gen-migration66-role and gen-migration66-script.
- If migrating from v6.7, use gen-migration67-role and gen-migration67-script.
The following task is used to create the SQL script to copy the old database content into the new schema.
ant gen-migration61-script -debug
- When running the above ant tasks, check that all the parameter values are correct:
- rtsAdmin.login should be the user configured with the rtsAdministrator role.
- server.url should point to the new RTS URL.
- oldDatabaseSchemaName should point to the database schema name of RTS v6.
- datasourceName should point to the JNDI name of the new RTS data source.
- outputFile should point to a file to which the SQL script will be written. If this file does not exist, it will be created.
Note: A common mistake is to point to Rule Execution Server (RES) database, and/or access it as the RES user.
- When executing the scripts generated using the ant tasks above, ensure that
- All the parameter values are correct
- The user who runs the scripts has permissions to write to the new database.
- The scripts are run on a clean empty database.
The following task executes an SQL script (output.sql) that defines the new RTS schema:
db2 -tvf <script file-name> > <output file-name>
- RTS v7.x has new constraints to prevent duplicate tags. This can lead to some rule artifact tags to be excluded from the migration script to avoid a duplicate issue.
Once the RTS database has been migrated,
- Complete the ruleflow and decision table migration by synchronizing with Rule Studio. Resolve any synchronization errors, and update the rule artifacts in Rule Studio to ensure decision tables and ruleflows use the new format. Publish the updated artifacts back to RTS.
- Resolve any compile errors on rules in RTS after migration.
- Check the project for consistency.
- Verify that the rulesets are generated correctly
|Business Integration||IBM Operational Decision Manager||Modules:Rule Team Server||Platform Independent||7.5|
|Business Integration||IBM Operational Decision Manager||Platform Independent||8.0|
More support for:
WebSphere ILOG Rule Team Server
Software version: 6.5, 6.6, 6.7, 7.0, 7.1
Operating system(s): Platform Independent
Reference #: 1591798
Modified date: 2012-04-25