Customizing Logic for Structure Compare
This information applies to the following applications:
• Compare to Part Structure
• Compare to Part Configuration Structure
• Compare to Part Instance Structure
In these applications, a matching process is used to determine whether two objects will line up on the same row. This matching is often done based on properties of link objects between parent and child. Utilizing properties on the parent or child are also possible.
For two parents that are matching, one on the left and one on the right, each link under the left parent is matched against each link under the right parent to find a comparison precedence. A lower precedence means a stronger match. A precedence of “0” means the links match completely, and a negative precedence means the links do not match.
A matcher is configured to match on one link object type. Therefore, it is possible to customize matching logic for different link object types.
It is important to note that the matchEdges() method is called many times during the matching process, so the method must be highly performant, otherwise serious performance degradations will occur.
Customizing matching logic is a two-step process.
1. Implement a custom matcher. For example:
public class DSBCustomMatcherWTPartUsageLink extends DSBAbstractMatcher {
@Override
public int matchEdges(DSBEdge sourceEdge, DSBEdge targetEdge) {
// Custom matching logic
...
// Example of gathering required attributes
Object sourceFindNumber = sourceEdge.getEdgeInfo()
.getAttribute(PLMEntity.FIND_NUMBER.getAttribute());
Object targetQuantityAmount = targetEdge.getEdgeInfo()
.getAttribute(PLMEntity.QUANTITY_AMOUNT.getAttribute());
Object sourceVersion = sourceEdge.getChild()
.getNodeInfo().getAttribute(PLMEntity.VERSION.getAttribute());
...
}
@Override
public List<Attribute> initRequiredEdgeAttributes() {
// Edge attributes required for matching
// If no attributes are required for matching, return null
return Arrays.asList(new Attribute[]{
PLMEntity.FIND_NUMBER,
PLMEntity.QUANTITY_AMOUNT
});
}
@Override
public List<Attribute> initRequiredNodeAttributes() {
// Node attributes required for matching
// If no attributes are required for matching, return null
return Arrays.asList(new Attribute[]{
PLMEntity.VERSION
});
}
}
2. Add an entry in the appropriate xconf file linking the custom matcher to a link type. For example:
<Service context="default" name="com.ptc.windchill.enterprise.dsb.server
.graph.matcher.DSBAbstractMatcher">
<Option cardinality="singleton" selector="wt.part.WTPartUsageLink"
requestor="null" serviceClass="com.ptc.windchill.enterprise.dsb.server
.graph.matcher.DSBCustomMatcherWTPartUsageLink"/>
</Service>
Example
This is an example for how to convert a custom matcher.
To use your own delegate, you can specify the following in service.properties:
<Service context="default" name="com.ptc.windchill.enterprise.dsb.server
.graph.matcher.DSBAbstractMatcher">
<Option cardinality="singleton" selector="wt.part.WTPartUsageLink"
requestor="null" serviceClass="com.ptc.windchill.enterprise.dsb.server
.graph.matcher.CustomDSBGraphProcessorDelegate"/>
</Service>
Changes in Logic from Previous Releases
The process for creating custom matching logic for compare applications has changed in Windchill 10.1 M010.
There are four notable changes:
1. Custom matchers no longer implement DSBGraphProcessorDelegate and ApplicationContextChild. Custom matchers only need to extend DSBAbstractMatcher.
2. The method getRootSummaryStatusFlags() has been removed.
3. The methods initRequiredEdgeAttributes() and initRequiredNodeAttributes() have been added.
4. A matcher is now configured to match on one link object type.
