When migrating objects where foreign key references are captured
in the object's CLOB, 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 CLOB-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 CLOB 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 CLOB. 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 © 2000, 2015, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.19.2015 16:18:51 [F1_1424305131000]