Adoption is used to assign common ancestry to an object for the purpose of migration. The original encyclopedia ID and the original object ID of the selected destination model object are updated to match the original encyclopedia ID and the original object ID of the equivalent object in the source model. Adoption establishes a correspondence between objects that are alike so they can be migrated or compared.
The adopt function automatically unadopts component objects. Component objects that do not get adopted are given a new original encyclopedia ID and a new original object ID to sever any common ancestry they may have. Incremental commits are not taken during the adopt function. Adoption of large models can cause contention.
To avoid contention, you can selectively adopt large models rather than using the All option.
The following table lists the suggested order of adoption for specific object types and the prerequisites that are required for the adoption of the objects:
|
Object Type |
Prerequisite |
|---|---|
|
Relationships |
Entity types |
|
Data records |
Entity types, Relationship |
|
Tablespace |
Databases |
|
Commands |
Business system |
|
Templates |
Business system |
|
Functions |
Entity types and work attribute sets defined in views |
|
Processes |
Entity types and work attribute sets defined in views |
|
BAA common action blocks |
Entity types and work attribute sets defined in views |
|
BSD common action blocks |
Entity types and work attribute sets defined in views |
|
Procedure |
Business system, entity types and work attribute sets defined in views |
|
Dialog flow |
Procedures, Exit states |
|
Online load module |
Business system |
|
Window load module |
Business system |
|
User defined matrix |
User defined object class |
All other selectable objects do not have prerequisites and can be adopted in any order.
|
Copyright © 2013 CA.
All rights reserved.
|
|