Solution

Personalizzazione avanzata > Business Logic Customization > Customizing MPMLink > Configuring and Customizing Automatic BOM Transformation > Solution

Solution

Use the out of the box configuration and customization hooks to implement your logic.

Prerequisite Knowledge

To perform this task, you need to have an understanding of the following:

• Basic MPMLink and BOM structure

• Basic development involving Java

• Management of resource bundle file customizations

• Windchill xconfmanager concepts

You can configure the rules for transformation using properties or a rules file in JSON format. For more information on the rules file, see Rules File.

Solution Elements

The out of the box configuration for the main class that handles the template flow is located in the <WT_HOME>/codebase/com/ptc/windchill/mpml/xconfs/mpmlink.service.properties.xconf file.

The configuration is given below:

You can update the configuration to include custom delegate.

The out of the box property configuration is provided in the <WT_HOME>/codebase/com/ptc/core/foundation/associativity/xconfs/associativity.properties.xconf file.

The out of the box property configuration given below provides the default behavior to perform transformation the same way as under the nearest common equivalence context:

These out of the box properties let any instance of WTPart to be pasted anywhere on the downstream structure, which means no constraints.

The properties are supported for Part Usage and Part. Priority is always given to Part Usage. Only when Part Usage is valid, the configurations for Part is considered. If you do not want to control the transformation for Part Usage, keep the out of the box property configuration for the Part Usage, which makes all the usages to be valid.

The format of the property is: <base_prefix>.<upstream_view>.<downstream_view>.<type_internal_name>. The keys for the property are explained in the given table:

Element	Type	Description
base_prefix	Property Key Component	The prefix com.ptc.windchill.associativity.reconciliation.addusage is mandatory and constant. Only properties with this prefix are considered for the add template configurations.
upstream_view	Property Key Component	The internal name of the view, which forms the upstream view context for equivalence link. For example: design. This key needs a corresponding downstream_view configuration as well. The key is optional.
downstream_view	Property Key Component	The internal name of the view, which forms the downstream view context for equivalence link. For example: manufacturing. This key needs a corresponding upstream_view configuration as well. The key is optional.
type_internal_name	Property Key Component	The internal name of the type that is valid for transformation. The key should not contain the hierarchy name. For example: com.ptc.ElectricalPart. This key supports inheritance. So, if defined for a super type, the associated configurations are applicable for sub-types, unless explicitly defined. The key is mandatory.

Examples of configuring the property with the above keys are given below:

• Specifying the type: com.ptc.windchill.associativity.reconciliation.addusage.wt.part.WTPart

• Specifying the type with the upstream and downstream view: com.ptc.windchill.associativity.reconciliation.addusage.design.manfacturing.wt.part.WTPart

The system supports reading property for the usage and child in the same order of priority. All the properties are supported for usage as well as child though it may not be applicable in some cases.

For each of the property keys, you can define a list of key=value pairs. The pairs are customizable and additional options can be added which will be available in the delegates and can be handled using custom logic. The out of the box key value pairs are given in the table:

Element

Description

transformOption

Describes how the given type should be transformed in a downstream structure. The default valid supported values are addSame, newBranch, and newPart. These values are equivalent to the interface actions Paste, Paste as New Branch, and Paste as New Part.

If a downstream structure exists, the service internally prioritizes the addExisting option. If not specified, the default value is addSame.

The value is case sensitive.

An example using the rules file is given below:

{
"sourceType": "wt.part.WTPart",
"transformOption": "newBranch"
},

An example using the property file is given below:

As per the example, the parts with the type as WTPart are added as new branch to the downstream structure.

structureOption

Describes the action to be performed on the children of the node which is being transformed. You can carry forward the children, transform the children recursively, or not carry forward the children.

Valid values are 0, 1, and 2. For example, structureOption=0. The default value is 0. The values are explained below:

• 0: Do not duplicate the children.

• 1: Duplicate the children but do not transform them.

• 2: Duplicate the children and recursively transform them.

In some cases, the value maybe not applicable. For example, if transformOption is addSame, then structureOption is not applicable.

An example using the rules file is given below:

"sourceType": "wt.part.WTPart"
"transformOption": "newBranch",
"structureOption": "1",

