rss
SOATUBE
Oracle
Custom Search SOABYTE here

Tuesday, June 29, 2010

Business Rules 10g to 11g migration



















Before you can use a dictionary created with Oracle Business Rules Release 10.1.3.x with Oracle Business Rules for Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1), you must migrate the dictionary to the new dictionary format. Depending on how the Release 10.1.3.x dictionary was created, there are several possible migration paths to migrate a dictionary from Oracle Business Rules Release 10.1.3.x format to Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1).




Ø  Using Oracle JDeveloper to Migrate an Oracle Business Rules Dictionary

When a dictionary is part of an application created in a 10.1.3.x BPEL Decision Service, you can migrate to the Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) dictionary format when you open the BPEL process in Oracle JDeveloper.
1.       Start Jdeveloper.
2.      From File Menu, select Open
3.       Navigate to your project, and select Open. JDeveloper invokes the Oracle BPEL Process Manager migration utility to convert the project, including its rules dictionary.
4.      Examine the Messages – Log window for any errors.
5.       From the File menu, select Save All.
Ø  Using Rule Migrator Tool to Migrate an Oracle Business Rules Dictionary
You can use the MigrateRuleRepository command-line tool to migrate a dictionary from 10.1.3.x to Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) format. Note that most migration scenarios require that you perform manual migration tasks because 10.1.3.x has concepts that have been superseded in Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) by updated and more powerful constructs.
The command-line tool is a Java class called the following:
oracle.rules.tools.migrator.MigrateRuleRepository

It is located in the following directory inside the SOA Oracle home:
SOA_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar

To run the command-line tool, you must have the following set of JAR files available in the classpath.
JAVA_HOME/lib/tools.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jar
JDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jar
JDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jar
JDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar
The following shows a sample MigrateRuleRepository command:
MigrateRuleRepository -all
-origType FILE_REPO
-origLocation /scratch/MyRepository
-destLocation /scratch/MyMigratedDictionaries
-importedClasspath /scratch/foo.jar:/scratch/myclasses
-xsdDirectory /scratch/myschemas
-xsdGeneration /scratch/jaxb_classes
Ø  Using Oracle Business Rules SDK to Migrate an Oracle Business Rules Dictionary

To migrate a dictionary using Oracle Business Rules SDK,

1.       Start Jdeveloper.
2.      In the Application Navigator, click New Application
3.       In the Create Application wizard, enter the name and location for the new application. Click Next.
4.      In the Create Generic Application wizard - Name your Generic project page, enter the name and location for the new project. Click Finish.
5.       In Oracle JDeveloper, select the project with the new name.
6.      Right-click and from the drop-down list select Project Properties.
7.       Select the Libraries and Classpath item.
8.      Click Add JAR/Directory. You must update your project classpath with the following JAR files. Note that there may be a JAVA_HOME installed next to JDEV_HOME, in your ORACLE_HOME directory.

JAVA_HOME/lib/tools.jar 
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jar
JDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jar
JDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jar
JDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar
In the Add Archive or Directory dialog, select the required JAR file and click
9.      Click Add Library -You must add the following libraries to your project classpath:
BC4J Client
Oracle JDBC
Oracle Rules
Oracle XML Parser v2
 JAX-RPC Client


10.   In Oracle JDeveloper, select the project with the new name.
11.    Right-click and from the drop-down list select New.
12.    In the New Gallery, in the Categories area, select General.
13.    In the New Gallery, in the Items area, select Java Class. Click OK.
14.   In the Create Java Class window, configure the following properties
 Enter the Name value - Name of the Java class.
 Enter the Package value – Name of the package
Check the following check boxes:
– Public
– Constructors from Superclass
– Main Method
                Jdeveloper creates the required Java class.
15.   Use MigrateRuleRepository API to create the required code for the Java class.
16.  If the repository you are migrating contains XML Fact Types, you need to specify the location of the schema file that defines these XML Fact Types, and also the output directory that JAXB should use when converting schema files into Java classes.
17.    In the Application Navigator, right-click .java and select Make.
18.   In the Application Navigator, right-click .java and select Run.
19.   Examine the Messages - Log window for any errors.
20.  Retrieve the migrated dictionary from the destination location.


