When migrating objects where foreign key references are captured
in the object's XML based field, subordinate instructions are needed
to define the foreign key references in order for CMA to understand
the relationships. This is in contrast to direct foreign keys where
CMA can determine the relationships using constraints. The instructions
provide two purposes. For wholesale migrations, where all data (or
a large amount of data) is being migrated, the instructions allow
CMA to group related objects into transactions. This helps in the
apply process at import time to ensure that related objects are grouped
together. However, the apply process includes iterative steps to try
to overcome dependencies like this so defining the instructions is
not critical for this type of migration. For piecemeal migrations,
defining instructions ensures that the related objects are included
in the migration, if appropriate.
The following are options for creating migration plans with XML-embedded
links:
- One option is to use the specific logical (business) BO in the
primary instruction to define the object you are copying. With this
option, the subordinate instructions may use XPath criteria to define
the related foreign key. When this approach is used, a separate Migration
Plan must be created for each logical BO. (Refer to Understanding the BO Filtering Process for more information.)
This option would only be used in isolated cases.
- Another option is to create a migration plan that uses the Physical
BO as the primary instruction, and then include a subordinate instruction
for the real logical BO, using SQL Traversal to join the object to
itself by its primary key. Note that with this technique, the records
that reference the logical BO will still only be included in the export
file once. At this point further subordinate instructions may use
XPath notation to define the foreign key data. Using the physical
BO as the primary instruction ensures that all records in the MO are
considered. The subordinate instructions with the logical BO and
XPath notations will only apply to the records that are applicable
to that BO. This option is useful for MOs that have a small number
of logical business objects with disparate foreign keys.
- Another option is to use the physical BO in the primary instruction
and use raw SQLs in the subordinate instruction's traversal criteria
to identify the foreign keys using substring commands. A separate
Subordinate Instruction is needed for each SQL corresponding to each
element occurrence. Using this technique has the same advantages
of the previous in that all records for the MO are included in the
migration. However, this technique may be useful for maintenance
objects with a larger number of business objects expected where each
has one or more foreign keys. It's especially useful if many business
objects reference the same foreign key. Then only one instruction
is required for that foreign key. Note that a single migration plan
may use this technique and the XPath technique for different elements.
A migration request may have multiple migration plans for the same
maintenance object. That allows for some flexibility and long term
maintainability in that the above techniques may be used in multiple
migration plans. Consider the following example:
- A product provides base business objects with foreign keys defined
in the XML field and provides the appropriate migration plan with
instructions. An implementation extends this business object or perhaps
creates their own business object for the same maintenance object
and includes different additional foreign keys in the XML. Rather
than duplicating the base migration plan and adding additional instructions
for the additional foreign keys, the implementation can create a second
migration plan for the MO with the additional foreign keys defined.
A migration request should be defined to include both migration plans.
In this case if the implementation has only one custom BO, they can
choose to use the custom BO as the primary instruction as described
above in the first option.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]