Oracle Configurator Implementation Guide Release 12.1 for Part Number E14322-03 | ![]() Contents | ![]() Previous | ![]() Next |
This chapter describes how to migrate a CZ Release 12 instance into an empty CZ instance, and how to migrate Model data from one instance to another development instance.
This chapter covers the following topics:
Migrating data is the process of copying data from one database instance to another database instance. You can migrate data from a CZ schema to another, empty CZ schema, or migrate Models from one development instance to another. The latter process is explained in Migrating Models.
The process of migrating data from a CZ schema should only be run against a target database containing a new installation of Oracle Applications, and both the source target and database instances must have the same schema version.
Migrating data from a CZ schema does not:
Transfer data from custom tables that are not in the CZ schema
Transfer saved configurations
Migrating saved configurations is not recommended because it typically involves a very large amount of data.
Warning: Data migration is a one-time process. Once migration is complete, do not repeat the process or use the migration concurrent programs to refresh data in the Oracle Applications database.
To migrate an Oracle Configurator Release 12 schema:
Check the versions of the Oracle Configurator Release 12 source and target database schemas.
Both the source and the target must be at the same minor version. If there is a difference between the two database schema versions, then migration cannot continue. You must take appropriate steps, such as upgrading, to bring either the source database instance or the target database instance to the desired version.
See Verifying CZ Schema Version for details.
Verify that there are no implementors logged in to Configurator Developer that is connected to the either the migration source or target database instances.
Verify that there are no end users connected to either the migration source or target database instances, including production deployments or a test runtime Oracle Configurator.
Delete Models from the Oracle Configurator Developer Repository that do not need to be migrated into the target database schema.
Run the Purge Configurator Tables concurrent programs to clean up the source schema prior to migrating the data. For more information see Purge Configurator Tables.
Verify that the target CZ schema is empty before you run the Setup Configurator Data Migration concurrent program on the target database instance.
Note: An "empty" schema means a new Oracle Applications installation that contains no data. If you must remove data from an existing instance and use it as a target of data migration, then contact Oracle Support Services for assistance.
Run the Migrate Configurator Data concurrent program from the target database instance. For more information, including possible issues recorded in the log file, see Migrate Configurator Data.
Resolve all issues or errors that are reported in the log file.
Verify that the Import Enabled flag on the source database instance is enabled. For more information, see Enable Remote Server.
If you will be importing BOM Model data to the target instance from a different server from which you migrated the data, then run the Synchronize All Models concurrent program on the target instance.
For example, your import source is DB-X and you import BOM Model data from DB-X to DB-1. You then migrate data from DB-1 to DB-2. If you will be importing data to DB-2 from any database other than DB-X, then you must run the Synchronize All Models program on DB-2.
For more information on BOM Model synchronization, see The BOM Model Synchronization Process.
Migrating models is the process of copying configuration model data from one instance (the source) into another development instance (the target). Imported BOM Models and Models created in Configurator Developer can be migrated, and you can migrate one or multiple Models at the same time. After the migration process completes successfully, you can view and modify the migrated Models in Oracle Configurator Developer on the target instance.
Note: Do not confuse Model migration with data migration. Data migration refers to migrating the entire CZ schema into an empty database instance, whereas Model migration refers to migrating specific Models and their structure, rules, and UIs to another database instance.
When you migrate a Model for the first time, it creates a Model with the same name on the target instance. If you migrate the same Model again, a new copy is created on the target, and its default name is "Model Name (Migrated from source DB name: Repository Folder path." Any subsequent migration of the Model creates Models called "Model Name (Migrated from source DB name: Repository Folder path copy x)." Migrating a Model creates a copy of that Model on the target instance, regardless of whether the Model has changed on the source instance. For details about how the migration process handles referenced Models, see Migrating Referenced Models.
To migrate a Model, the target database instance must be a development instance (it cannot be a publication target), and both the source and target instances must have the same schema version.
The following objects that are part of or are associated with the selected Model are copied to the target instance:
Model structure
Rules
User Interfaces
Referenced and connected Models
UI Templates
Usages
Effectivity Sets
Configurator Extension Archives
Populators and Item Master data
Properties
For details about data synchronization criteria and a list of what is not copied during migration, see Synchronizing Migrated Model Data.
Migrating Models is a two step process:
In Configurator Developer, specify which Models you want to migrate.
For details, see the Oracle Configurator Developer User's Guide.
Run the Migrate Models concurrent program.
See Migrate Models.
These steps can be performed only by the Oracle Configurator Administrator.
Note: A Model's compiled logic is not migrated to the target instance. After migrating a Model, you must open the Model for editing in Configurator Developer on the target instance and generate logic. Additionally, you may need to update saved configurations of the migrated Model so they can be restored successfully. For details, see Restoring Saved Configurations of Migrated Models.
Model Migration Examples
The following examples show possible scenarios in which it may be useful or necessary to migrate Models. It should be noted however that these examples are not intended to show best practices or a recommended way of building and maintaining configuration models.
The illustration Migrating Models Serially shows the migration of a Model across several development instances before being migrated to the production instance. In this scenario, each development instance is used to develop a specific area of the Model, such as Model structure in Instance 1, rules in Instance 2, and UIs in Instance 3. After unit and system testing is complete, the final version of the Model (A2) in Instance 3 is published to the Production instance.
The illustration Migrating Models from Multiple Development Instances shows the migration of a Model from several development instances to a single test instance, before publishing to a production instance. In this scenario, several different areas of a Model are developed in isolation in separate development instances and then the Models are migrated and synchronized in the test instance before being published to the production instance.
Migrating Models from Multiple Development Instances
A configuration model that has been published can be migrated into another development instance for additional modification without affecting the published Model.
The Migrate Models concurrent program detects whether the root Model (parent) or one of its referenced (child) Models has been previously migrated to the target instance, and whether the child Model has changed on either the source or target since the last migration.
If you migrate a Model that references a previously migrated Model, and the child Model has not changed on the source instance, then the migrated parent refers to the existing child on the target instance. If the child Model has changed on either the source or the target instance since the last migration, then a new copy of that Model is created on the target instance. If the child Model does not yet exist on the target, then it is migrated (for example, a new reference was created in the parent Model on the source instance).
The illustration Migration of Referenced Models shows examples of Models with referenced Models that are migrated to another instance. When Model A is migrated, copies of both Model A and its child Model B are created on the target instance. You then migrate Model C, which also references Model B. Model B has not changed since the last migration, so the copy of Model C references the existing copy of Model B on the target.
Model B is then modified on the source instance (for example, new Model structure is added), so when you remigrate Model A, a new copy of both Model A and its child Model B are created. Model B is modified again on the source, so when you remigrate Model C, new copies of both Model C and its child Model B are created on the target.
The migration process does not create a new copy of a referenced Model if only the Model's name has changed.
Migration of Referenced Models
It is possible for the process of migrating Models to create a situation in which the persistent node identifier (persistent_node_id) that Oracle Configurator uses internally to identify configuration nodes are not able to uniquely identify Model nodes when restoring a saved configuration. This can occur when, for example, a pre-Release 12 instance that contains saved configurations is upgraded to Release 12 or later. In Release 12 and later, saved configurations store both node names and a persistent node ID.
The following concurrent programs add Model node names to saved configurations and enable Oracle Configurator restore them successfully:
You must run one of these concurrent programs on a migration target instance if all of the following are true:
The instance was upgraded to Release 12 (or later) from a prior release
You intend to publish Models from the instance
You want to be able to restore configurations of published migrated Models on the instance
When synchronizing Model data, the Migrate Models concurrent program matches the source configuration model's internal keys that refer to BOM and Inventory data with comparable data on the target instance. The data are comparable when the Item and Inventory Organization names of the data being migrated match data of the same type on the target instance. All of the migrated BOM Model's referenced Models are also synchronized with comparable BOM Models on the target instance. For more information, see Migrating Referenced Models.
After the synchronization completes successfully, the Item IDs for the migrated BOM Model reflect the IDs on the target instance. If the name or structure of the BOM Items on the source and target instances is different, then the migration fails. For more information, see Result of Synchronizing BOM Models.
During Model migration, the following occurs:
Populators that reference Item Master data such as Item IDs, Property IDs, and/or Item-Type IDs, are changed to reference the migrated data. However, Populators that match Item Master data by name are not changed during migration.
Item Master data that exists in the source but not in the target is migrated. This includes missing items, values, and assignments. Existing Item data on the target instance is not changed. The migration process never overwrites or modifies any existing data on the target instance.
Repository objects such as Usages, Properties, and Effectivity Sets that exist in the source but not in the target are migrated.
Because multiple Models may refer to the same Repository object, creating multiple copies of that object on the target instance is both unnecessary and undesirable. Therefore, synchronization that occurs during Model migration redirects any references to Repository objects on the source instance to equivalent Repository objects on the target instance.
The log file that is created when you run the Migrate Models concurrent program describes the results of the migration. An example of this file is shown below.
Example of a Log File Generated by the Migrate Models Concurrent Program
Item 'SMX_1 Model' already exists on the migration target instance. All migration objects in the migration target instance that reference 'SMX_1 Model', will be changed to use the Item.
.
.
.
The Effectivity Set for rule 'LR-O11 R O21' already exists in the migration target instance. Rule 'LR-O11 R O21' is part of the Rule Sequence 'RS'. All rules in Rule Sequence 'RS' will be changed to 'Never Effective'.
.
.
.
Effectivity Set 'Eff - Delete 1' already exists on the migration target instance. All migration objects in the migration target instance that reference 'Eff - Delete 1', will be changed to use the Effectivity Set.
To view this log file, click View Log from the Requests page after the Migrate Models concurrent program completes successfully.
For more information, see Synchronization Criteria During Model Migration.
The following table provides the synchronization criteria for the different types of Configurator data that is not Model-specific. The columns include Object Type, Matching Criteria, Synchronization Condition, and Result.
Object Type is the data that is migrated and used to match the comparable Model's object. Matching Criteria is the specified Object type's data that is used for matching. Synchronization Condition is the condition that must exist for the object to pass synchronization. The Result column indicates the end result of the migration based on the synchronization condition.
Object Type | Matching Criteria | Synchronization Condition | Result |
---|---|---|---|
Property | Property Name, src_application_id | Data Type and default value are the same | Migrated Model is changed to reflect existing data on the target instance |
Data Type is the same, Property default value is different | Default Property value on the migrated Model will be different than on the source Model | ||
Data Type is different | Migration fails | ||
Item Type | Item Type Name, src_application_id | Item Type Name and Properties are the same | Migrated Model is changed to reflect existing Item Type on the target instance |
Additional Properties exist on the Item Type in the target instance | Migrated Model acquires any additional Properties on nodes that are associated with that Item Type | ||
Source Item Type has additional properties | Migration fails | ||
Item | Item name (ref_part_nbr), src_application_id | Item Type Name and Item Property values are the same | Migrated Model is changed to refer to existing Item on the target instance |
Item Type is the same, but Item Property values are different | Migrated Model is changed to refer to existing Item Type on the target instance, property values remain unchanged on target | ||
Item Type does not match | Migration fails | ||
UI Content Template | UI_DEF_ID = 0, TEMPLATE USAGE = ‘0’, Template Name | TEMPLATE TYPE, MESSAGE_TYPE, ROOT_ELEMENT_TYPE, MAIN_MESSAGE_ ID, PARENT CONTAINER TYPE, ROOT ELEMENT SIGNATURE ID, and ROOT_REGION_TYPE are the same | Migrated Model is changed to refer to existing UI Content Template on the target instance |
TEMPLATE TYPE, MESSAGE_TYPE are the same, but ROOT_ELEMENT_TYPE, MAIN_ MESSAGE_ ID, PARENT CONTAINER TYPE, ROOT ELEMENT SIGNATURE ID, or ROOT_REGION_ TYPE are different | Migration fails | ||
Mismatch on TEMPLATE TYPE or MESSAGE_TYPE | The template is migrated to the target instance, it is renamed (if a Template with the same name exists on the target), Template references are changed to reflect the change, and a warning message is displayed. | ||
UI Master Template | Name, UI_DEF_ID = 0 | (no conditions) | Migrated Model UIs always acquire the target's Master Template's characteristics |
Effectivity Set | Name | (no conditions) | The Migrated Model acquires the settings of the matching Effectivity Set on the target (see Migrating Effectivity Sets Used in Rule Sequences)) |
Usage | Name | Usage Name is the same | Update to indicate the ID of the Usage on the target |
Name does not match and there are less than 64 active Usages on the target | Usage is migrated | ||
Name does not match and there are 64 active Usages on the target | Migration fails | ||
Archive (for Configurator Extensions) | Archive_name | (no conditions) | Migrated Model uses the target's existing Archive |
Populator | Item ID, Property ID, Item Type ID | (no conditions) | If the Populator references Item Master data by ID (Item ID, Property ID, or Item Type ID) then it is changed to reference the data on the target. If the Populators match Item Master data by name, then the Populator is not changed. |
BOM Import Source | Import server on source and target instances | The source BOM Model's import source does not match the target BOM Model's import source | The BOM Model's import source is changed to reflect the import source for the target |
When you migrate a Model, all of the Model's Rule Sequences are also migrated to the target instance. If any of the rules in a Rule Sequence refer to an Effectivity Set that exists on the target instance, all of the rules in the Rule Sequence will be set to 'Never Effective' after the migration is complete. (This change will be listed in the Migrate Models concurrent program log file. For details, see Synchronizing Migrated Model Data). You may want to modify the Rule Sequence on the target instance and specify new effectivity dates for each rule in the set.
If a rule refers to an Effectivity Set that exists on the target, and the rule is not part of a Rule Sequence, then the rule refers to the Effectivity Set on the target after the model is migrated.
Copyright © 1999, 2010, Oracle and/or its affiliates. All rights reserved.