Ø  Oracle Business Rules Manual Migration Tasks
Certain migration scenarios like migrating dictionaries using JAXB1.0 in 10g to 11g require manual migration tasks.

How to Migrate JAXB 1.0 to JAXB 2.0
Oracle Business Rules Release 10.1.3.x uses JAXB 1.0 by default and Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) uses JAXB 2.0. Rules Designer 11g only allows XML schemas to be imported using the JAXB 2.0. However, migrated dictionaries can continue to use JAXB 1.0, but the schema cannot be modified or reimported as JAXB 1.0. A migrated dictionary which uses a JAXB1.0 objects still works with Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1).

To migrate JAXB 1.0 to JAXB 2.0:
    1. Use Rule Migrator to migrate.
    2.  Delete all classes in SCA-INF/classes.
    3.  Record the aliases assigned to all of the fact types used in your rules.
    4.  Delete from the data model the XML Fact Types you want to upgrade to JAXB 2.0. This operation can result in a large number of validation warnings, one for every reference to the now-deleted fact types. However, the SDK stores references to both the ID and String value of all referenced elements. 
If the reference ID is set and it exists, then the String value is updated to reflect its current alias. So, if the alias of a fact type is changed, all of the places where that fact type is referenced get the new value because of the reference id.
If the element with the ID is removed from the dictionary, the String value retains the last known name of the referenced element. This allows you to, for example:
1. Delete a fact type with alias "FactType1"
2. Import a new fact type.
3. Set the alias of the new fact type to "FactType1" and all of the references to the deleted   fact type automatically change to the new fact type.
    1. Import the schema.
    2.  Set the alias of the fact type to the previous alias.
    3.  Run validation on the dictionary.
    4.  If desired, set the alias of the fact type back to the original alias.
    5.  Confirm that all of the references are now be updated.


How to Migrate RL Functions:
In the previous release, the only option for creating a Function was to write free form RL. These functions relied on generated RL names, which have changed in 11g Release 1 (11.1.1): the RL names are now automatically computed from the alias so they are RL-compliant, instead of relying on the user to provide a valid name.
You must re-write any function which accesses globals to comply with this change by using Actions. It is easier to write functions using Actions because they are validated at design-time.
In Oracle Business Rules Release 10.1.3.x dictionaries that contain free-form RL functions, it was a common practice to refer to Java classes which were not in the data model. For example, many dictionaries include functions which use ObjectFactory to create instances of JAXB classes. In Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1), to include this class in the data model you cannot simply reimport the schema and import ObjectFactory because it is imported as a JAXB 2.0 class. The solution in this case is to use the ObjectFactory class which is in the "classes" directory in your project from when the dictionary was migrated. This ObjectFactory class should be imported as a Java class and can then be referenced in Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) functions.

To migrate RL functions:
1.       For each free form RL function, re-write the RL to use Actions.
2.      In 11g Release 1 (11.1.1) you may use Actions both in Function bodies and in rules.
3.       There are several new Action forms which in most cases eliminate the need for free form function bodies. Action forms available include:
Call
Assert and Assert new
Retract
Assign and Assign New
Modify
Synchronized
Expression
Assert
If, Else If, and Else
For and While
Return, Throw, Try, Catch, and Finally
RL
4.      Validate your dictionary.

Ø  Manual Migration
In the previous release, the only option for XML schema import was JAXB 1.0. In 11g Release 1 (11.1.1), Oracle Business Rules provides support for JAXB 1.0, but JAXB 2.0 is the default. If you choose to continue to use JAXB 1.0, generated RL may throw MultipleInheritanceException. The SDK does not do any validity checking on free form RL Function bodies. As a result, any errors in the functions are not revealed until the RL is executed.

0 comments:

Post a Comment

 
Blogger Profile