Supporting Migration Based on Custom Mapping

Activation of Custom Mapping

In DELMHubMappingConfig.xml (win_b64\resources folder) you have to activate custom migration by providing the mapping file.

The following figure shows you to activate the mapping.

Mapping Schema

MHubMigration: This is the root node of the custom mapping file. MHubMigration node will have one child node for each Plantypeset present in DELMIA Process Engineer; and you must define a child Plantypeset node if a project of a particular Plantypeset is being migrated. If the user needs to define two separate mappings for the same Plantypeset, it should done in two separate customization files and the user needs to specify one of these during migration (in DELMHubMappingConfig.xml). For every Plantypeset, user needs to define name attribute and it is the name of the Plantypeset in E5. There is also a node 'Options' which provides some general options which are common to Migration.

Options: You need to define different options determine migration and/or metadata generation behavior. Following section explains these options:

Top level Scope: This option is only applicable for migration and not for metadata generation. If this option is set, scope links get created between the top level objects. The following conditions need to be met

• Process – Product scope links between top level objects get created only if there is one top level product specified. If there are multiple top level processes, scope links get created for each top level process.
• System – Process scope links between top level objects get created only if there is one top level process specified. The top level resource also needs to be mapped to a system for this link to be created. If there are multiple top level resources mapped as systems, scope links get created for each top level process. Apart from the above, System – Process scope links also get created for each top level process which gets created as both process and system.
• Resource – System scope links between top level objects get created only for top level resources which are mapped as both organizational resource and system. If there are multiple top level resources meeting the above condition, scope links get created for each of top level resource.

AllPlantypes: This option is only applicable for both migration and metadata generation. This option determines the behavior as follows:

• Metadata Generation: If this option is set to 0, metadata will be generated strictly according to the mapping specified in the custom mapping file. If this option is set to 1, metadata will be generated for all plantypes as per their default types in addition to the metadata for the types specified in the custom mapping file.
• Migration: If this option is set to 0, only objects of plantypes specified in the custom mapping file will be migrated. If this option is set to 1, objects of plantypes not specified in the custom mapping file will be migrated as default types.

Plantypeset: This node is the child of the MHubMigration node. This node provides mapping details for all the plantypes present in the PlantTypeSet.

Plantype is the child node of Plantypeset and Type is the child node of Plantype. You need to define one Plantype node for each E5 plantype and you can define multiple V6 types for each plantype.

The following image shows a sample mapping xml and the table shows the resultant mapping.

Local Scope Link Attribute

Local scope is part of Plantype and then the local scope links are created. You can choose to create scope links at each object level. If this attribute is set to 1, then the local scope links are created for objects corresponding to this plantype in addition to the global scope links (which are always created) and the top level object scope links (if specified).

• If an E5 object is created as both System and Process in V6, a scope link is created between the System and the Process
• If an E5 object is created as both Resource and System in V6, a scope link is created between the Resource and the System
• If an E5 object is created as both Process and Product in V6, a scope link is created between the Process and the Product

Attribute Migration

All the plantype attributes (as defined by HideIn3DLive property in E5) is available in the generated metadata. The attributes can be mapped to other type attributes using custom type mapping and attribute mapping rules.

Common Behavior

The capability to filter out objects from E5 product or process or resource tree can be used as all branches may not be used in actual planning.

E5 Relation Migration

Process-Product Links: If the process (having the relation) is mapped as a process, then a provide process is created under this process and an implement link is created between the provide process and the Product (provided it has been migrated).

If the process (having the relation) is not mapped as a process, then the provide process is created under the first parent process which is mapped as a process. If the process (having the relation) is also mapped as an operation, then an Implement link is created between this operation and the provide process.

Process-Resource Links: If the process (having the relation) is mapped as an operation, an implement link will be created between the operation and the resource (provided it has been migrated). Otherwise, no implement link will be created.

Process-Process Links: If both the processes (having the relation) are mapped as process, a Precedence Link will be created between these processes. If both the processes (having the relation) are mapped as operations, a Time Constraint will be created between these operations

Metadata Generation Details

Metadata is created based on the V6 type mapping definition provided in the XML. If there is only one V6 type mapped to a plantype, then, only one metadata is created for that plantype, if otherwise multiple metadata are created.

AllPlantypes=1 : Metadata is generated as it is done everyday, that is, one metadata will be generated per plantype corresponding to the E5 Type. So, a product and resource plantype has a metadata deriving from product modeler; a process plantype has a metadata deriving from functional process modeler.

In addition to the above, the metadata is generated corresponding to the additional types specified in the xml file. Metadata is not be re-generated for the default types

AllPlantypes=0 Metadata is generated only for plantypes specified in the custom mapping xml file for the mapped types.

The valid tags for V6 types and the corresponding modelers are listed in the following table:

Mapping Illustration

The following example illustrates how the mapping is applied to transform an E5 structure to a V6 structure.

• All objects of E5 plantype Workplan is migrated as Process and General System
• All objects of E5 plantype Subassembly and Part is migrated as Products in V6
• All objects of E5 plantype Operation is migrated as General Operation