Loading a Migration Set

Once the set has been built on the source environment, it becomes visible to target environments that are set up to monitor the source environment. The configuration set is listed on the page "Inbound Data Sets" (FN0040).

This page is available on the target environment - migration sets are pulled, not pushed. The user selects the set and starts the load process by clicking the "Start" button. This pulls the file from the source environment repository and starts the configuration import process.

Customer security regulations may not allow for direct communication between the source and target environment. The alternative approach is for the user to specify the location of the migration file and start a file-based import. This is managed from the "File Imports" tab on the same page.

In addition to business rule violations, the import process can return the following messages:

Code	Severity	Text
GEN-MIGR-001	Fatal	Cannot find {entity} with key {code or usage name} used by {entity, key}
GEN-MIGR-003	Fatal	Cannot find OhiTable with Name {name} used by {entity, key}
GEN-MIGR-004	Fatal	Cannot find Signature with Name {name} and Subtype {subtype} used by {entity, key}
GEN-MIGR-005	Fatal	Cannot find usage for dynamic field or record {usage name} on {table name} used by {entity, key}
GEN-MIGR-006	Fatal	The dynamic field usage ({name}, {table name}) is not compatible with the existing configuration
GEN-MIGR-007	Fatal	The import file must have a .zip extension
GEN-MIGR-009	Fatal	It is not possible to start a new import while another import or build is in progress
GEN-MIGR-013	Fatal	The migration process failed due to technical issues

Possible business rule violations can occur when the same dynamic field usage has a different configuration on the source and target environment, for example, the usage allows multiple values on the source environment and only a single value on the target environment.

Note that each configuration item is inserted, updated or deleted on the target environment as a separate transaction. This means that the failure inserting, updating or deleting a single configuration item does not prevent the rest of the payload to migrate.

To ensure consistent policy processing results, it is recommended that policy processing is put on halt prior to migration.

Preventing Configuration Migration between applications and major versions

OHI does not support config migration between a source and, a target that are not on the same release. Doing so can break the system without means of recovering.

To limit this:

• At the time for export, a file containing application and version information is attached automatically to Configuration Migration Set, export zip (Ex: Policies - 3.30.3.0.0). System encrypts this information in the file.

• At the time of import, system reads the file in the Zip and validates the version attached to it with the version of target environment.

• The application does not support configuration migration between a source and target environment that are not on the same major release. If you try to import a configuration migration file that violates this business rule, the system returns message GEN-MIGR-015.

• When the Configuration Migration Tool payload (XML file) contains a non-existing entityName attribute, the system returns message GEN-MIGR-016. This could happen if the Configuration Migration Tool set was created from an instance where a country pack module is activated, and loaded into an instance where that country pack module is not activated (controlled by system property).

Code	Severity	Text
GEN-MIGR-015	Fatal	The import failed because the source environment {source environment} {source environment release} and the target environment {target environment} {target environment release} are not the same
GEN-MIGR-016	Fatal	The import failed because entity name {entityName} doesn’t exist.

If while importing a dynamic logic that contains some Reusable Code with dependencies on one another, The CMT import may not load all the dynamic logic. For that issue a new property has been introduced that is :

ohi.cm.dynamiclogic.import.maxRetryCount

This defines the number of times a dynamic logic failed import should be retried.

This cannot be greater than nine and the default value is three.