You can also access this tutorial in German and French.


This video is about flexibility in workflows and more specifically the definition and loading of worklets in YAWL. We also show how parameters are passed to worklets. The attached zip file contains the workflows and worklets needed for the running example.


Welcome to another YAWL tutorial! Today we will talk about worklets in more detail. At the basis, worklets are just ordinary YAWL workflow specifications. But they are not loaded into the engine in the same way using the control center. Instead, worklets are uploaded using the YAWL editor and then they are stored in the YAWL database somewhere. And we will see how this is done in this video. When worklets are invoked using ripple down rules as we have seen before by worklet selection or in combination with exlets as compensating actions, they receive their parameters from the parent specification by identical names and they also return the return parameters in the same way. Worklets can be loaded into the YAWL engine either one by one or in a batch using rule sets. So how can we define a worklet? As already said, worklets are ordinary YAWL specifications. Let's take a look at our supplementary material. We have two folders here: one is the parents folder and we have the organise concert YAWL workflow specification that we have looked at in the last tutorial. And also we have a folder with worklets. And here we can see several YAWL specifications: one of them is change to mid venue this is just one of them and I will open this in the YAWL editor by dragging and dropping it here. And in the last video, we have already seen that "Cancel stadium", "Book ANZ center", and "Tell punters" has been executed. So we don't need to do the walkthrough again.

So you just define this as an ordinary workflow with the YAWL editor. Let's look at the data variables though. The data variables, the net variables, are here. And we can see that venue cost, seating, and venue name our input/output parameters. And these parameters are used in combination with the parent specification. To pass parameters from the parent specification to our worklet and back. So just looking at the parent specification or "Organize concert" we look at "Do show" and look at what kind of parameters we have here. And we can see that we have venue, tickets sold, and seating. So these are the parameters and if they have the same name as the worklet in the work that they are passed through. How to upload this as a worklet? So this button here is for uploading YAWL specifications as ordinary workflows. This is not what we want to do. Instead we just use this button here: store the current specification as a worklet. And then this worklet is successfully added.

This is one thing and we can if we want to upload each of these worklets one by one. The second thing is that we have defined the rules to finally invoke this worklet in the parent specification. And we are able to store this information in a file which is an xrs file. We can look at this rules folder here. And we can see organize concert xrs and if we open this, we can see that this is an XML file containing essentially all of the rules that we have defined. So normally you don't need to look at this but it's a relatively simple XML file if you're interested. And what we can do instead of uploading each worklet one by one. We can put all of the worklets into one folder, put a rules file there and then upload the whole thing as a batch. And this is done here using this symbol: upload worklets and or rule sets from file. And if we click this, it will ask us where the rules file is located. And then upload everything in one batch. For me worklets are one of the most useful features in YAWL. In the next video, we will talk about exlets. See you later!