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.
When doing a cross version migration where the target (Runtime Repository) has a version less than 25.3 and the source (Development Repository) has a version of 25.3 or greater, you must specify a new System Preference. The signature in the Source Repository changes with 25.3 to allow for larger migration packages associated with many languages (greater than 22) so if the Target is less than 25.3, it will not understand the new, larger signature. The X System Preference tells the Source (Development Repository) to generate its payload using the older signature.
System Preference Name: Use Old Migration Signature
System Preference Value: TRUE (A value of TRUE means the Target is less than 25.3. If this System Preference is not defined or is set to FALSE, the new signature will be used during cross version migration.)
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.
-
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:
-
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.
-
-
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.
-
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 |
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
-
Copy the CleanUPTaskDR utility from
SiebelBuild/ses/siebsrvr/bin
on the source environment to the same location on the target environment. -
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 |
---|---|---|
|
Table Owner |
|
|
Table Owner User |
|
|
Table Owner Password |
|
|
ODBC Data Source |
|
|
Log File Name (Optional) |
|
|
Siebsrvr Installation Path |
|