An example using the property file is given below:

As per the example, the specified parts are transformed as new branch and are duplicated without propagating.

attribute.<internal_name> (property file)

sourceAttributes (rules file)

Specifies the internal name of the attribute on the type which is used to control transformation validity. The supported attribute types are Global, Local, Alias, and Calculated.

This is a multi-valued property and allows specifying multiple attributes. This is optional and if not provided, transformation is validated only on the type. Out of the box, the system performs string comparison.

An example using the rules file is given below:

"sourceType": "wt.part.WTPart",
"sourceAttributes": ["AUA=yes"],

An example using the property file is given below:

As per the example, the parts with the attribute AUA as Yes are added under the downstream structure.

targetType

Identifies the downstream type under which valid upstream parts can be consumed. The path containing the given type in hierarchy is marked as valid. You need to specify the internal name of the type as the value and not the hierarchical name of the type.

It is optional. If not specified, the nearest common equivalence context is used as the default target.

An example using the rules file is given below:

{
"targetType": "wt.part.WTPart",
"transformOption": "newBranch"
},

An example using the property file is given below:

As per the example, the parts are added as new branch under the downstream parts that are of type WTPart.

targetAttribute.<internal_name>

Specifies the target node where the upstream node should be pasted or transformed. It contains the prefix targetAttribute.

It is optional. If not provided, the system uses targetType. It stops at the first matching instance in the path hierarchy, navigating from the leaf to the root.

An example using the rules file is given below:

[
"source.part.attribute1:String1",
"target.part.attribute2:String2"
],

An example using the property file is given below:

As per the example, the upstream part with String1 value for attribute1 should be added under the downstream part with String2 value for attribute2.

doAndValidationForAttr

Specifies whether to perform an AND or OR operation to find a match when multiple attributes are defined for matching on the source or target.

Default is true.

An example using the rules file is given below:

"newAttributeMappings":[
[
"source.usage.Attribute1:true",
"target.part.CustomAttribute1:String1",
"doAndValidationForAttr": "true"]
],
"targetType": "wt.part.WTPart",
"transformOption": "newPart",
"skipAttributes":
[
"source:buy",
"Attribute2":"true"
]

An example using the property file is given below:

As per the example, if there is a part in the upstream structure with Attribute2 set as true and attribute Source set as buy, then the part is skipped and is not added in the downstream.

forceNewDownstreamCreation

Specifies if a new downstream part should be created when a downstream branch or part already exists. Default value is false.

An example using the rules file is given below:

{
"sourceType": "wt.part.SoftType1",
"transformOption": "newPart",
"structureOption":"2",
"forceNewDownstreamCreation":"true",
"targetType": "wt.part.SoftType1"
}

An example using the property file is given below:

As per the example, the upstream part of type wt.part.SoftType1 will be transformed as a new downstream part under the downstream part of type wt.part.SoftType1.

doNotTransform

Specifies whether a given type should be transformed. This helps when you want to skip parts of some types from transformation but process the child parts. Default value is false, that is always transform the type or its subtypes if configured.

An example using the rules file is given below:

{
"sourceType": "org.rnd.PartSubType3",
"doNotTransform": "true"
},

An example using the property file is given below:

As per the example, the part of type PartSubType3 is not transformed.

continueNavigationForReusedChildren

Specifies whether you want to continue navigating the structure if, as part of transformation, the children were reused and carried forward as is to the downstream branch. It is useful when you transform parent using the addSame action, but in the structure, you use the newBranch or newPart action for a node. It may impact the performance.

Default value is false.

An example using the rules file is given below:

{
"sourceType": "wt.part.WTPart",
"transformOption": "addSame",
"continueNavigationForReusedChildren":"true",
"targetType": "wt.part.WTPart"
}

An example using the property file is given below:

As per the example, the part structure should be navigated even if the child parts were carried forward as is to the downstream.

useProcessPlanLogicEnabled

Specifies that if a downstream structure does not exist, search for a process-plan created for the part and use the downstream structure associated with the upstream node given in the process-plan.

An example using the rules file is given below:

{
"sourceType": "wt.part.SoftType1",
"useProcessPlanLogicEnabled":"true",
"targetType": "wt.part.SoftType1"
}

