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 migration set is listed on the page "Inbound Data Sets" (FN0040) 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-002 |
Fatal |
Cannot find {entity} with Code {code} and Flex Code Definition Code {definition code} 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 |
Business rule violations can occur when a dynamic field usage has a different configuration on the source and target environment, for example when the usage allows multiple values on the source environment and only a single value on the target environment.
- Note
-
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 processing results, it is recommended that processing [1] is put on halt prior to migration.
Once de-queuing is stopped, the application still accepts and queues new imports coming in through the integration points, but no longer picks up queued objects up for processing.
Dynamic logic may contain a reference to re-usable code in another dynamic logic.
If the dynamic logics are not imported in the correct order, the compilation will fail.
If this happens, the process retries the failed compilation at the end of the import.
The system property ohi.cm.dynamiclogic.import.maxRetryCount specifies how many times the process retries compilation before marking the import as errored.
The default value is three.
Preventing Configuration Migration Between Applications and Major Versions
Oracle Health Insurance does not support config migration between a source and a target that are not of the same application or not on the same release.
Trying to import a configuration migration file that violates this rule returns message GEN-MIGR-015.
When the migration set contains a non-existing entityName attribute, the system returns message GEN-MIGR-016. This could happen if the migration 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.
| 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. |