Building a Configuration Migration Set
The JET UI pages "Configuration Migration Sets" [1] and "Outbound Configuration Migration" [2] allow the user to build a data file for a configuration migration set.
The 'build' function takes three input parameters:
- Inclusion Date
-
If specified, the build function only adds those items to the payload that have been created or have been updated since the inclusion date. The inclusion date filter only applies to a restricted list of high volume items. See High Volume Items - Inclusion Date for more details.
This parameter is optional. - Exact Version Match?
-
By default configuration migration sets are tagged with the version that they are created with, which is checked at the time of importing the migration set, to see if the application version is compatible enough to import this set. The check on the application version is by default on the major version. If this flag is on, then an exact version match is to be performed. This can be used in case there are breaking changes delivered as a patch, and a configuration migration set only works with a particular patch version.
This parameter is optional, the default value is false. - Disable Delete by Omission?
-
By default configuration migration sets, when they get imported, perform deletion by omission for child lists. This means if certain children of the root element are not present in the payload, then they would be deleted from the target environment.
This can impact the use country pack Configuration Migration sets, as Country Packs only contain root elements and not the corresponding children, as those are added at the customer end. With this flag switched on, the configuration migration tool import will not perform deletion by omission, and let those child records stay in place.
This parameter is optional, the default value is false.Note that the desired 'Delete by Omission' behavior can also be set upon importing a migration set. That setting overrules the setting added during the build of the migration set.
The "Build" function iterates over all items in the migration set and creates a migration file.
Once the payload is generated, two actions become available. The first is the option to save the file on a local file directory.
The second option is to use the integrated web service for data exchanges. Once the file is built, the set becomes visible to other (target) environments that are set up to monitor available sets on the source environment.
In the target environment the system can load the configuration migration set [3] through file import or through importing a data file set.
Target environments can be set up in this way by specifying the end point of the source environment in the application properties file. Refer to Property Management for more information on setting a property. Once visible, the target environment can pull and import the migration payload from the source environment.
The generated files are stored in an internal repository on the source environment.
Build Unsuccessful
If the build fails, for example because of technical issues (out of memory error or a crash), the system logs a message. This message can be found in the Interface Messages Overview page.
If the build fails due to unexpected technical issues the message is not specific (GEN-MIGR-013). The application log file must be analyzed to determine the cause of the failure.
It is not possible to start a build if another build is in progress.
| Code | Severity | Text |
|---|---|---|
GEN-MIGR-008 |
Fatal |
It is not possible to start a new build while another build or import is in progress |
GEN-MIGR-010 |
Fatal |
It is not possible to start a build with an empty data set |
GEN-MIGR-013 |
Fatal |
The migration process failed due to technical issues |
GEN-MIGR-014 |
Fatal |
A cycle is detected in the object graph of {entity, key} |
GEN-MIGR-015 |
Fatal |
The migration process failed due to non-compatible application-version {application-version} |
High Volume Items - Inclusion Date
A large part of a full migration payload can be made up out of the following items:
-
Product Benefit Specifications
-
Fee Schedule Lines
-
Provider Group Affiliations
-
Procedure Group Details
-
Diagnosis Group Details
-
Reference Sheet Lines
-
Flex Codes
For this reason, the configuration migration function is optimized specifically to generate and load these items. In addition, the user interface offers a feature to manage the payload size for these items: the inclusion date. If specified, this build function filters these items so that only the ones that have either been created of have been updated since the inclusion date are added to the payload.
Regular behavior of the configuration migration tool is to delete dependent items if they are not in the payload. However, a target environment that receives a data set with an inclusion date will not delete items that belong to one of those items. The reason is that a target environment recognizes to-be deleted dependent records by their absence from the payload. Since the inclusion date filters the payload, the target environment is not able to distinguish between the situation where a record is absent because it was deleted or because it has been last updated before the inclusion date.
Excluded Data
Unless explicitly specified differently, the system excludes diagnosis, procedures, payers and providers from the migration set. These objects have their own data exchanges.
If the configuration migration set specifies to include, for example, providers, the system automatically includes all providers that are somehow linked to configuration in the set. In other words, unlinked providers will not be included.
Oracle Health Insurance provides a separate option to create and build data sets that contain all providers, all diagnosis or all procedures [4]. These sets can also make use of the inclusion date - meaning that only providers, procedures or diagnoses are added to the payload that have been created or updated after the specified date.