Using Worklets to reduce Workflow Complexity

If you want to explain the essence of a procure to pay workflow you might want to use a diagram like this one:

It shows the “sunshine path” of a process where a request is created by a requisitioner (red), the request is approved by a manager (orange), a purchase order is created by a buyer (yellow), and the goods are selected, shipped and invoiced by a supplier (blue). The requisioner receives the goods and the buyer receives the invoice. Finally, the invoice is payed by accounts payable (blue).

It may happen of course that the request is not approved, that goods are not available or that there are complaints after the reception of the goods or the invoice. If we add this behaviour to the diagram above we get something like this:

Although the control flow is depicted here in a very direct way, we lose some of the simplicity and clearness of the original approach. In this tutorial, we will show how the original diagram can be directly used for an implementation that accounts for all the special cases. This can be done by using worklets and exlets.

Developing the solution step by step

The first thing we will add now is a differentiation of the task “Approve request” according to the Max_price:

Max_price < 500No approvalApproveAutomatically
500 <= Max_price < 10.000Approval by manager
10.000 <= Max_price < 100.000Approval by senior managerApproveSenior
Max_price >= 100.000Approval by a manager and a senior manager (four-eyes principle)ApproveTwo

In order to do this we have to write and upload the worklets and then create an RDR-tree like this:

Next we want to notify the requester if the request has not been approved and then cancel the case. Since the compensating action is done in a worklet, we cannot use the retain familiar facility of the editor. We must store the userid in a variable and pass it to the worklet. This can be done with a codelet called “TaskCompleterInfo” that comes with the YAWL distrubution.

We will first create a worklet called “CreateRequestWorklet” that will always be used. It serves for hiding the technical task “Store completer of WI”.

Once we have this done we can crete a Workitem post-constraint violation rule. The actions suspend case, compensate by “NoteRejection” and cancel case are executed if the request has not been approved.

We do the same thing for tasks “Create purchase order” and “Select goods”, i. e. notify the requester in case something is not available and cancel the case.

If the goods received are not ok we want to return them and notify the supplier of this fact. For this purpose, a worklet “Return goods” is created that does this.

Furthermore, the SupplierID must be stored as well. This requires another worklet “Select goods worklet”.

Overview of the results

The next table shows an overview of all worklets and how they are linked to the specifications. The information is persisted in the files ProcureToPay.xrs and Return_goods.xrs.

SpecificationTaskRule typeWorklet
ProcureToPayCreate requestSelectionCreateRequestWorklet
 Approve requestSelectionApproveAutomatically
  WI post-constraintNoteRejection
 Create purchase orderWI post-constraintNoteRejection
 Select goodsSelectionSelect_goods_worklet
  WI post-constraintNoteRejection
 Receive goodsWI post-constraintReturn_goods
 Receive invoiceWI post-constraintNote_complaint
Return_goodsReturn goodsWI post-constraintNote_complaint


All necessary files are attached here in a zip file. In order to install everything follow these steps:

  1. Load the Organisational data from file YAWLOrgDataExport.ybkp using the control centre.
  2. Load the specification ProcureToPay.yawl using the control centre.
  3. Load all other yawl-files as worklets using the YAWL editor.
  4. Load the rule files ProcureToPay.xrs and Return_goods.xrs using the YAWL editor.

Running the workflow

The workitems of the workflow are distributed to the following users:

User-IDFirst nameLast nameRoles
man1MiroNantzManager, Requisitioner
man2MartheNoxManager, Requisitioner
smanSeanNibbleSenior Manager, Manager, Requisitioner
buyerBertaRuddingtonBuyer, Requisitioner
apAmandaProffsAccounts Payable, Requisitioner

All users have the password “pass”.