Procedure — Adding Automatic Refresh

A customized workflow process template used by promotion requests can be modified to support automatic refresh. The following example will outline to procedure used in the latest iteration of the “Promotion Request Approval Process” provided out-of-the-box.

In this example a rework loop has been added. The loop begins at the Approve Promotion Request task. Members of the Promotion Approvers receive this task. An addition route has been added to the Approve Promotion Request task called Rework.

In this example, a tally expression is defined that determines, based on all the approvers’ votes, which route to take.

Vector v = new Vector();
v.addElement("Approve");
v.addElement("Reject");
v.addElement("Rework");
Vector vResult = wt.workflow.work.WfTally.any(self, v);
if( vResult.contains("Rework")) {
result = "Rework";
} else if ( vResult.contains("Reject") ) {
result = "Reject";
}else {
vResult = WfTally.all(self,v);
if( !vResult.isEmpty() ) {
result = (String)vResult.get(0);
}
}

This expression says if any approvers choose Rework then the Rework option is taken. If no approvers select rework but any select Reject then Reject is taken. Otherwise the Approve route is taken.

The approver task no longer contains special instructions. However, there exists a process variable called special_instructions. This field is global to the process and therefore can be set programmatically. The enhanced workflow uses the Comment field of the Approve Promotion Request task to assemble a string of comments that approvers voted Rework. This String is set on the Rework special instructions. For example, if there are three users in the approvers role: user1, user2 and user3.

In this case, the reworker will receive a task with the special instructions:

Once the Rework route is chosen the promotion targets are locked for rework and the promotion creator will receive the Rework Promotion Request task. This task will provide special instructions supplied by the approver of what promotion items need rework. This special instructions field is writable for the Approve task and read only for the Rework task. The creator can then iterate certain promotable objects for this task. The creator could determine that the promotion in not longer viable and can choose the reject option. In this case the promotion request is rejected.

The user performing the rework can only update objects that they have permission to modify. If the content of the promotion request is not able to be modified, major reworking of the promotion request will require a rejection followed by a new promotion request with the reworked items. The rework loop is meant to address minor issues such as typographical errors, issues with quantity or units, minor geometry changes rather than significant structural changes.

Once the promotion creator chooses the ‘Submit’ option the promotion request will execute the Refresh Promotion Objects expression.

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
catch( Exception wte )
}
{
wte.printStackTrace();
}

The PromotionNoticeWorkflowHelper.refresh(pn) method will refresh the promotion objects to their latest iteration following the preference rules defined in Solution. Finally the loop is finished and the approvers again receive the Approve Promotion Request task. It is important to include the call to lockTargets() to ensure the promotion targets are not inadvertently modified before approval if locking is supported.

The following fit table describes how the Latest iteration Refresh preference affects automatic refresh.

Promotable	Is Promotion Target	Latest iteration refresh preference value	Eligible to be Refreshed
part_1	N/A	Do Nothing	false
part_2	Y	Refresh promotion candidates	true
part_3	Y	All	true
part_4	N	Refresh promotion candidates	false
part_5	Y	All	true