This topic describes special information relating to migration objects provided for use by CMA in the product. Additional objects may be provided by your specific product. Any special information for objects is provided separately in each product's documentation.
You can see all currently available objects and their descriptions by performing a search in the Migration Plan Query or Migration Request Query pages.
The following points highlight some information about the Framework-provided migration plans and migration requests:
Fields and characteristic types are not migrated with the object unless specifically indicated.
The Application Service used by an object is migrated only if it is CM-owned.
The F1-Language migration plan should never be used in a migration request with other objects. Defined constraints will cause CMA to link all objects with a language table—which is almost all of the system admin data—into one large transaction. Attempting to update and commit all the changes for this one large transaction may cause performance issues and/or out of memory errors. For this reason, this MO has its own migration request, F1-Languages.
The migration request F1-SchemaAdmin defines migration plans related to data that is commonly used in schema-based objects.
The Batch Control object optionally references a User. If this user does not exist on the target system, CMA cannot apply the requested changes.
The base migration plans for MO and BO include instructions to copy option types that use foreign key references to refer to other objects. Note that the data stored in the options are not validated, so defining these instructions is not required when doing wholesale migrations. However, including subordinate instructions for foreign key references is useful for piecemeal migrations to ensure that the related data is included in the migration. If you add additional MO or BO option types that use foreign keys and you want to support piecemeal migrations, you must create custom migration plans and requests for MO and BO, respectively to include these referenced objects in the migration plan. Note that you do not need to duplicate the instructions in the base migration plans. You may define the additional migration plans to only have the additional custom option types. When submitting a migration request for MO or BO you must include both the base migration plans and the custom migration plans in the request.
The migration plans provided by CMA migrate scripts, schema-based objects and zones, and, through constraints, some of the associated data associated with them. However, data specified through alternate formats (such as through Edit Data steps in scripts, referenced in schemas for schema-based objects, or data from mnemonics in zone parameters, etc.) are not identified and combined in the same transaction. It's important to note that this could cause validation errors during Apply, and may require retrying or migrating the additional data separately. See Apply Step for a description of how to reapply the import should an Applied With Errors result occur.
There are two migration plans for Scripts. The migration plan F1-ScriptOnly migrates just the script and its Application Service (provided the Application Service is CM-owned). This is used in the F1-FrameworkAdmin migration request, which migrates all admin objects. The migration plan F1-Script includes most related objects, but does not migrate any objects referenced in the edit data area steps. It does not move the Function maintenance object (which has been deprecated). This migration plan is not included in any base migration requests. It may be included in any appropriate custom piecemeal migration request where scripts and related data should be migrated.
If your implementation includes a Feature Configuration setting for the F1_DBCONINFO entry that will be included in a migration request, be sure that the import user on the target region has the appropriate security rights to this entry (Super User access mode for the Feature Configuration application service (CILTWSDP).
All of the provided Framework-owned migration requests include the SQL statement "1=1" so that all records in the plan are migrated. If an implementation wants to limit a migration to a subset of records, the prepackaged migration request may be duplicated and then customized to modify the key selection criteria.
Many of the XAI-related maintenance objects include references to environment-specific data, and data should be migrated with extreme care. Migration plans are not provided for MOs that contain mostly environment-specific data. Migration plans are provided for the following XAI-related maintenance objects, but these plans are not included in the F1-XAI-Admin migration request: External System, XAI Receiver, Message Sender, and XAI Route Type.
The following framework provided migration requests may be used in a wholesale migration. Refer to your specific product’s CMA documentation for its recommendation on which migration requests to use for a full migration of framework and product administrative tables.
For each migration request determined to be needed for a wholesale migration, create a migration data set export record and process it as documented in Exporting a Migration.
Piecemeal migrations involve copying a targeted set of data. It may be that it includes a subset of maintenance objects (for example all Activity Types or all Asset Types) or it may further limit the records within one or more maintenance objects (for example, all ‘electric’ rates). Many piecemeal migrations are ad-hoc, depending on the specific requirements at the time.
If your product has provided migration requests for piecemeal migrations out of the box, it would they would be defined to copy the appropriate type of data. However, the selection criteria would most likely not be limited to a type of record. As such, it could be used as is for a “copy all data in these maintenance objects” migration. For example, the framework provides a migration request for Security Configuration. This may be used to copy all the data in the various security tables. Oracle Public Sector Revenue Management provides a migration request to copy form types and its related data.
If your implementation wants to copy only a subset of data for maintenance objects covered by a base provided migration request, do the following:
Duplicate the base migration request.
Find the migration plan for the object or objects where you want to limit the data. Enter appropriate Key Selection criteria to select the desired data.
Use that migration request to request a migration data set export request.
If your piecemeal migration requirement is not satisfied by a base migration request that may be used as a starting point, review the base migration plans for the records that should be copied. Determine if the migration plans have the desired subordinate instructions to copy (or not copy) the related data as desired.
If existing migration plans satisfy your requirements, create a migration request that includes those plans (and desired key selection as needed). Use that migration request to create a migration data set export request.
If existing migration plans do not satisfy your requirements, create migration plans as needed. Create a migration request that includes those plans (and desired key selection as needed). Use that migration request to create a migration data set export request.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]