Key Customization Points
You must keep the following key points in mind when customizing these workflows.
Lock/Unlock Promotion Targets
As you notice there are two "Conditional" routers that you see in the above workflows. They handle important tasks.
One of them does the job of locking targets. The promotion targets could be parts, CAD documents, docs etc. These promotion targets could be associated with a lifecycle that has lock transitions. If so, and if there is a need to move the targets to a desired lock state before reviewing the Promotion Request, and if there is lock transition that exists with that desired lock state as the end state, then those targets have to be locked before review tasks can be fired to the promotion review team members.
The out-of-the-box conditional for locking has an expression similar to the below code snippet:
wt.maturity.PromotionNotice pn =
(wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
wt.maturity.MaturityServerHelper.service.lockTargets( pn );
result = "Accepted";
}
catch( Exception wte )
{
result = "Rejected"; // send notification to owner
}
(wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
wt.maturity.MaturityServerHelper.service.lockTargets( pn );
result = "Accepted";
}
catch( Exception wte )
{
result = "Rejected"; // send notification to owner
}
The customized workflow should also have a similar locking mechanism before including the task for review.
The second conditional does the actual promotion of the targets and has code like:
wt.maturity.PromotionNotice pn =
(wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
wt.maturity.MaturityServerHelper.service.promoteTargets (pn);
result="Approved";
}
catch (wt.maturity.MaturityException me)
{
result="Rejected";
}
(wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
wt.maturity.MaturityServerHelper.service.promoteTargets (pn);
result="Approved";
}
catch (wt.maturity.MaturityException me)
{
result="Rejected";
}
The promoteTargets API also takes care of the process of unlocking the targets before promoting them. This kind of an unlocking mechanism should also be incorporated in the customized workflow.
Review Promotion Request Activity
The task that should be included in the workflow must be of the type Promotion Request Task. This special task type will be available as a drop down while defining the review activity in the workflow.
Owner Role in Promotion Request Team Template
Another important rule that must be strictly followed is to include the "Owner" role in the team template that would be used for Promotion Request. The owner role is a participant in many of the activities and robots in the PR workflow.