To export data, there must be a migration request that references one or more migration plans. The migration plan is a set of instructions that defines the structure of an object to be exported. It may also contain instructions for foreign keys related to the object.
The definition of the migration plan for a given object and the instructions to include depend a little bit on the type of migration request that it will be included in. It also depends on whether or not the foreign key is a physical column in the object or if it is captured in the BO Data Area (CLOB) or as a flattened characteristic. The instructions for foreign keys serve two purposes:
Copy Related Data. The instructions serves as an indication to the CMA tool that the related object represented by that foreign key should also be copied. For example, a migration plan for Tax Type may have an instruction for its Revenue Calendar. If the Tax Type migration plan is included in a migration request but the Revenue Calendar migration pan is not, the revenue calendars related to the migrated tax types will also be migrated. This is true whether the foreign key is linked as a real column or defined in the BO Data Area for one of the business objects for the migration plan’s maintenance object.
Group Related Data. For a migration request that includes a list of migration plans for different objects, the instructions help the CMA tool to group together objects in a logical ‘transaction’ for importing. For example, imagine the migration plan for Person Type contains an instruction for its default Identifier Type. If a migration request includes the migration plans for both Person Type and Identifier Type, the CMA tool will export all Person Types and Identifier Types. In addition because of the instruction on Person Type indicating that there is a relationship between person type and identifier type, the CMA tool will ensure that any Identifier Type defined on a Person Type will be grouped for import with its related person type. The result is that at import time the Identifier Type is added before the Person Type preventing any foreign key validation issues.
Configuration migration assistant may be used for two broad types of data migration:
Wholesale migrations. This is where an implementation is trying to “copy all” administrative data from one environment to another. For example, if trying to set up a test region that mirrors production in order to recreate a bug. Another example is to “promote” configuration changes from a test region to production after testing the new configuration. In these types of migrations, the migration plans for objects that include foreign key data in the BO Data Area, it is beneficial to have sub-instructions for all foreign keys. This will allow CMA to correctly group related data.
Piecemeal migrations. This type of migration is more targeted and would only copy a subset of maintenance objects or a subset of data within a given set of maintenance objects. Some examples:
A set of new form types for the coming year are defined and their data should be copied to a test region.
The new dates for all the revenue calendars have been added for the coming year and should be copied to production.
A new calculation control is introduced with the changes for the coming year’s property tax calculation rules and should be copied to a test region.
For these types of migrations, it is beneficial to only include sub-instructions for the foreign keys that need to be included. For example, in the case of a new form type, if it is for an existing obligation type, there is no need to copy the obligation type and all the data that is related to that. Ideally, the migration should only copy the data that is expected to be new or changed as a result of the new form type.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]