IBM Support

Migrating to Rule Team Server v7.0 and v7.1

Technote (FAQ)


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 v7.1.1.4 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 grant required privileges to the database user referenced in the datasource. The role gets select permission on all required tables of the old database.
        ant gen-migration61-role

    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.
    The ant task for generating the SQL expects both the old schema and the new schema to belong to the same database. The old schema contains both the tables and data for the old RTS version. The new schema should contain the tables created using the Installation Manager for the new RTS version. The task uses the datasource JNDI to access the database. It then uses the old schema to generate SQL statements that collect the original information in the old schema and transfer it into the new schema in the same database.
    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:
        ant execute-schema
    We recommend that you have the scripts reviewed and executed by a DBA, who will also be able to better understand any errors that may occur during script execution. For example, if working with DB2, the DBA can run the SQL script with the -tvf option to retrieve any errors generated:
      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
    • Configure the transaction timeout values for v7.x, to prevent timeout during ruleset generation. RTS v7.x does not use EJBs, and so timeout values are configured differently.
    • If migrating from v7.0 to v7.1, clear the RTS cache to prevent errors when generating a ruleset.

Related information

Migrating a Rule Project to JRules v7.0 and v7.1
Migrating RuleApps to v7.1
Improving RTS performance

Cross reference information
Segment Product Component Platform Version Edition
Business Integration IBM Operational Decision Manager Modules:Rule Team Server Platform Independent 7.5
Business Integration IBM Operational Decision Manager Platform Independent 8.0

Document information

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: 25 April 2012

Translate this page: