Customizing Logic for Structure Compare

Erweiterte Anpassung > Business Logic Customization > Customizing Business Logic > Customizing Logic for Structure Compare

For a general overview of comparing structures, see Comparing Structures

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:

Example

This is an example for how to convert a custom matcher.

public class CustomDSBGraphProcessorDelegate extends DSBAbstractMatcher {
@Override
public int matchEdges(DSBEdge sourceEdge, DSBEdge targetEdge) {
// Custom matching logic
}
@Override
public List<Attribute> initRequiredEdgeAttributes() {
// Edge attributes required for matching
}
@Override
public List<Attribute> initRequiredNodeAttributes() {
// Node attributes required for matching
}
}

To use your own delegate, you can specify the following in service.properties:

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.

War dies hilfreich?