You can also access this tutorial in German and French.


This is the last of the tutorials on flexibility in YAWL. At the centre here are exlets and their definition in the YAWL editor. The zip file below contains the necessary files for start and end of the tutorial.


Hello and welcome to another tutorial on flexibility in YAWL. We will now talk about exlets. You may be familiar with exception handling concepts in programming languages for example in Java: catch and throw etc. In YAWL, exlets are the mechanism that in combination with worklets does the handling of exceptions. We will continue on an example of tutorial 17 where we didn't properly react if the manager rejected the request. What we want to do is, we want to inform the requester about the rejection and then terminate the case prematurely. So what will we have to do in YAWL, we will first have to define a worklet that informs the requester then we will define a post constraint rule to invoke an exlet. And we will write an exlet that first suspends the case, then does the compensating action of invoking the worklet, and then terminates the case. So what do we have to do? We have to define a worklet that is used as a compensating action to inform the requester of the fact that the request has been rejected. And then we have to stop the case right there. So let's first start with the definition of the worklet. A worklet is a normal YAWL specification. So I have opened the YAWL editor here with an empty specification. And the first thing I will do is I will copy the data type definitions of the parent specification into the specification in order to be able to use the same complex types that we have defined. So I open the data type definitions here and I just copy paste these definitions in here. And you can extract this from the parent specification in the supplementary material.

Then the next thing is: I want to inform the requester, in form about rejection, and now I have to define the variables. And what I need is the purchase request and also the fact that it has not been approved. And I will define two variables here: on the net level first. So I go to data variables here and I will define the variable purchase request of type purchase requisition type. And this doesn't have scope local but it has scope input/output now. And also I will define a variable approved, a boolean variable; and again the scope input/output. Then I can pass on these variables here to our task and I will pass them on as input variables because they are just there for information. So they don't need to be edited.

And then I will save this as a specification and I will use this. I will call this one inform worklet. I also should offer this to a requester. So where's my resourcing? Okay! Next thing is: I need to upload it to the YAWL engine as a worklet. So this is this button here: workflow ... worklet successfully added. Next thing is that I will close this and now I will go to the parent specification.

And I will just go to the sub workflow order here and I will go to approve purchase. And now define a rule and the rule I will define is a work item post-constraint violation for approve purchase  and the approved ... the value of approved must be false. And if this value is false, we will do an action and we will invoke the editor here. So the first step is to suspend the work item here. The next step is to do a compensating action and now I'm asked which of the worklets I want to use. And this one is the inform worklet.

And then I don't want to continue the case but I just want to stop the case. And last but not least, I need to connect all of these. Then there is an alignment button here. And then this is done. So we have defined an exlet now. Oh, there is still a problem: invalid action for item post constraint exception. Maybe we have to suspend the case here. Target case is left in the suspended state. Now it's okay. So we have to find the right combination of suspension and removing things. Align okay and then add and close. So now the rule is successfully added and we have this exlet and now we have to see if this is working as we expect.

So this is our main workflow. So what we can do is just launch a new case: case id 6. And then see what happens. Okay, so the first one is "Prepare purchase request" and this is assigned to two Robbie Rays. So this is the first one. So we will log in with this user. Completed! Next we have "Approve purchase". This is assigned to our user mam and we accept and start it. And now we want to see what happens if we don't approve. And now we can see that "Prepare purchase order" is suspended and "Inform about rejection" is a work item that is assigned to Robbie Rays. So we can see that this has not been approved here. We complete this. Now we look at our worklist. It's empty and the case list is empty as well.

So everything is working as expected. You may have wondered, when we inform the requester about the rejection, how we have identified the right user that originally did the request? Well, the answer is we didn't. The problem is that retain familiar, the retain familiar pattern that is inbuilt in YAWL can only be used within one specification. And because the worklet that informs the requester is a different specification, we cannot use this here. The solution to this is to store the completer of the task in a variable, then pass this variable as a parameter to the worklet, and then in the worklet, assign this to the value of this variable. This can be done in YAWL but it requires using codelets. And we will cover codelets in a later tutorial. This concludes our tutorials on flexibility in YAWL. Thank you for watching! (12.63 KB)