Limitations
Old and New Workflow Processes
In some cases, old workflow processes can be configured to work with new workflow processes. For example, Problem Reports or Variances that complete their workflow process after being approved can still work with a new Change Request workflow, but the Change Request workflow process will still need to call the force close on the parent associations. If the Problem Reports or Variances with a new workflow process are also associated they will not be forced to closed when the handlesClosure is set to true. The Change Request workflow process template provided in Windchill Release 11.0 is configured to support both the previous release and new Problem Report and Variance workflow processes.
Using the force closure API on existing associated change object processes that already have synchronized closure will likely cause unexpected results. For example, the Change Request workflow process already has a synchronized closure for when the Change Notice is resolved. If the Change Notice workflow process was updated to force close the parent associations, then additional sequences in the Change Request process such as locking annotations would not happen.
Required Updates to the Change Request Workflow Process
The Change Request workflow process must be updated in order for it to work with the flexible change process associations. The ChangeService2Event.CN_STATE_CHANGED is no longer supported with flexible change process associations. The event will still work for the deprecated wt.change2.AddressedBy2 associations.
Closure with Multiple Associations
Direction of closure should be considered when determining which change object types are defined as the parent (role A) and child (role B) role of the flexible change process association. Note that the owning role can be defined separately from the parent or child role. For example, given the following relationships:
• Problem Reports associate to Change Requests
• Change Request associate to Change Notices
The recommendation is to use the direction of closure when defining the association rules. Defining the association rule in the direction of closure guarantees that the Change Request waits for all associated Change Notices to close and a Problem Report waits for all associated Change Requests to close. If the Change Request is considered to be the owner role for both associations then consider defining the change process association rules with the roles defined in the direction of closure as follows:
|
Role A (Parent)
|
Role B (Child)
|
Owner Role
|
|
Problem Report
|
Change Request
|
Role B
|
|
Change Request
|
Change Notice
|
Role A
|
Additional considerations are required if the rules are not defined in the direction of closure. Consider the following changes to the rule definitions:
|
Role A (Parent)
|
Role B (Child)
|
Owner Role
|
|
|
|
|
Change Request
|
Problem Report
|
Role A
|
|
Change Request
|
Change Notice
|
Role A
|
If the general isRelatedChildrenInStates API is used in the Change Request workflow process without specifying a specific change object type it would result in the Change Request waiting for the Problem Reports to close. The Problem Report workflow process is also waiting for the Change Request to close resulting in a closure deadlock. In order to prevent closure deadlock the specific change object types should be specified when using the isRelatedChildrenInStates API. In the Change Request workflow process the Change Notice type should be specified so that the associated Problem Reports are ignored.