An example using the property file is given below:

As per the example, the child parts consumed by the operations of the process plan that is associated with the upstream part are added to the downstream structure. The custom attribute values defined for these child parts are used to create the parent parts.

For more information, see Use Case 10: Generate a Downstream Structure by Considering Process Plan Allocation.

doNotTraverse

Specifies whether the node for a given type should be traversed further for processing its children for transformation. This helps when you want to stop traversing at a given node, and skip its children. Default value is false, that is always traverse the type or its subtypes.

An example using the rules file is given below:

{
"sourceType": "org.rnd.PartSubType4",
"doNotTraverse": "true"
},

An example using the property file is given below:

As per the example, the node of type PartSubType4 is not transformed.

attributeMapping.rule

Used for generating downstream structure. You can specify multiple rules and use internal names and values of attributes to map upstream child attribute with the downstream parent attribute.

attributeMapping.rule<integer>=up_attribute_internal_name:value:down_attribute_internal_name:value

For this property, targetType is mandatory. Also, if there is a need to generate the structure based on matching attribute values, provide the attribute name separated by colon:

attributeMapping.rule<integer>=up_attribute_internal_name:down_attribute_internal_name

For example:

• attributeMapping.rule1=lineNumber_value:10:lineNumber_value:40

• attributeMapping.rule2=source:make:source:buy

• attributeMapping.rule3=matchingAttr:matchingAttr

You can also provide a range for matching the attribute values. Only source type will respect the range.

For example:

• attributeMapping.rule1=lineNumber_value:10>90:lineNumber_value:40, skipAttribute.lineNumber_value=20

• attributeMapping.rule3=matchingAttr:A10>A90:matchingAttr:B10

newAttributeMapping (property file)

newAttributeMappings (rules file)

It is recommended to use newAttributeMapping instead of attributeMapping.rule.

Used for mapping upstream child attribute with the downstream parent attribute. You can define multiple rules using the internal name and values of attributes to filter as per the required criteria. targetType is mandatory for this element.

The syntax for source attribute is:

source.attributeLocation.attributeInternalName:attributeValue

The valid location values for source attribute are part, usage, and occurrence. You can perform single or multiple attribute mapping.

The syntax for target attribute is:

target.attributeLocation.attributeInternalName:attributeValue

The valid location value for target attribute is part location.

An example using the rules file is given below:

"newAttributeMappings": [
[
"source.occurrence.OccIBA:occv1",
"target.part.PartAttribute:Value1"
],
]

An example using the property file is given below:

As per the example, the occurrences of a part that has the OccIBA value as occv1 are added under the part that has the PartAttribute value as Value1.

It is recommended to use newAttributeMapping instead of attributeMapping.rule.

skipAttribute.<internal_name> (property file)

skipAttributes (rules file)

Specifies the name of the attribute defined for a type to skip that type from transformation. It supports multiple skip attributes.

An example using the rules file is given below:

"skipAttributes":
[
"Attribute1:String1",
"Attribute2":"String2"
]

An example using the property file is given below:

As per the example, if an upstream part has Attribute1set asString1and Attribute2set asString2, that part should be skipped and not added to the downstream structure.

You can also provide a range. For example:

skipAttribute.lineNumber_value=20>90, skipAttribute.lineNumber_value=20

Additionally, you can use the doAndValidationForAttr element along with skipAttribute.

Examples of configuring the property with the above keys are given below:

• <Property name="com.ptc.windchill.associativity.reconciliation.addusage.org.rnd.CustomPart" multivalued="," default=""/>

• <AddToProperty name="com.ptc.windchill.associativity.reconciliation.addusage.org.rnd.CustomPart" value="transformOption=newBranch"/>

• <AddToProperty name="com.ptc.windchill.associativity.reconciliation.addusage.org.rnd.CustomPart" value="structureOption=0"/>

• <AddToProperty name="com.ptc.windchill.associativity.reconciliation.addusage.org.rnd.CustomPart" value="targetType=wt.part.WTPart"/>

• <AddToProperty name="com.ptc.windchill.associativity.reconciliation.addusage.org.rnd.CustomPart" value="targetAttribute.phantom=true"/>

È stato utile?