Siebel Business Rules Administration Guide > Configuring the Business Rules Development Environment > Migrating Rules Between Environments >

Migrating Rules Runtime Data Between Environments

The following topics describe the two primary methods for migrating runtime data (rule modules and statements) and other Object Importer metadata that is used at runtime from one environment to another.

• Migrating Rules Runtime Data Using Export and Import Utilities
• Migrating Rules Runtime Data Using Siebel Application Deployment Manager

Migrating Rules Runtime Data Using Export and Import Utilities

You can migrate runtime data (rules modules and statements) and other Object Importer metadata that is used at runtime to a target environment by using the Export and Import utilities in your Siebel application.

This strategy is intended for migrating small numbers of rules to a single target environment. For larger amounts of data, or for migrating rules and other Siebel data concurrently, or for migrating data to multiple servers, you typically use Siebel Application Deployment Manager (ADM). For more information, see Migrating Rules Runtime Data Using Siebel Application Deployment Manager.

Runtime data is exported to XML files from a source runtime datasource. The XML is imported into the target runtime datasource.

Observe the following requirements for migrating rule modules:

• If you must migrate rule modules from multiple source environments, then the name of each module must be unique within the entire collection of modules that is migrated to the target environment.

  CAUTION:  Modules overwrite current data. A migrated module overwrites an earlier migrated module of the same name. Only the state of the original module in the target environment is preserved.

• The semantic role model on which imported rule modules are based must be consistent with the Siebel Repository for the target datasource. To ensure consistency, the repository for the source datasource must be identical to the repository for the target datasource.

To export runtime data

1. In your Siebel application, navigate to Administration - Business Rules > Rule Modules List
2. In the Rule Modules applet menu, choose one of the following:
   • Export All Modules with Model. If the semantic role models in the target (import) and source (export) environments differ, such as when no rule modules are yet deployed in the target environment, then you must export all rule modules from the source environment with the model.

     NOTE:  You must not export a subset of rule modules with the model.

   • Export Modules Only. If the semantic role model exists in the target (import) environment's runtime data and is identical to the semantic role model in the source (export) environment's runtime data, then there is no need to replace the target environment's runtime role model. You can export selected modules only.

     An XML file with the exported rule modules is created. If applicable, it includes the semantic role model for the exported rules.

3. Opt to save the file.
4. Repeat Step 1 through Step 3 in each runtime environment from which you must export rule modules.

To import runtime data into the target datasource

1. In your Siebel application, navigate to Administration - Business Rules > Rule Modules List
2. In the Rule Modules applet menu choose Import Rules.
3. In the Import Rules dialog box, browse to select an XML file that was exported from the source runtime datasource.
4. Repeat Step 2 and Step 3 for each exported XML file from all source environments.

Import preserves the rule module state in the target environment if it is already deployed there. That is, if the existing rule module of the same name in the target environment has active state, then the imported rule module has active state.

If an imported rule module does not have a rule module of the same name already deployed in the target environment, then the imported rule module assumes the state it had when it was exported from the source environment. That is, if the rule module was in active state when it was exported, then it assumes active state when it is imported.

For information about activating a rule module, see Configuring and Activating a Deployed Rules Module.

Migrating Rules Runtime Data Using Siebel Application Deployment Manager

Application Deployment Manager (ADM) is the framework that automates the migration of enterprise customization data from one Siebel environment to another.

This topic provides the rules-specific details for using ADM to migrate rules-related data. For detailed information about using ADM in all contexts, see Siebel Application Deployment Manager Guide.

For migrating small numbers of rules, HaleyAuthority's Import and Export functions suffice. However, Import and Export are not practical for migrating all the components of a particular customization that includes rules and other Siebel data. Such customizations may include migrating rules, as well as objects such as business components, views, and lists of values (LOVs). To migrate such customizations efficiently, use ADM to create packages and deploy.

Business Rule is a predefined ADM data type that is intended for use in migrating business rules runtime data.

Please consider the prerequisites and principals when you use ADM to migrate rule modules:

