Enterprise Administration > Business Administrative Change Promotion > Running the Business Administrative Change Promotion Command-Line Utility > Sample Use Cases for Type Definition
Sample Use Cases for Type Definition
You can exchange all Type Definition objects in its entirety including hierarchical information. However, it is also possible to exchange BAC information of following objects independently:
• Reusable attributes
• Quantity of measure
• Global enumerations
• Measurement systems
The following table provides information about import and export of Type Definition object based on sample use cases.
Use Case
Export
Import
The below screenshot shows a sample of BAC package which is to be exchanged:
In this use case, all the document type definitions are exchanged without any changes.
All the type definitions are collected for export.
BAC information of only LWCTypeDefinition objects is exchanged.
All the information about type and their associated base definition objects are exported to a folder which is archived in the BAC package zip.
All the objects are imported as new objects.
Incremental:
• Attribute change in ‘ECAD Data’.
• Layout change in ‘Minutes’.
‘ECAD Data’, and ‘Minutes’ are collected for export.
BAC information of above are exchanged along with their ancestor’s BAC information.
All the information of only listed types and their associated base definition objects are exported.
All the existing objects for update action are identified and the objects are imported
Incremental:
If there exists an attribute Attr1 used in ‘General’ type only, then following actions are performed:
• Delete an attribute Attr1 association present in ‘General’ type.
• Delete the reusable attributeAttr1.
‘General’ type definition is collected for export.
Delete tracking is not done for attribute association.
‘General’ type definition is updated after loading is completed.
Information about attribute Attr1 associated with ‘General’ type is loaded to a temporary location. User should be able to delete based on any existing mechanism manually.
Incremental:
If there exists an enumeration constraint for an attribute EnumAttr1 used in ‘Document’ type, then the following action is performed at the source system:
Add an enumeration entry for EnumAttr1 enumeration definition.
No objects are selected for export as base definition object change is not tracked. The enumeration definition modification change does not have direct impact on ‘Document’ type definition.
No data to import.
If the constraint is a local enumeration that is based on the global enumeration, then Document type will be updated.
Incremental:
Delete the type definition ‘Reference Document’.
‘Reference Document’ type definition deletes record collected for export.
‘Reference Document’ type definition is deleted at the target system during delete processing stage.
Incremental:
Rename the type ‘MM Drawing’ to ‘Model Drawing’ in the source system.
‘Model Drawing’ collected for export.
‘MM Drawing’ is searched based on Collaboration Information. Rename is performed at the target system during find.
Renaming a type involves changing its internal name. The property values of a display name can be changed but that does not constitute a rename.
Incremental:
• Rename the type ‘MM Model’ to ‘Manager Model’ in the target system.
• Modify an attribute for ‘MM Model’ in the source system.
‘MM Model’ collected for export.
During find, renamed Manager Model type is found by collaboration information. The conflict is thrown to the user with following resolutions:
• Overwrite — The type will be renamed back to ‘MM Model’.
• Skip — A new type will not be created.
Incremental: (Root type modified in target system)
• ‘Document’ type added with new attribute in the target system.
• ‘Plan’ soft type is modified in source system.
‘Plan’ soft type is carried along with ‘Document’ BAC information.
A conflict will be thrown for modified ‘Document’ type. The resolution provided for the conflict is Skip.
* 
There can never be any further transfers from source system to target system, until the root type is exchanged and overwrites the target system version. It is applicable to any type which is modified in the target system and has descendants.
Incremental:
New soft type BACDocument added under ‘Document’ type.
The BACDocument is exported with ancestor information.
BACDocument is imported as a new object.
Incremental:
• Create a WTDocument with soft type ‘Presentation’ in the target system.
• Delete the soft type ‘Presentation’ in the source system.
‘Presentation’ delete record will be exchanged.
Conflict check during Delete Processor identifies the “Where used” object. The conflicts will be thrown with following resolutions:
• Retry and Skip for selective and development mode.
• Retry for Synchronize mode.
Incremental: (Delete and Recreate)
• Delete the type ‘Agenda’.
• Recreate the type with same internal name.
New ‘Agenda’ type is collected for export.
Delete record of old type ‘Agenda’ is also collected for export.
BAC Delete processor runs a search based on Collaboration Information and deletes the existing ‘Agenda’ in the target system.
A new ‘Agenda’ type will be created.
* 
The sample use cases are for illustrative purposes only and these types will not be available to be loaded in the system.
Was this helpful?