Solution

The class DiscrepancyType represents the type of discrepancy. This class is marked as supported and contains out of the box discrepancies.

This is a standard Windchill enumeration with its own rbInfo file DiscrepancyTypeRB.rbInfo, which can be customized using out of the box enumCustomize tool.

All the enumerations marked as selectable are shown in the BOM Transformer interface in MPMLink. You can use the enumCustomize tool to update the existing list of discrepancy types and add or remove the types.

Discrepancy2 is the base interface to define actual discrepancy value object. It is marked as supported. However, it is recommended to extend the abstract supported class AbstractDiscrepancy2. This abstract class provides the default implementation for the methods used in the interface.

◦ All the implementations of Discrepancy2 or AbstractDiscrepancy2 are expected to be value objects and should not contain business logic. The implementations are designed to hold data related to discrepancy.

◦ Actual logic to detect and resolve the discrepancy is provided in the discrepancy delegate discussed in the next point.

◦ This model allows for clear separation between data and business logic. You can define one discrepancy and multiple delegates or vice versa based on your requirements.

Discrepancy Delegate is the base interface to define a delegate for a given discrepancy type. It is marked as supported. It is recommended to extend the abstract supported class AbstractDiscrepancyDelegate for any customization requirements. This abstract class provides the default implementation for the methods used in the interface.

◦ The main purpose of delegates is to provide separation of data and logic. Delegates should be responsible for the logic. Also, this allows one delegate to be used for multiple discrepancy types based on the complexity and reusability of logic.

◦ There are two parts to the delegates. The first part is the ability to convert a given discrepancy to a JSON format and to consume a JSON and return a discrepancy. This is needed for user interface purpose when you want to report and then resolve selected discrepancies. But if it is only for the server side, these APIs can be skipped. The second part to delegates is to implement the logic to detect, verify, and resolve the discrepancies.

codebase\com\ptc\windchill\associativity\xconfs\associativity.service.properties.xconf
<Service context="default" name="com.ptc.windchill.associativity.reconciliation.DiscrepancyDelegate">
......<Option cardinality="singleton" selector="QUANTITY" requestor="null"
......serviceClass="com.ptc.windchill.associativity.reconciliation.part.QuantityDiscrepancyDelegate"/>
......<Option cardinality="singleton" selector="REMOVED_USAGE" requestor="null"
serviceClass="com.ptc.windchill.associativity.reconciliation.part.RemovedUsageDiscrepancyDelegate"/>

</Service>

This is the main input for the reconciliation service. The responsible class is ReconciliationContext. You can provide any custom input using the addAdditionalParam method.

This map can be populated with a key or value which can be read in most of the customization hooks across the flow of service as well as in DiscrepancyDelegate. This allows for customization which can be driven based on different inputs; for example, when performing different tasks differently for client or server usage. Also, this allows the service or customization to cache performance intensive information which can be reused across different delegates.

The class CriteriaType represents the criteria to compare the current iteration of the upstream structure with the previous iteration. This class is marked as supported and contains out of the box criteria types.

This is a standard Windchill enumeration with its own rbInfo file CriteriaTypeRB.rbInfo which can be customized using the out of the box enumCustomize tool.

AbstractCriteria is the base class used to find the previous item to be compared with the current item for detecting discrepancies. The service uses the previous item to build the previous path or structure information to detect structure discrepancies.

TimeBasedCriteria, OutOfDateCriteria, and BaselineCriteria are provided out of the box. These criteria can be injected to the service using the ReconciliationContext input. If not provided, service reads the default criteria from the configuration.

The interface can be customized. It accepts a collection of items and returns a map of current versus previous item. It expects the result to have an entry for each input. Therefore, if no previous items are found, it is expected to add the same item as the value in the result. The interface is given below:

public abstract Map<Associative, Associative> getCurrentToOldAssociative(ReconciliationContext context, Collection<Associative> associatives) throws WTException;

Following is the configuration for the default criteria given in the file:codebase\com\ptc\windchill\associativity\xconfs\associativity.service.properties.xconf.

The main service interface to interact with the discrepancy model is ReconciliationService. The service provides APIs to detect or resolve the discrepancies based on inputs and configurations. Following are the minimum inputs required for the service:

a. Change context: The root node under which all the changes or discrepancies need to be detected. This is the common equivalence context for all the changes and not necessarily the absolute root of the structure. This helps in performance consideration. Higher the change context in the hierarchy, more the performance impact of the service. This is assumed to be upstream.

c. Change item path: The path of the change items under the given change context. The path starts from the user interface where structure information is available. This helps save performance impact. This input is optional.

d. Upstream navigation criteria: The navigation criteria to traverse upstream structure. This can be optional, but should be provided. If it is not provided, the service receives the default navigation criteria for the change context. This may cause issues if default navigation criteria is not configured properly.

e. Downstream navigation criteria: The navigation criteria to traverse downstream structure. This can be optional, but should be provided. If not provided, the service receives the default navigation criteria for the downstream change context. This may cause issues if default navigation criteria is not configured properly.

f. Downstream change context: The downstream root under which the discrepancies should be verified or resolved. This is optional if you only want to detect discrepancies.

This is the base interface to define a delegate to perform pre-actions and post-actions after detecting and resolving a discrepancy. It also holds the logic to order discrepancies for resolve. The delegate is marked as supported.