Change Management Cardinality

進階自訂 > Business Logic Customization > Customizing Change Management > Change Management Cardinality

You can modify the cardinality or workflow closure rules for change requests from change orders or change issues from change requests.

Background

The cardinality of the AddressedBy link and the FormalizedBy link is driven by a delegate infrastructure. The default implementation for out-of-the-box change object types provided in Windchill 10.0 M20 or later is a delegate supporting 1-N, N-1, or N-M cardinality. The later is only applicable if the change object cardinality preferences are enabled. A new delegate is also available to support 1-1 cardinality.

Scope/Applicability/Assumptions

• Assumes you have general knowledge about Java classes and concepts such as class extension

• Assumes you have general knowledge about the xconf mechanism to create properties.

Intended Outcome

After reading this, you should know how to create custom cardinality rules for change requests and change orders, or change requests and change issues.

Solution

Solution: Create a custom class that extends a default delegate, and create an xconf entry to register your custom delegate.

Prerequisite knowledge

To apply this best practice, you need to have an understanding of the following:

• Java class extension

• Xconfmanager

Solution Elements

Element	Type	Description
wt.change2.ChangeCardinalityDelegate	Interface	Generalizable Interface for cardinality rules
wt.change2.DefaultAddressedByDelegate	Link class	Supports 1-1 ChangeRequest2 to ChangeOrder2 cardinality
wt.change2.DefaultFormalizedByDelegate	Link class	Supports 1-1 ChangeRequest2 to ChangeIssue2 cardinality
wt.change2.AddressedByDelegate	Link class	Supports 1-N, N-1 or N-M (preference driven) WTChangeRequest2 to ChangeOrder2 cardinality
wt.change2.FormalizedByDelegate	Link class	Supports 1-N, N-1 or N-M (preference driven) WTChangeRequest2 to ChangeIssue2 cardinality
ChangeMgmt-service.properties.xconf	Default change service properties	Property file which registers the above cardinality rules out-of-the-box.

Customization Points

1. If you want to customize the cardinality for the AddressedBy2 link, then you should create a new java class (your delegate) which extends the DefaultAddressedByDelegate or the AddressedByDelegate (depending on which existing functionality closest matches the behavior desired)

public class YourCustomAddresssedByDelegate
extends DefaultAddressedByDelegate
{
/**
* Determines if the change request is 'properly addressed'.
Default implementation of
* addressed by means that one change request can be addressed
* by only one change notice and vice-versa.
* @param ChangeIssue
* @param ChangeRequest2
* @return void
* @throws WTException - If the cardinality is
* invalid, a ChangeException2
* should be thrown along with the reason why the
* cardinality is not valid.
*/
@Override
public void validateCardinalityConstraints(ChangeRequest2 cr,
ChangeOrder2 co) {
//YOUR RULES IMPLEMENTED HERE
}
/**
* Overriding this method will handle the closure of the ChangeRequest2
* object based on a delegate implementation.
* Ultimately, the closure of the ChangeRequest2 will require the closure of all
* associated ChangeOrder2 objects
* which are registered against the same delegate.
*
* @param changeObjects
* @param changeObjects
* @return
*/
@Override
public boolean isReadyForResolution(ChangeRequest2 cr,
Set<ChangeOrder2> objs) {
//YOUR RULES IMPLEMENTED HERE
return true; // if the change request is ready
}
}

2. If you want to customize the cardinality for the FormalizedBy link, then you should create a new java class (your delegate) which extends the DefaultFormalizedByDelegate or the FormalizedByDelegate (depending on which existing functionality closest matches the behavior desired)

public class YourCustomFormalizedByDelegate extends
DefaultFormalizedByDelegate
{
/**
* Determines if the change request is 'properly addressed'.
Default implementation of
* addressed by means that one change request can be addressed
* by only one change notice and vice-versa.
* @param ChangeIssue
* @param ChangeRequest2
* @return void
* @throws WTException- If the cardinality is invalid, a
* ChangeException2 should be thrown along with the
* reason why the cardinality is not valid.
*/ @Override
public void validateCardinalityConstraints(ChangeRequest2 cr,
ChangeOrder2 co) {
//YOUR RULES IMPLEMENTED HERE
}
/**
* Overriding this method will handle the closure of the ChangeRequest2
* object based on a delegate implementation.
* Ultimately, the closure of the ChangeRequest2 will require the closure of all
* associated ChangeOrder2 objects
* which are registered against the same delegate.
*
* @param changeObjects
* @return
*/
@Override
public boolean isReadyForResolution(ChangeIssue ci,
Set<ChangeRequest2> set) {
//YOUR RULES IMPLEMENTED HERE
}
}

When defining this xconf configuration, it is important that the requestor (in this case the ext.change2.YourChangeRequest2) is not an abstract type, this is because the framework performs the lookup based on a concrete class name (and it does not support hierarchical lookup of types). The selector class, however, can be an abstract type. If you do not register your delegate, then the default Windchill implementation would be used instead of your delegate. This default implementation supports 1-N, N-1, N-N (if the change object cardinality preference is enabled).

Modifying the cardinality of out of the box Windchill types:

For example, if you wanted to apply 1-1 cardinality between the WTVariance and the WTChangeRequest2, you would have add the following properties to xconf configuration:

這是否有幫助?