• The source and target environments must have identical knowledge bases.
• It is assumed that the source and target environments for the migration are derived from a common environment. Exporting the semantic role model from the source to the target environment replaces the model in the target environment, so it is important that most, if not all, existing rule modules in the target environment also exist (modified or not) in the source environment. Thus, after migration, the model required in the target environment is essentially updated with no deficiencies for rule modules that existed in the target environment, but not in the source environment, prior to migration.

  If the semantic role model is replaced in the target environment during migration, any rule modules that existed in the target environment, but not in the source environment, may have their Inconsistent flag set to Y in the Rule Modules applet in the Administration - Business Rules screen. You must resolve any rule module's inconsistency with the new model in HaleyAuthority and re-deploy the rule module from HaleyAuthority. For more information, see Configuring and Activating a Deployed Rules Module.

• After migration, all modules have an Active status displayed in the Rule Modules applet in the Administration - Business Rules screen. If the status of a module should not be Active, deactivate the module. For more information, see Reconfiguring and Deactivating Rule Modules.

To migrate rule modules using ADM

1. In the Siebel application that points to the datasource to which you deployed your rules (the source environment), choose Site Map > Administration - Business Rules >
2. Choose Site Map > Application Deployment Manager > Deployment Projects. Create a new deployment project using the instructions in Siebel Application Deployment Manager Guide. All the fields that need to be filled in for the project are explained in the Siebel Application Deployment Manager Guide.

   Use the following guidelines to clarify the entries for some specific fields:

   • Session Configurable. Your entry in the Deployment Filter field, described in the following Step 3, determines which rule modules are exported in this project. To override this filter for a particular deployment session, check this field. To prevent a session-level override of the filter, leave this field unchecked.
   • Target System and Target User Name. No entries are necessary.
3. In the lower applet, follow the instructions in Siebel Application Deployment Manager Guide to create a deployment filter for selecting the subset of rule modules to export.

   Use the following guidelines to clarify the entries for some specific fields:

   • Data Type Name. Enter Business Rule.
   • Deployment Filter. The Business Rule ADM data type supports the following syntax to implement a field-level search specification on the Rule Module business component. You must enter the search specification manually.

   [Field Name] operator 'Filter_Criterion' -model

   The optional -model flag specifies to export the selected rule modules without exporting the source environment's semantic role model.

   Use the following guidelines for setting the -model flag:

   • Append -model if the semantic role model exists in the target environment's runtime data and is identical to the semantic role model in the source environment's runtime data. For this scenario, there is no need to replace the target environment's runtime role model, so setting -model increases the migration performance. For example, to export only rule modules whose Name field begins with Pharma, without the model, enter:

   [Name] like 'Pharma*' -model

   • If the semantic role models in the target and source environments differ, such as when no rule modules are yet deployed in the target environment, then you must export all rule modules from the source environment with the model. To do so, leave the Deployment Filter field empty or enter:

   [*]

   NOTE:  You must not export a subset of rule modules with the model. That is, a filter specification like the following is not valid:

   [Name] like 'Pharma*'

4. Use the instructions in Siebel Application Deployment Manager Guide to backup rule modules in the target environment, import the rule modules, activate, and restore the rule modules as you would do for any other ADM data type.

   NOTE:  During restore, any new rules that are inserted during import are deleted. To change this behavior, modify the ADM registry by changing the value of the DeleteNewObjects property to N. For information on the ADM registry, see Siebel Application Deployment Manager Guide.

5. Depending on the parameters you set in ADM, the state of imported modules (Active or Inactive) may not be the same state as the modules they update. Check the states of the updated modules, and activate or deactivate modules as needed.

   Migrated modules are in Active state provided the Activate step of the ADM migration process is invoked. If Activate is not invoked, then modules' states prior to migration are preserved after migration.

   For information on activating rule modules, see Configuring and Activating a Deployed Rules Module. For information on deactivating rule modules, see Reconfiguring and Deactivating Rule Modules.