Advanced Customization > Business Logic Customization > Customizing Workflow Administration > Customizing Promotion Request Workflow Processes > Key Customization Points > Lock/Unlock Promotion Targets
  
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
}
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";
}
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.