1. Database Upgrade Guide for DB2 for z/OS
  2. Managing Cross Version Migration

Managing Cross Version Migration

Siebel CRM applications in general support cross version migration, meaning that you can use Siebel Migration to propagate changes from a Design Repository (DR) environment which has a later binary version than the Runtime Repository (RR) environment. For example, consider a scenario where you have installed the latest Siebel CRM monthly update in the DR environment, but are not planning to install the same monthly update in the RR environment until you have had adequate time to test it – perhaps a few months or more later. In the meantime, you may have repository or other changes that you want to migrate from DR to RR, even though they are on different binary versions.

In this scenario, some types of changes need to be managed carefully – for example:

  • At the boundary between Siebel CRM 20.6 and 20.7 when the Workspace-Enablement of Workflow Processes feature was introduced. This feature includes changes to Workflow Process-related tables, in particular the RR tables where Workflow Processes are deployed. For a customer on Siebel CRM 20.7 (or later) in the DR and on Siebel CRM 20.6 (or earlier) in the RR, Siebel Migration needs to know what format the target environment is anticipating – is it expecting to receive data from the old deployment table or the new deployment table?

  • At the boundary between Siebel CRM 22.6 and 22.7 when the Workspace-Enablement of Tasks feature was introduced. This feature includes changes to task flow-related tables, in particular the RR tables where task flows are deployed. For a customer on Siebel CRM 22.7 (or later) in the DR and on Siebel CRM 22.6 (or earlier) in the RR, Siebel Migration needs to know what format the target environment is anticipating – is it expecting to receive data from the old deployment table or the new deployment table?

The answer in both cases: The target environment expects to receive DR data from the source environment, and the data is deployed into the old deployment table in the target using the old business service.

Cross Version - Incremental Migration

For incremental migration of workflow objects, any version after Siebel CRM 20.7 will handle cross version migration automatically:

  • When the watermark is generated by the RR environment, it will include the target's binary version.

  • When the migration export job is executed in the DR, it will use this information to manage any differences between the two environments.

  • If the target is pre-20.7, it will send the Workflow Process data in the older format.

  • If the target is version 20.7 or later, it will use the newer format.

For incremental migration of task flow objects, any version after Siebel CRM 22.7 will handle cross version migration automatically:

  • When the watermark is generated by the RR environment, it will include the target's binary version.

  • When the migration export job is executed in the DR, it will use this information to manage any differences between the two environments.

  • If the target is pre-22.7, it will send the task flow data in the older format.

  • If the target is version 22.7 or later, it will use the newer format.

Cross Version - Full Migration

For full migration, there is no watermark so there is no way for Siebel Migration to know that the target environment is on a different version. To accommodate this – that is, to let Siebel Migration know that the target environment has an earlier version, add the FullMigCompatibilityMode system preference to the source (DR) environment. Doing this ensures that the expected data is sent to the target (RR) environment.

Note the following about adding and configuring the FullMigCompatibilityMode system preference:

  1. This parameter is only required when crossing a release boundary where a change has occurred.

    • In the example provided here for workflow objects, it is only required if the DR is on Siebel CRM 20.7 or later and the RR is on Siebel CRM 20.6 or earlier.

    • In the example provided here for task flow objects, it is only required if the DR is on Siebel CRM 22.7 or later and the RR is on Siebel CRM 22.6 or earlier.

  2. Since each target environment's binary version can be different (for example, if your Test environment is on 20.5/22.7 and your Production environment is on 20.3/22.6), you can create multiple "FullMigCompatibilityMode" system preferences using sequential numbers. That is, FullMigCompatibilityMode0, FullMigCompatibilityMode1, FullMigCompatibilityMode2, and so on.

  3. For each source Integration Workspace (IWS) from which you will be migrating, you must create a "FullMigCompatibilityModeX" system preference that contains the name of the source IWS (or MAIN):

    • System Preference Name: FullMigCompatibilityModeX, where X is a consecutive number starting from zero for each IWS that will be migrated across a known release boundary.

    • System Preference Value: Workflow, Task or some other object type that changes across a given version boundary. Set "Value" to one of the Values shown in the following (second) table.

    • Description: <The name of the IWS (or MAIN)> for which the compatibility mode is required.

Example configurations for FullMigCompatibilityMode are shown in the following table.

System Preference Name

System Preference Value

Description

FullMigCompatibilityMode0

Workflow

MAIN

FullMigCompatibilityMode1

Task

MAIN

FullMigCompatibilityMode2

Workflow

Int_June_202x

FullMigCompatibilityMode3

Task

Int_June_202x

FullMigCompatibilityMode4

Workflow

Int_July_202x

FullMigCompatibilityMode5

Task

Int_July_202x

The "System Preference Value" refers to the type of object that is of concern to cross a boundary and should be set for example as shown in the following table.

Source Version >=

Target Version <=

Value

20.7

20.6

Workflow

22.7

22.6

Task
Note: Only workflows and task flows are affected (during cross version migration) at this time. As more objects become Workspace-enabled, new boundaries will be determined.

CleanUpTaskDR Utility

In the case of a full migration where the source is being upgraded to 22.7 or later and the RR environment has task DR data, any import of task DR records will fail due to a duplicate record error. For the import to run without error on a lower versioned environment, task DR data must be deleted. To delete task DR data, you must run the CleanUpTaskDR utility located in the .../ses/siebsrvr/bin folder.

To run the CleanUpTaskDR utility

  1. Copy the CleanUPTaskDR utility from SiebelBuild/ses/siebsrvr/bin on the source environment to the same location on the target environment.

  2. Run the CleanUpTaskDR utility from SiebelBuild/ses/siebsrvr/bin on the target environment.

    The syntax for running the CleanUpTaskDR utility is as follows:

    SiebelBuild/ses/siebsrvr/bin> CleanupTaskDR –t <TBLO> –u <TBLO User> –p <TBLO User Password> 
–o <ODBC Data Source> –s <Siebsrvr Installation Path>

    For example:

    C:\2022_06\ses\siebsrvr\bin CleanupTaskDR –t dbo –u SADMIN –p MSSQL 
–o Siebel_DSN –s C:\2022_06\ses\siebsrvr

    While running this command, the following message appears: 

    C:\2022_06\ses\siebsrvr\bin> Deleting data from Task Related Tables

The following table describes the arguments that you can use to run the CleanUpTaskDR utility.

Argument

Description

Example

-t

Table Owner

dbo

-u

Table Owner User

SADMIN

-p

Table Owner Password

********

-o

ODBC Data Source

siebel_DSN

-l

Log File Name (Optional)

CleanupTaskDR_timestamp.log (Default)

-s

Siebsrvr Installation Path

C:\2022_07\ses\siebsrvr