Tutorials fmannhardt Tue, 11/15/2011 - 14:39

A main goal of the YAWL User Group is to make knowledge about the YAWL system explicit. On the following pages we'd like to build up a collection of tutorials for both beginners and experienced users. You are invited to take part and help us, please use the forum "Tutorials and examples" for submissions or contact us directly info@yaug.org.

Video Tutorials

Video Tutorials ahense Sat, 05/09/2020 - 06:33

YAWL BPMS Tutorial 1

YAWL BPMS Tutorial 1 ahense Sat, 05/09/2020 - 06:16

This video gives a quick overview about the origins of the open-source BPMS YAWL. YAWL is based on the Workflow Patterns Initiative and an alternative standardisation approach to BPMN.

YAWL Download

Workflow Patterns

Hello and welcome to this new channel on the Business Process Management System YAWL. This channel is brought to you by Bonn-Rhein-Sieg University and the YAWL User Group. I especially thank our E-learning team and the Video Lab for helping me set up this channel. My name is Andreas Hense. Business Process Management is not an entirely new idea. Already in the 1980s, there was this idea of office automation, as it was called, and workflows and until the year 2000, many different workflow systems emerged and each of them had a different notation and a different semantics. So by the year 2000, there were two major efforts unifying everything that was on the market then. One effort was called BPMN - Business Process Model and Notation - and is essentially an industrial standard - a notational standard - that combines everything that was available at that time in workflow management systems. The second approach was an in-depth analysis of all these systems. This was called workflow patterns and based on these workflow patterns a minimal language that could express the totality of these things was created. And this language was called YAWL - Yet Another Workflow Language. So then from 2002 onwards the Technical University of Eindhoven and the Queensland University of Technology in Australia have developed YAWL into a full-fledged Business Process Management System. YAWL has a very stable engine that can run for many years without ever breaking down and so is really ready for productive use. So what is the difference between YAWL and other business process management systems? Other Business Process Management Systems have a tight integration with a software development layer and that makes them very attractive for software developers because they can find all of their tools they know. YAWL has a clear separation between the workflow specification layer and the software development layer and that makes YAWL very attractive for organizations that don't want to call software developers each time they have an improvement or a change in their requirements. Well, in this series of hands-on tutorials we want to show you how to install YAWL, how to build your first workflow, how to run your first workflow, and go on step-by-step to more complex topics. There will also be the possibility for you to ask questions. We will answer these questions and also produce videos on demand. So if you like this idea I invite you to subscribe to this channel and go to the next video on the installation of YAWL. See you then!

YAWL BPMS Tutorial 2

YAWL BPMS Tutorial 2 ahense Sat, 05/09/2020 - 06:41

In this video we show how to install YAWL 4.3 on Windows 10. YAWL can also be installed on Linux and Mac OS. The installation procedures are very similar.

OpenJDK 11

YAWL Download


Hello and welcome to this tutorial on how to install YAWL. So, YAWL can be installed on all ordinary operating systems: Windows, Mac, and Linux. And it comes with an installer. The only prerequisite that you need is a Java version. So let's just look at what is installed on our system here. So if you put up a command prompt and you say "Java - version" you can see here that I have installed open JDK 11 and, as I said, it also works with Java 8. So once you have Java installed you can now go to the YAWL website. And the YAWL website is under yawlfoundation. github.io. So open this site and press the download key. And then you have a number of files that you can download there and the first one is the Windows installer. So I will click on that one and then wait until it downloads. So double click on that and - "Windows protected your PC" - and now you can see the logo coming up and it asks us if we want to accept the license agreements. You have to accept that and then gives us some directory where to put it and then it's installing it and it asks us to select a Java run time. So I have only one installed here so I'll select that.

And then it unpacks the files and we're finished. So okay! Next step is to type "YAWL" here and we get YAWL 4. And what you can see now is the YAWL control panel. And the YAWL control panel has a starting button for starting the YAWL engine. We will do that in a moment. And it also has something to check for updates. So we'll do that first and we have some updates here: so we'll click that. It's verifying everything and then it's starting the YAWL engine. And we allow access. "Update completed successfully" - and we can have a look at the log and we can see that the YAWL engine has started. And so the next thing to check if everything works is to go on the YAWL logon page and it opens up YAWL in the browser and as you can see, YAWL is here on localhost port 8080. That's the Tomcat server that YAWL runs on and we can log in here with the username admin and password is YAWL all capital letters: 'Y' 'A' 'W' 'L'. And that's it now! YAWL is installed successfully on our machine. Okay, we are done!

YAWL BPMS Tutorial 3

YAWL BPMS Tutorial 3 ahense Sat, 05/09/2020 - 06:49
This video shows the basic resources that you can reach from the YAWL control panel and some others.

YAWL User Manual

YAWL Examples


YAWL User Group


Hi, and welcome back to the YAWL tutorials! In the last tutorial, we have seen how to install YAWL. In this tutorial, I will show you parts of the YAWL environment and also some resources that you can look up to know more about YAWL. So let's first start at the control panel where we ended in the last video. So, how do we get there? We have YAWL installed. So we go to our screen now and just type in "yawl" and then the control panel opens and we start the YAWL engine and look at the output that is coming on the screen. And once the YAWL engine is started, we get a green symbol over here.

Okay, now the engine is running and we go through the elements that you can reach from the control panel step-by-step. So the first one is the button to stop the YAWL engine and the next one is the YAWL log-on page or what is also called the YAWL control center. So if we click that one, we get a browser opening here on localhost 8080 - remember this is the Tomcat server - and we just login with "admin" and password "YAWL" with capital letters - all capital letters. This is the standard password. And then we get to this screen here and we can have a look at our cases. Currently there are no cases here because we didn't start anything yet. We can administer users, organizational data, and many other things. So we will cover that in a later video in more detail. So, now let's go back. The next component here is the YAWL process editor. So if we click on that on this pencil symbol, we get a message that a new build of the YAWL editor is available. So be prepared that the YAWL engine is updating via the control panel - as we have already done in the last video - and the editor has its own updater here and we would just do update and restart and so we will get the latest version of the YAWL editor. So: "updated successfully". And now here we have the possibility to edit workflows, so we can start a new workflow and then we can insert our tasks, connect them, and so on and so forth. So we'll come back to that in the next video. So I don't want to save the changes. Just close this. The next component is the updater checker. So we looked at that already. So in regular intervals you can check that or if it starts it will check automatically if there are updates available. Then we have a preferences settings symbol here and we can edit many things here and the next thing, the information icon, if we click that one, this will open the most recent version of the YAWL User Manual for us and this is one of the most important documents when you start to work with YAWL. So basically everything you need to know about operating the YAWL system and the YAWL
editor is in the user manual. So this is a document containing - yeah - nearly 300 pages now. Then the next symbol here is a link to a page where we can have some example files, example workflow specifications and  - also this is quite interesting - and sometimes the user manual refers to these workflows. So if you are looking for example workflows, this is the place to go.

And then we have the question mark here and this is just telling us which kind of version of the control panel we have here. So these are the things we can reach directly from the YAWL control panel. So as resources what else do we have? There is the YAWL book called "Modern Business Process Automation" and there is a reference to this book here in the YAWL Foundation page that we have already seen and I'll put a link to that below so you can you can have a look. Then we have the YAWL page itself which we have already seen the last time. This is where you can get the YAWL installation from. And we have the YAWL User Group page and so this is an overview of all the resources that you can directly get about YAWL. There are many other things available, but if you start with these ones I think you will have a good start. So meet me again in the next video on our first workflow
So we will start editing workflows. See you later!


YAWL BPMS Tutorial 4

YAWL BPMS Tutorial 4 ahense Sat, 05/09/2020 - 07:03

This is the first video explaining the YAWL editor.

Hello and welcome back to the YAWL tutorial series! So in the last video, we have talked about the YAWL environment and the resources that you can look up for reading about YAWL and in this video, we will start with the YAWL editor and we will start editing the control flow. The goal of this video and the next two or three videos will be to get you to a running workflow as quickly as possible. So we will only cover the basics here and do the more detailed things in future videos. So let's start with a minimum of theory! On this slide, you can see the three workflow perspectives: namely the control flow, the data, and the resources.

These three perspectives come from the analysis of workflow patterns and the control flow is what makes a workflow going. So it's a sequence of steps. Sometimes it splits up in parallel or in different other splits and then it comes together again. And this control flow from the beginning to the end of our process is depicted graphically in YAWL with the YAWL notation. And you can see an example of that - a part of that - on the top of this slide. The next thing is, if you want to automate a business process and not only talk about it, you also need to say what kind of data you are dealing with and this is the second perspective in workflows. So the data perspective as we can see it on this slide consists of a declaration of variables and their data type for each of the tasks involved in our workflow specification.

And the last perspective is the resource perspective. This is about who is going to execute the task at runtime and this is a complex organizational model in the background and we are able to edit that in the editor as well. And the YAWL system then, with these three perspectives control flow, data, and resources is able to create a web application. And the web application combines all of these three things and is executable on our YAWL server. And so you can find here on the right hand side an example of a web form that is generated by YAWL, where you can see the names of the data fields and their types and - so for example - if you have a date type you can have a date picker and if you have a boolean type you have a check mark and so on and that is how YAWL is working and that's how you can do prototypes very quickly and deploy them on the YAWL server. So let's now go and see how this translates into our example and how we can do that using the YAWL editor. So I have opened up for you the YAWL control panel again. If you want to see how to start it, look at one of the previous videos. And we have already seen that there is this pencil symbol here and if we click that the YAWL editor opens and we get a blank page where we can start editing our workflow. One thing is important before we start. The YAWL editor needs a connection to a running YAWL engine and the running resource service. And we can look that up on the bottom of this page here. We have two little green check marks. If they are green everything is okay and if we click on them we can see that currently our YAWL editor is connected to a YAWL engine residing at localhost with port 8080 - that is the standard configuration - and the resource service is also at localhost with the port 8080 and we are using certain credentials to connect to this and we are able to test the connections. So now let's start our workflow. So to do that we have to go on the icon here on the top and it says "create new specification". So if we click that, we get a starting condition and an end condition and now we can change the palette here to ordinary tasks. That's what what we will start with and if we have changed this to atomic tasks we can now start editing our example workflow. And let's say we want to prepare a workflow for an application for leave and so we will start with "Submit leave request" as our first task. So we click here somewhere on the canvas and if we select this atomic task we have at the bottom here a decomposition and we will create a new decomposition and we will name it "Submit leave request".

So we have created this name here with blanks inside and if we say "okay", the system tells us that in order to create a valid XML identifier it will replace the blanks by underscores, which is fine.

And then we have the "Submit leave request" here. I will just zoom in a little more. So we have the possibility here at the top to zoom in and out and so that you can see more what we are doing. I will just zoom it in a little. So we have "Submit leave request" as our first task here. While we are in the atomic task in the palette - so that's always something you need to watch out for - we can connect the input condition to our first task like this by clicking the left mouse button and dragging it to the first task. The next task will be "Approve leave request". So again we click somewhere here, connect it and select this second task and go to the decomposition on the left hand side and say "new". We will call that "Approve leave request".

Then, after this approval, let's say we have two different outcomes of this: one is that the approval is given, so in that case we have a task called "Note approval" and if that's not the case, we have another task called "Note rejection". And we want to  ... now the control flow to split here. And in order to do that, we select this task and select a split type and in this case this is an XOR split - an exclusive or - so we will choose that here and the exclusive or symbol appears here. And now we connect to these two different outcomes and then we just connect this to the end to make it simple.

Okay, so now our control flow is complete and we can just make it look a little more beautiful. So, how to do that? There are if we ... in the palette we go to the right-most point here, we can select element. Let's first drag and drop around all of the elements and then move them somewhere to the top. And we click and then we select the elements here in the middle and now we align them to the top edges.

And what we also can do is, we can just select an element and put press left arrow until it is at the right position and then we can select these two elements here and align them to the left. And then we take the whole part. Do it like that and now our control flow is ready and it looks more or less clean. So now let's save our specification. So we have on the left hand side here different things so we have a description here.

So I click the three little dots here and I just say "Example application for leave" and we give the specification a name, so this will also be the file name for it "ApplForLeave" and a title. Se can call this "Application for leave". Note that we also have a version number here. So this is version 0.1, and before we save it what we can do we have a green check mark on the top here for validating the specification and if we click that, we see on the bottom "no problems reported", which is good. So now we can save this. So we press this "Save this specification" button and now it will create a name "ApplicationForLeave.yawl". So all these specifications are saved as .yawl files and we just save it somewhere in our directory.

Okay, that's all for now. So in the next video we will continue editing this workflow and will also insert some data. See you then!

YAWL BPMS Tutorial 5

YAWL BPMS Tutorial 5 ahense Sat, 05/09/2020 - 12:39

In this tutorial we continue working on our specification with the YAWL Editor. We enter the data that the participants will work with during process execution.


Hello, welcome back to the YAWL tutorials! You remember that we had three perspectives in workflows: namely the control flow, the data, and the resources. In the last video, we talked about editing the control flow and we did that with the YAWL editor and in this video, we'll talk about data - entering information about data - for every task in our control flow. And the next video will then be on the resources. So let's start where we left off in the last tutorial. If you don't have the specification of the last tutorial, you can go back to that tutorial and find it in the supplementary material. You will find a .yawl file in there that you can then load if you want to start from there. I have already opened up the YAWL editor now. Remember that you need a running YAWL engine and the resource service and that the YAWL editor must be connected to it. So let's go and look at the specification we did the last time. So we had four tasks here: one is "Submit leave request", then "Approve leave request", "Note approval", and "Note rejection". So we'll start off by telling the editor, what are the data we are going to use with "Submit leave request"?

So for that, we click on this task symbol here and then on the left hand side you can see that the editor has opened several sub panels here from the properties of the specification to the net, the task, and - last but not least - the decomposition. And this is a some kind of hierarchy. So in order to enter the data necessary for this task, what we can do is, we can directly go to the decomposition now and we find one line here about data variables. So if we click on that, there's a window opening now and we can enter net variables in the upper half and decomposition variables in the lower half. We can think of the net variables of being global variables in this net and decomposition variables being local to the decomposition we are currently editing; and the decomposition we are editing is called "Submit leave request". So it belongs to that task. So what kind of data do we need here? Let's say, we want to have the first name and the last name of the applicant. So we go here on the plus sign and we say the name of the variable. So I will call it "First_name" and you cannot see it here, but note that I did an underscore here, because these are XML elements and we will cover in a later video how you can edit variables containing blanks, variable names or labels containing blanks. But for the time being, let's just use underscore here. So First_name is the name of the variable and then the second column here is the type. So string is the default type and that's fine for this variable. We have a name and then the scope is local within this net. That's fine as well. The next variable we need is the last name, so I type in "Last_name" and we want to have a start and an end date. So I will add another variable "Start_date" and this time, I will choose the data type date. So I type in a "d" here and then I choose this date type and the same for end date.

And the last variable here is the destination. Oh, let's put in another one for the reason. So these are the variables we will use in this specification and we will use it in this decomposition. So in order to use them in the decomposition, we have to define something that is called a mapping of the variables from the net to the decomposition and this can be done manually but for the time being we will do that completely automatically by the editor. So what we do is just, we select the first variable and then we drag it into the decomposition and then we do this with all the other variables. So "Last_name", "Start_date", "End_date", "Destination", and "Reason".

So now we have to think about the scope of the variables in the decomposition and in the net these variables were local variables but in the decomposition we have three different choices for variable scopes. One is input/output. This is the default selection meaning that the variable has already a value in the net. We read its value, we edit it in the net and then we output it back to another net variable. The second scope is input only. Input only means that it has already a value in the net, it is input into the decomposition and then it is read only. We cannot change its value. And then we have the third option is output. So this means, we don't have a value yet and we are just going to create a value here in the decomposition and then this will be output to the net. And it is this third option we will use here for our first task because all of the variables are uninitialized for the moment. So I will choose output here and I'll do the same for all the other variables.

And then I can click "apply" and "okay". So we are done for the first task and the second task "Approve leave". So we are going to imagine that now someone maybe the superior of the applicant is now approving or rejecting the application for leave and we need all of the variables that we have seen in the last task as input variables now. So let's do that! So we open again the data for this decomposition and then we just drag and drop all of the variables here: "First_name", "Last_name", "Start_date", "End_date", "Destination", and "Reason" and we give all these variables the scope input. Now we will have to add two more variables: one is the variable that is about approving or rejecting this application and we will call this one "Approve_leave". So we will add another net variable here first, call it "Approve_leave" and this time this is a boolean variable. And the last variable is the rejection reason and this is a string and again we have to pull these variables down here and the scope now because it's the first time they are being used in this specification is output.

So very well! The next thing we will do is, we will edit this task "Note approval". So in case it is approved - and we will come back to this XOR branching here later - when it is approved, we want to see everything that has been entered in the "Submit leave request" including the approval check mark. So again, it's the same thing. We just open the data variables dialog and we just enter "First_name", "Last_name", "Start_date", "End_date", "Destination", "Reason", and "Approve_leave". And, because it's just a notification, we are going to set the input scope for all of these variables.

And "Note rejection" is very similar we just enter all of the variables we have here. And we will also enter the rejection reason and they are all of scope input. So now we have entered all of the data. The only thing that's missing now is that we need something to tell the system here for this XOR split which way to go. And which way to go is really dependent on what is the value of the variable "Approve_leave". We have "Approve leave request" selected and we go to "split predicates".

And now the system shows us "Note_approval" and "Note_rejection". And currently "Note_approval" is selected. And you can see the arrow that goes there is green and if we select the second option the arrow is green there. So what condition do we need for "Note approval"? Well, true means it's always true so that's not correct. So we want to edit that and we click the three dots here and now we have the possibility to generate an expression of a variable and we are lucky because "Approved_leave" is already selected here. So what we do is, we just press these two circles here and then we get an expression that gives us the value of the variable "Approve_leave". We will cover the subject of these expressions in a later video. For the time being, all we do now is we check if the value of this "Approve_leave" variable is true and we put true inside hyphens and then we can see the expression is syntactically correct and we press ok.

So that's all that we need now and we just have to check if our specification is valid. So we validate it here: "no problems reported" and then we save it here and it's done. So now we have entered the data for our little specification and in the next video I'll show you how to enter the resources that are going to work with this. See you then!

YAWL BPMS Tutorial 6

YAWL BPMS Tutorial 6 ahense Sat, 05/09/2020 - 12:40

In this tutorial we use the YAWL Control Centre to create roles and users. Then we continue using the YAWL Editor to assign roles to each task. We will use the "retain familiar" workflow pattern.


Hello and welcome back to the YAWL tutorials. In the last video we have entered the data necessary for our little workflow and this time, we will talk about resources: the question who is going to do what? So we will first go into the control center and we will create some roles and also some users and then we will go back to the YAWL editor and enter the roles: who is going to do which tasks? So let's start. You can see here the YAWL engine is already started, the editor is open and running and we now go to this button here and enter the YAWL logon page. And remember from one of our previous videos that the username is admin here and the password is YAWL - "Y" "A" "W" "L" - all in capital letters. So once we have that, we press the login button. So in order to start here, the first thing we have to do is open the org data tab and inside the org data tab, we are able to edit roles. So we first click new and then we enter the role name here and the role name is "Applicant".

We don't do a description and notes now and just add this role: "new item added successfully". And the second role we have to press new again and this time, it is the Approver and we add that as well. So the next thing we will do is, we will create users. So we go to the users tab and we will add a new user here and we have to enter first name last name and we need a user ID and we need a password. I will use the password pass - p a s s. And we have to repeat it here and then we need to assign roles to the users - one or more roles. So in this time, I want to create an applicant. So I select applicant here and I click on this little arrow here and then we see that this user lki has the role applicant and we click add. Now the system warns us that no position is specified and no capability is specified. We will cover the topic of positions and capabilities in a later video. We create a second user. This time user ID lha, password again the same, p a s s. And again, this will be an applicant. We create two users in order to show some of the interesting effects that will appear when we deal with these users and add and press ok. So now the third user will be rre and password again and this time this will be an approver. And the last user we will create today is rma, password pass and again an approver.

So now we have created these users and roles in our control center here and in order to save what we have done, we can now go to the org data tab and you can find a button here export org data to file. We will do that and you can see down here it is exporting that to yawl org data exp ybkp, so YAWL back up. So this is a YAWL backup file that is stored on the machine and I will put that in the supplementary material at the end of this video. So now that we have this, we can go back to our specifications. So it's already entered in the editor and remember, we need the connection here of the editor to our engine and the resource service and the informations that we just entered are now with the resource service because the engine doesn't know about it. So we need connections to both. So check that this is green here. If you have something red here, you cannot work. The next step will be we will go on our tasks and now we scroll down here and we go to resourcing and currently this is UUU which means everything is done by the user - meaning an administrator - and if we click these three little dots here, we come to the first point that the system can offer this work item at run time to participants, to roles, or net parameters. So we will cover the other things in a later video but roles now is the thing we need. So we go to roles and press the plus sign here. Now the system shows us the different roles we have entered previously and this time it is an applicant that we need. So we will offer this task to an applicant and that's all we want to do for this task. So we click OK. The next task is "Approve leave request". We select that, go to the left-hand side, click on resourcing, enable system offer and now we will choose approver as the role and we click OK. "Note approval" is the next task we will edit. We go to the resourcing and offer this to the applicant. The problem is now that we don't want this "Note approval" to be offered to any applicant but we want to choose the one that has filled in the application in the first place. So we have the possibility to do that and we can select "choose completer of task" and we have to select "Submit leave request" here and press ok. And we do the same thing for "Note rejection". So we put in the role applicant and we choose the completer of the task "Submit leave request". Okay, now we are done. We can press the green checkmark again: "no problems reported". We can save the workflow now, verify specification okay and now we're done.

So in principle, this should work now and we will see that in the next video. See you then!

YAWL BPMS Tutorial 7

YAWL BPMS Tutorial 7 ahense Sat, 05/09/2020 - 12:42

In this video we will deploy the workflow that we have edited in the last three videos on the YAWL Engine. We start a case and follow its status from the points of view of the administrator and the various users.


Hello, welcome back to the YALL tutorials. In the last three videos, we have entered all the information we needed for a workflow specification in YAWL. The control flow perspective, the data perspective, and the resource perspective. So now we are ready to finally deploy our own workflow on the YAWL engine. So we'll do that using the control center and the administrator account on the one hand and then we will go through our case step by step using different user accounts and I will show you how the work is being distributed by the YAWL system. So let's dive into it! Okay, so now you can see on this screen two browser windows on the left hand side we have the administrator so we are already logged in with the admin user. Remember this that this is admin and password is YAWL - Y A W L - all in capital letters. So on the left hand side, this is the administrator on the right hand side, we will log in with our users. So let's first go to the cases tab in the control center. And you can see currently, there are no specifications loaded. What we have to do now is, we have to first choose a file and we will go to our user here and we will find the application for leave. So we have selected the .yawl file and we upload it now. So you can see application for leave version is 0.4. So the YAWL editor is automatically increasing the version numbers as we save the specification and we have the explanation example application for leave. So we will launch our first case here. We have to select the application first. So select the application and launch case. Okay, so now I can see I have launched the case and it has the case ID 4 and I can go to the admin queues and see what happens and I can go to the Worklisted tab here and see that "Submit leave request", which is the first work item in our case, is assigned to two users: Liana Hayes and Lila King and that's what I would expect. So now I can go to the right hand side and I can login with Liana Hayes -  lha - password pass and I can see "Submit leave request" here in my offered queue. I accept and start, go to the started tab and press view edit and then I put in my data: first name, last name and then I put in nine of September until nine of October and I go to Munich and yes the reason is Oktoberfest. So then I complete the work item. Now going back to our administrative view, let's refresh here. We can now see "Approve leave request" which is assigned to Rosa Maine and Ray Rees. These are the two users we have created in our last video with the role approver in the offered stage. So on the right hand side, I log in with the user Ray Reese - let me log out first - so log in with Ray Rees, passport pass and now "Approve leave request" is in the offer queue. I accept and start, go to the started tab and click view edit. Now I can see all of the data that have been entered in the previous tasks in read-only mode - they are grayed out - and I can approve the leave and I can say the rejection reason is none. It's not rejected is accepted and I complete going back to our administrative view, refresh and see "Note approval" and "Note approval" is now assigned to one. That's what we would expect because we said we want to assign or offer it to the completer of the first task in this workflow. So if we go now back to the other browser where we have been logged in with this user that did the first step we can refresh here and we now see in the offered tab that we have "Note approval". We accept and start it, go to the started tab and click view edit and now we have "Note approval" here with the approved leave check mark set. All the data we have entered is valid. We can see them again and we press complete and now we are done. Because this was the last task in our workflow and if we go back to the admin queue and refresh, the lists are empty here and if we go to the cases we can see there are no running cases. So our first case has been completed successfully.

So this concludes our tutorial on how to execute a workflow on the YAWL engine. See you next time!

YAWL BPMS Tutorial 8

YAWL BPMS Tutorial 8 ahense Sat, 05/09/2020 - 12:42

In this video we talk about the basics of the OR-Split and the corresponding OR-Join. The example specification is about an automatic ordering process in an Italian restaurant.


Hello and welcome to another YAWL tutorial. So today we are going to talk about the OR split. The OR split is one of three splits in YAWL and it allows us to choose one or more of the subsequent branches. We will start with a very simple example in an Italian restaurant an automatic ordering process and we have already prepared the YAWL specification for you and you can find this down in the link to the supplementary material. Yeah, so let's dig into it! On the screen I have already opened the control center which is in the left corner on top. The YAWL engine is running and so is the resource service and on the bottom, you can see the YAWL editor which is connected to the engine and the resource service. You can see that by these green checkmarks and on the top right, we have a folder with a supplementary material which you can find down in the link below. So we also see the ordering restaurant XSD file which is there which is already incorporated in the tutorial 8 .yawl file. So what I'll do now is, I'll drag and drop this file into the YAWL editor and you can see that some parts of it are already edited so we'll build on that and later on we will deploy that and we will use the YAWL control center on the right hand side at the bottom. So let's go to the editor now. So the topic is the OR join and the OR split. So we have an example workflow here where we first decide on the menu and the idea is that you can choose between an entree, a main, and dessert and the main course is always there. So you cannot unselect the main course and the entree and the dessert are optional. And that is exactly the kind of thing that you can do with an OR split. So let's first select the OR split in the editor. So we go down to ... we'd select the task "Decide on menu" and we go to split type and set it to OR. And now you can see the symbol for the OR split appearing here and on the right hand side, the order tasks will have an OR join. So we go to join type and select OR as well. Okay, in order to connect the tasks, we have to draw the arcs. So we go to the palette and select the atomic task and then we just connect them like that.

And that's done. And now, we go to the "Decide on menu" task and we are going to enter the split predicates that are necessary. So we go in the task section, look for split predicates - three flows - and we have "Choose dessert", "Choose main", and "Choose entree" here and in an OR split it's always the last one that is always true. So if we want to make the main course obligatory, we have to select this option here and just move it down with these little arrows to the bottom because, no matter what we enter here, the bottom expression the bottom predicate will always be true. And for the "Choose desert" and the "Choose entree" we will select some predicates now and we have already entered some boolean variables in the specification. So for the "Choose dessert" we have a variable called called "Dessert_selected" and if we select that here and we click on these two circles here, we get an expression that just gives us the value of this variable and if this variable is true, we will enter this, this branch "Choose dessert". So "Dessert_selected" is true, we go here, okay? And we do the same thing with the entree. So select here, go to "Entree_selected", click on the two little circles here and then we check if this evaluates to true.

So now we can see the split predicates for the OR split and if we go to the tasks "Choose entree", "Choose main", and "Choose desert", we have already entered some variables here. So here we can see the entre choice is then being taken and the other tasks are very similar to this. What we can do here is, we can choose the completer of a previous task. This is the retain familiar pattern. So we go to resourcing and we enable system offer and we choose the completer of the task "Decide on menu". So it will be the same user that will be selected here and we enable system allocation and starting. So it will be quicker when we just execute the workflow and we say "ok" and we do the same thing for "Choose main". So we go to resourcing, enable system offer, choose completer of task "Decide on menu", allocate and start and the same for "Choose dessert".

So now this part is done and we go to the last task "Order" and in the order task we do the same thing: we enable system offer, choose completer of task. Now we select "Decide on menu" again and enable and started. So now this specification should be done and we will save it and then deploy it. So let's do that. So we press save: "no problems reported". We go to this upload specification icon here, press that and we unload all previous versions and launch a new case. If you want to upload this, you can either create your own user or you can upload the YAWL org data export ybkp file here and then you will have the same user. So I'm now here in this control center with a user that has also the admin role. So you can see, we have two lines of menu items here and now I am - when I look at the cases tab - we can see that tutorial 8 is started with case ID 4. If I go to the admin queues, I have one unoffered task and I can start that directly to me. So I do that, I go to my work queues, go to the started tab, and I click view edit and now I can decide on the menu. So I can select entree or dessert or both and in the first run, I will just eat a main course - that's all. So I will complete here without selecting anything in addition and now, if i refresh here, I get the next work item "Choose main" in my started queue. Press on view edit and now I can do the choice of the main course. So I will eat bistecca di manzo and complete and now again, I can refresh here, view edit and I could see my order is just the bistecca di manzo. So I will complete that here. So now let's try it again and be a little more hungry. So I will start a new case, choose the tutorial specification, launch the case, go to the admin queue and "Decide on menu".

Entree and dessert selected, complete and now I have three tasks to fulfill. I choose this one and this one and the last one and I will go to view edit and now I can see the three choices and I'm ready to order. That's all! Today we have dealt with the basics of the OR split and especially OR join can be quite tricky. This will be a topic of a later video. Another thing we have used in this tutorial in the workflow in the ordering task was extended attributes. That will also be another video in the future. Thanks for watching!

Supplements.zip (6.48 KB)

YAWL BPMS Tutorial 9

YAWL BPMS Tutorial 9 ahense Sat, 05/09/2020 - 12:43

In this video we talk about the the XOR-Split and the corresponding XOR-Join. The XOR-Split comes in two variatioins: explicit choice and deferred choice. The example specification is about a business process where a make-or-buy decision is taken. The zip file below contains a complete YAWL specification.


Welcome back to another YAWL tutorial! This time we are going to talk about the XOR split. In the last tutorial, we discussed the OR split and this time, the XOR split has exactly one path to follow and in some ways it's a little simpler than the OR split. But there is a subtle difference between the so called explicit choice and deferred choice. In the explicit choice, it is the system that decides which way to go based on some data in general and in the deferred choice it's the environment or the user who decides which way to go. So we will use a concrete example that is to be found in the supplementary material and we are going to dig into it right now. Our screen shows four different windows: on the top left, we have the YAWL editor open with a specification from the supplementary material. On the top right, we have the supplementary material tutorial 9 .yawl and also the file with the resources that you can load into the your engine before starting. On the Left at the bottom we have the YAWL control panel with a running engine and on the right we have a control center with the admin view and we are logged in with the user lom that is admin and ordinary user at the same time. So let's look at the workflow now. The specification starts with a task called "Formulate requirement". After this task, we have a condition here and the condition is a place like in Petri Nets. If formulate requirements is finished, we find a token here in this place and one of the tasks "Define software development project" or "Prepare software procurement" can take this token and so the choice here is what is called a deferred choice because it's the environment that will choose between the two paths and it is dependent on who is going to start which of these work items first and then the rest of the workflow will follow that. Then after "Defined software development project" we have the XOR split here and this is the explicit choice. And the explicit choice here is taken on a variable called "Cost" or "Estimated_cost" and if the cost is smaller than 100,000, we will go straight on to "Start project" and if it is greater or equal to 100,000, we will first need to get approval for our project. And the same holds for the lower part of this workflow: "Prepare software procurement" and "Prepare purchase order". The approval in the middle is another XOR split. Again explicit choice and depending on if the approval was given, we will go either to "Start project" or "Prepare purchase order" depending on where we came from. And if it's not approved, we will just go to the end. Good! So this is the specification. Now let's see how this works if we run this. I have already uploaded it into the YAWL engine so we can go now to the right-hand side to this admin panel and we click on cases and we have tutorial 9 here. So I will select that specification and launch a case. Now if I go to the admin queues, I can see that one work item is work listed to Lorenzo Monaco, which is the user lom. And I'm logged in as this user. So I will find this work item in my work queues here. In the work queues I have a started work item "Formulate requirement". I open this and so I give this a title. So I want to do a CRM project and I will give us some kind of description here and an estimated cost of a thousand. So that is my requirement and I complete the task. So what happens now? If i refresh this here, I can see that I have two offered work items now: one is "Define software development project" and the other is "Prepare software procurement". And it is here with this deferred choice that we can decide to make or to buy this software. So I will accept and start "Define software development project" and watch out what happens now. I accept and start this and I refresh it here and now I have only one started work item and this is "Defined software development project". So the other work item has disappeared because its activation has disappeared. The token in the place has been taken by "Define software development project". I view and edit it and now I can change the estimated cost if I think it's more expensive. I can choose the technology and complete it here and this time, if I refresh, I go to "Start project" because this cost is lower than the threshold here. And now I can assign a project manager and complete the case. Just to do another example, I go to cases again, launch another case and go directly to my work queue and I formulate another requirement and now I want to do an ERP system and this time, the cost is little higher and again: I have these two work items offered to me. So I will go the procurement path now, accept and start and I edit it. And now I choose a supplier and I complete this work item. Now it's "Approve proposition". So in the real life, this would of course be another person doing this "Approve proposition". I go to view edit and I cannot see the estimated cost and let's say, I don't approve it. I complete and the case is done. That's that!

That was easy, wasn't it? So in the next video, we will talk about sub workflows. See you then!

In this video we talk about the the XOR-Split and the corresponding XOR-Join. The XOR-Split comes in two variatioins: explicit choice and deferred choice. The example specification is about a business process where a make-or-buy decision is taken. The supplementary material down here contains a complete YAWL specification.

Supplement.zip (3.84 KB)

YAWL BPMS Tutorial 10

YAWL BPMS Tutorial 10 ahense Sat, 05/09/2020 - 12:44

In this video we explore composite tasks in YAWL. Composite tasks allow for the creation of sub workflows and are a means of structuring more complex business processes. YAWL sub workflows are built upon the principle of Single Entry Single Exit (SESE). The file below contains a YAWL specification to start with and the result at the end.


Welcome back to another YAWL tutorial! Today we are going to talk about sub workflows also called composite tasks in YAWL. Sub workflows are needed when workflows become more and more complex to factor out certain parts of them. In YAWL we have the principle of single entry single exit, that is each sub workflow has exactly one entry point from the control flow perspective and one exit point. What is special about sub workflows or subnets is that, if you are accustomed to ordinary programming languages you know the concept of scopes that you have certain blocks and that variables are visible in lower blocks from upper blocks. In YAWL, we don't have that concept. Instead if you have a subnet, you need to explicitly pass the parameters to it and we will see that. So if you look at the supplementary material - the link below - you can upload an initial net and in this tutorial we will work on this net and bring it to a final version. Okay, let's go! So we start with a YAWL specification from the supplementary material. You can find it down here and this file is called Tutorial10.yawl. So load that into your editor and then let's start. So we have already a first task in here and we have some data types and some variables prepared. So suppose we have an ordering process where the first task is "Prepare purchase request". We then want to continue ordering and ordering is a two-step sub process. So in order to do that in YAWL, we go to the pallet here and choose the two squares here and click on a canvas somewhere and then we can connect this as any other task. And for the time being, we just connect it to the end. And now, if we go to this so called composite task, we can now create a new subnet. And the subnets name is "Order" and if we go into this new tab now. Here we have a new sub YAWL specification with a single entry and a single exit. Just as an ordinary YAWL specification. So here in this subnet, we have two tasks:

The first one is called "Approve purchase" and the second one is called "Prepare purchase order". So we go down here, create a new decomposition and the second one is "Prepare purchase order". And now we go back to the main net. We need to explicitly pass net variables down to the sub net and - in this case - we need two net variables. We go to this order composite task, click on data variables and then we say, we need the purchase request and we need the purchase order. And the purchase request is an input variable that comes from the top-level net and the purchase order is an output variable. So now we have the variables available and if we go down to the order subnet and to the task "Approve purchase", we can now drag and drop the purchase request from here and if we need another variable - let's say a boolean variable "Approved" - we can define it as a local variable here and just drag it into that task and then prepare purchase order. So variables here are the "Purchase_request" as an input variable, the "Approved" as an input variable, and the "Purchase_order" as an output variable. And this will prepare the output for the whole subnet. So that's all for now! We will continue with this example in a later video. You can find the final net of this tutorial in the supplementary material.

The next tutorial will be the first one on more advanced topics, namely the multiple instance task. Hope to see you then!

Supplement_0.zip (4.35 KB)

YAWL BPMS Tutorial 11

YAWL BPMS Tutorial 11 ahense Sat, 05/09/2020 - 12:45

In this video we look at multiple instance tasks that can have any number of work items created for each activation. The tutorial starts with the example of the selection of candidates for a position. The supplementary material contains a YAWL specification to start with and can be found in the zip file below.


Hello and welcome back to another YAWL tutorial! So in the first ten tutorials, we covered some basic topics on the Business Process Management System YAWL and now, in the following tutorial starting from today, we will cover some more advanced features and the feature we will discuss today are multiple instance tasks. So you have to know that, if we have a workflow specification we call every little step a task and every workflow specification can be instantiated into cases. So we have case one, case two, and so on and so forth. And in general, for an ordinary task which is called atomic task, we have for each activation of the task in the workflow in the case we have a work item. And normally, there is only one work item for each activation or one instance as we call it, but in multiple instance tasks, we can have any number of instances for each activation of the multiple instance task. So we will show multiple instance tasks using an example of a hiring process, where we first collect a list of suitable candidates and then we have a multiple instance tasks for carrying out the interviews. And so we have one instance or one work item per candidate to do the interview and we can distribute these work items to our personal specialists. And after all the interviews have been conducted, we can then review the results. As usual, you can find the supplementary material in the link below and we will start right now. Okay! We start here with the YAWL control panel already open and the YAWL engine is running. And we're going to click on the YAWL editor symbol here and it opens up with a specification Tutorial11.yawl, that you find in the supplementary material. This specification has two tasks for the time being: "Edit candidate lists" and "Check candidate list". And we are going to insert the multiple instance task in between the two. So we just delete the arc between the two tasks here and now we are going to insert a multiple instance task. And it's just in the palette here the second symbol from the left multiple instance atomic task. So we click that and we insert it here and then we connect it to the other tasks. And so now we have that and we are going to call this "Interview candidates". So we create a new decomposition call this "Interview candidates". And there we are. Before we edit the task, we will have a look at the data types because we need a list of candidates first. And the data types are specified here under properties of the specification and we have two defined types here. And you can see them here but in order to see them a little more clearly, we will open the file Candidates.xsd and look at the XSD specification here. So essentially we have two complex types here: the first one is called "Candidate_type" and the second one is called "Candidates_type". The first one is a sequence of a name, a phone number, and a comment. And the second one is a sequence of candidate. And candidate as you can see here is of the candidate type and it has a maxOccurs unbounded. So we can have any number of candidates in the candidate style. And that's exactly the thing we need for the multiple instance task. Now let's construct the multiple instance task. We select the multiple instance task in the editor and go to data variables. And in our net variables, we have already a variable called "Candidates" which is of the candidates type and we have already given it an initial value, which looks like this: candidate, name, phone number, comment. Currently they're all empty. So what we will do is, we will drag and drop this candidates variable into the task variables or the decomposition variables of interview candidates. And now we see a red warning here: "one variable must be marked as multiple instance" and the rightmost symbol here is "mark as multiple instance". So we have to press this and now this variable name - as you have seen- changes from "Candidates" to "Ccandidates_item". And you can also see that it is now of the "Candidate" type and no more of the "Candidates" type. So this is exactly what we want. Underneath, the editor has created a splitter and a joining query. The splitter query is "for $s in candidates * return" and so on and so forth. So this splitter query essentially splits up the candidates into single candidate items. And if we are familiar with XPath and Xquery, we can write our own queries here; but for the time being, we will just leave it as it is. And the joining query is in the output mapping. So "for $j in interviewCandidates/candidate return $j". So again the editor has created this joining query here and we are not going to touch this for the time being and essentially we are done for our multiple instance task. Of course, we could have other variables here that are not marked as multiple instance but for the time being, this is enough. We click OK and then this specification is complete. So now we will save it and upload it to the YAWL engine and launch a new case. Okay, now let's try it out. We are currently logged in here as a user that is administrator at the same time. And we have started "Interview candidates" with the case ID 36. So if we go to the admin queue, we can see edit candidate list - our first task here. And we can start that directly to our user. Ggo to the work queue, look at the started queue, and edit the candidate list. And so we can have a candidate. And now we can create any number of candidates with the plus sign here. So I will create another candidate.

And I complete this. Let's look at the admin queues now. We have one instance here "Interview candidates" and we can offer that and start it. And I conduct the interview and then I complete it. We go to the admin queue. We get another work item here. We can start this, conduct the interview, and now we have one item worklisted here: "Check candidate list". And we check the list with all the interview results.

That's all! So you've seen that multiple instance tasks are a good way of distributing work to a larger number of people; and in YAWL, there are several allocation strategies for doing this. And this will be the topic of another video. What we haven't covered today for multiple instance tasks are thresholds and also dynamic instance creation. If you are interested in these topics please leave a link below. See you next time!

Supplement_1.zip (4.77 KB)

YAWL BPMS Tutorial 12

YAWL BPMS Tutorial 12 ahense Sat, 05/09/2020 - 14:43

In this video we talk about Cancellation Regions in YAWL. These cancellation regions are a flexible tool for handling all sorts of abnormal behaviour from user-triggered abortions of activities to timeouts. The flexibility in defining cancellation regions comes at a price: it is easy to make mistakes. We show you how to avoid these. The zip file attached here contains an initial and a final YAWL specification for following this tutorial on your own YAWL installation.


Hello! Welcome back to another your tutorial! Today we will talk about cancellation regions in YAWL. In many cases it is important to be able to cancel a set of tasks once you have started a complex workflow. In YAWL, cancellation regions are an extremely powerful tool. However, it's not so easy to use them correctly. Today, I will show you how to avoid mistakes while defining cancellation regions and we will give you an example and explain the mechanics of these cancellation regions. As usual, you can find supplementary material in the link below. And we will start right now. We will start off with a specification that you can find in the supplementary material. The file is called Tutorial12.yawl. And you also need to load up the YAWL org data export ybkp file first. If you don't know how to do that, look at one of the previous tutorials. This specification is already loaded in the YAWLeditor here and you may recognize it because that is the specification of tutorial 9. We have someone formulating a requirement and then, there is a process going on, where we decide to either develop software in a project or to procure software. Imagine that after formulating the requirement you find out that you don't need this software after all and you want to cancel the whole procedure - no matter where it is now. So if we look at all this part of the specification after formulate requirement, we may say that ok, until the purchase order is sent out or the project is actually started, we can still cancel the whole thing. And we want to give the possibility of canceling to the same user that has formulated the requirement. So how can we do that? Well, we will first create an AND split after "Formulate requirement". And this is a very frequent pattern here. So we select "Formulate requirement" and go on the left-hand side, look at the split type and select. And here, we will insert a task "Cancel requirement" and connect it here and then also connect it to the end. And this cancel requirement task will be offered to the same user that has formulated the requirement. So on the left-hand side, we go to resourcing, enable system offer, and we will choose the completer of task "Formulate requirement". In order to define our cancellation region, we need to click on this red circular symbol here. And then we get another symbol here that allows us to add elements to this cancellation region. We have to select everything: starting from this condition here, all of the tasks in here, and also the arcs between the tasks. The reason that we have to select the arcs is that YAWL comes from Petri Nets. And in Petri Nets, between two transitions, there's always a place. And you can imagine that each time we have two tasks or two transitions in a YAWL specification, that there is an implicit place in between them which is on the arc. And that is why we have to select all of the elements now in this cancellation region we want to define. So we select the condition here and click "add" and then we select the tasks.

And we select all the arcs between the tasks. And now, our cancellation region is complete. And we will also ... now we can stop this ... and now we don't see the cancellation region anymore. We can select tasks again and click it to see it again. And you can see now this red dot appearing here indicating that this is a cancellation task. And we will also define "Start project" and "Prepare purchase order" as cancellation tasks. So again, we will define the cancellation region. And this time, we will select "Cancel requirement" and the arc before that. See "Start project" now is a cancellation task. And we will do the same thing for "Prepare purchase order".

And we're done. We save this and we upload it to the YAWL engine. Now, we can start to execute the case and see how it behaves. So the first task is assigned to Lorenzo Monaco: "Formulate requirement". And now, we have three work items: "Cancel requirement", which is assigned to Lorenzo Monaco, the same user that just started the requirement, "Define software development project", and "Prepare software procurement". So all of them are now assigned to the same user. This is for demonstration purposes and let's see what happens, if we do "Cancel requirement".

"We accept and start it. And you can still see the other two are still there. So it started and, because we didn't define any behavior for it, we cannot view it but we can complete it. And you can see now: after the completion, all the other work items are gone. And if we look at the cases, we can see the case is finished. So this cancellation has worked. You can try yourself executing now the workflow in the rest and for example go to start project and look at which moment in time the "Cancel requirement" task is in turn cancelled. And this pattern here that we have two regions in the workflow that mutually cancel each other, is a very frequent pattern in workflows.

If you have any questions, please ask them in the comments and don't forget to subscribe to this channel, if you don't want to miss any new episodes. See you soon!

Supplement_2.zip (8.11 KB)

YAWL BPMS Tutorial 13

YAWL BPMS Tutorial 13 ahense Sat, 05/09/2020 - 14:52

Timeouts are an essential element in business processes. Participants who have accepted a work item may be absent and a timeout can trigger an escalation to the next level. In other cases, there may be fixed deadlines to meet and certain activities do not make sense once they are passed. In many cases, timeouts are combined with cancellation - a topic that we have dealt with in the previous video. In this video we cover the topic of Timer Tasks in YAWL. They are easy to set up. The zip file attached here contains an initial and a final YAWL specification for following this tutorial on your own YAWL installation.


Hello and welcome back to another YAWL tutorial. Time-outs are useful when something takes too long. YAWLl has so-called timer tasks that allow you to stop waiting for the completion of a work item, when a certain time is reached or a time interval has elapsed. In this tutorial, we will show you how timer tasks work. Our example today is a silence procedure, where a proposition is accepted if no one rejects it in a certain time interval. As usual, you can find the workflow specification in the companion page following the link below on the screen. We have already our specification from the supplementary material open in the YAWL editor. The file is called Tutorial13.yawl and this specification is a silence procedure. So essentially, someone writes a proposal and then this proposal is distributed to three entities: A, B, and C, who can evaluate the proposal. If their evaluation is positive and all of them are positive, the same user that has written the proposal notes the acceptance of the proposal. If however, one of them rejects the proposal, we go here to this cancellation task and once this is completed, all of the other evaluations are cancelled as you can see from this cancellation region. Cancellation regions were a topic of the previous tutorial. Then "Note rejection" is executed and this is offered to the same user that has written the proposal. So what we want to do now is to introduce timer tasks for the evaluations. So if someone fails to evaluate the proposal in a given time interval, this means that the proposal is accepted from this perspective and our timer task can help us here. So let's edit timer tasks. We select "Evaluate proposal A" and on the left hand side we see timer. And if we click on the three dots, we now have the possibility to set a timer for this task. And we can set it either on offer or on start. On offer is the correct choice here. And then we have possibility to set, when the task expires. And we can either set an exact date, a fixed date, or we can say after a duration, or we can even do this via a variable. But for this variable, we need a variable in a specification. We will not cover this here now. What we will do is, we will do this "after a duration of". And then we have seconds, minutes, hours, days, and so on and so forth. So for testing purposes, we will set this to two minutes and click OK. And then we do the same for "Evaluate proposal B". We'll set this to two minutes and also for "Evaluate proposals C".

And you can see now that these tasks have this clock symbol here indicating that we have timer tasks. Here we save the specification and we upload it to the YAWL engine. We open the control center and we see that there is a case started with case ID 41. And "Write proposal" is in the unoffered work items. So we start that and write the proposal and complete it. So now we have the two minutes timer running. If we go to the admin queues, we can see "Evaluate proposal A" and we can see "expires in 1:51 and if we press refresh, you can see now it's 1:41 and so on and so forth. And the other tasks are the same. So we can see the time until the timer expires here. What we can also do is, we can evaluate one of the tasks - let's say this one - and we accept - let's say we accept it - and we write a comment and complete it now. So this one is a manually completed task. We go back to our overview here and we can see that these tasks expire. So if we now take one of them- let's say C - and start it.

Go to the work queues, and now we don't accept it here. We have now a task "Note rejection" because one rejection is enough and we can see that one of these evaluators has rejected the idea. And we see the comment and this is all gone. Now let's try a positive case with a timeout. We'll start another case and now let's say one of them accepts it again. And now we just have to wait until the two minutes are over. So it expires in four seconds and you can see now they have gone and we have "Note acceptance" here.

I'm sure you already have an idea where to use timer tasks. If you do this and are successful, please let me know in the comments below. See you next time!

Supplement_4.zip (6.15 KB)

YAWL BPMS Tutorial 14

YAWL BPMS Tutorial 14 ahense Sat, 05/09/2020 - 14:53

In this video we talk about defining your own data types in YAWL. These are defined using XML Schema Definition (XSD). We also demonstrate how to access parts of complex types using XQUERY. The zip file below contains an initial and a final YAWL specification and an XSD file.


Welcome back to another YAWL tutorial! Today, we will talk about data and data types. Data is one of the most complex topics in Business Process Management Systems. When it comes to data types, different systems take different approaches: some Business Process Management Systems just work without any types. So you can input anything into the fields. Other Business Process Management Systems allow you to define a small set of very simple types that are proprietary and made especially for the purpose of Business Process Management. YAWL has a different approach here. YAWL uses XML, XML schema definition and Xpath and Xquery. One advantage is that you can find lots of information on the Internet about XML and all the surrounding technologies. Another advantage is that there are many APIs and software libraries that can for example translate XML elements into java objects and then java objects into relational database tables. We start from an XML schema definition and then demonstrate how that XML schema definition takes effect in the forms that are generated by the YAWL system. So let's dig into it! Today's tutorial is about types. So in XML, types are called a schema and XML schema definition - XSD abbreviated - is something that we will start with. So if you look at the file here - you can find this in the supplementary material - you can see that there is a number of complex and simple types defined. If you want to know more about the details, as already said, there are many tutorials on this on the Internet for example by the w3c schools and many others. So here you can see a complex type called customer list type and this is essentially a list of customer type elements. Customer type is a type that consists of a customer id which is a positive integer, a customer category, a customer name, and an email. The first three types are standard XML schema types as you can see from the prefix xs. And the last one is a type that we define here. The email address type is defined here and this is a restriction on the XSD standard type token, which is a subset of string and you can see here a regular expression. So if you want to know what this regular expression means, you can look up on the Internet looking for regular expressions in XML schema definition and just to note one thing: for example the at-sign of the email address appears here. The other type that we have is a category type abc. So this will create a drop down list. And then we also have an email address list type. Now let's take this type definition and copy it to a new YAWL specification.

So we select all that, copy that, go to the yard editor, and start a new YAWL specification. And we go to data definitions here and we paste that in here and if it says ok, then the syntax is correct. So now, we start editing our workflow. So we insert two tasks: first one is called "Edit customer list" and the second one is called "Check email addresses".

Now we define our net variable. Go to data variables and call this "Customer_list". And this is of type customer list type and we can give this an initial value. So if we click here on the three dots and we press this double circle here, the system generates an XML element that is correct for this type. You see, there is one customer with a customer id, customer category, a name, and an email address that corresponds to our regular expression. And I will replace that by two customers with email addresses and everything correct. So now we have a list of two customers here and this is the variable that is initialized at the beginning. If we go to the customer list task, we just drag this variable in here. So we can edit it later on. Nothing needs to be changed.

And now what I want to do is, I just want to show you how to access parts of the complex types and we will do a more complicated example with an Xquery. The Xquery is here.

So what we want to do is, we want to look inside the customer list, take the content of that customer list/*, and then return for each element in the customer list, an email element, where the content of the email element is the email address, the text of it, this is the email address itself, of the customer list element.

So copy that and now we go to the "Check email address" and we create a new variable here: email addresses and this is of the email address list type. And we make that an input variable. And now we have to define the mapping because the editor cannot find it automatically and we insert this Xquery here. So we go to the control center and look at the admin queues and we can see that "Edit customer list" is unoffered. So we assign it to the same user. And we can see the customer list is displayed here. And we can add other customers or we can edit the fields of each customer so we complete that. And then check email addresses. And you can see that the email addresses are displayed and they are in read-only mode. The Xquery was a little complex, wasn't it? But don't worry, it doesn't get any more technical than that in YAWL. If you want to develop software and you have to connect to other systems, this is done by software developers and in YAWL there are codelets for this purpose. Codelets will be the topic of another tutorial in the future. Thank you for watching!

Supplement_5.zip (4.96 KB)

YAWL BPMS Tutorial 15

YAWL BPMS Tutorial 15 ahense Sat, 05/09/2020 - 14:56

In this video we talk about defining your own data types in YAWL. These are defined using XML Schema Definition (XSD). We also demonstrate how to access parts of complex types using XQUERY. The zip file below contains an initial and a final YAWL specification and an XSD file.


Hello and welcome back to the next YAWL tutorial! Today we will talk about capabilities. So from the resource perspective, we have mostly used roles so far and this is in practice - at least from our perspective - the most frequent case. But YAWL has more than that. YAWL has not only roles but also capabilities, positions, and org groups. And you can see that here in the chart behind me how this is built up. This chart comes from the your book by the way. Today we will use a simple workflow dealing with insurance claims that demonstrates the use of capabilities. So let's go to the computer. Before we go into the YAWL editor, we will first look at the YAWL control center, add the org data and the users we have created. You can upload these to your own system by importing the ybkp file in the supplementary material. Good! So we have in the org data, we have one role called claims and we have capabilities health insurance, life insurance, and travel insurance. Health insurance is held by Albert Schweitzer, life insurance by Jeanne Calment, and travel insurance by Albert Schweitzer and Ferdinand Magellan. So this is the distribution of the users. The users all have password "pass" and they have their initials as the user id as you can see here. So now we'll look at the specification that is prepared and you can find it in the supplementary material and it starts with assessing the claim. And if it is not accepted, there will be a rejection sent to the customer in the categorize claim task. We choose one of the categories health, life, and travel. And depending on this choice, we will go into one of these tasks here. And they all have the same decomposition. But now we will enter different capabilities here. So we go to the calculate payment amount in the health branch and we will go to resourcing.

And now we see the role is claims and now we can add a capability and we choose health insurance. That's it! We have to double click it, press ok. The same thing here: for live life insurance and for "Calculate payment amount". Travel insurance. Nnote that it's also possible to make a conjunction or disjunction of capabilities. So you can ask for all of these capabilities for example if you want to. So that's it. We save the specification now. Let's check whether everything works as expected. So I have here on the left hand side the YAWL control center with the admin logged in on the right hand side. It's the user Jeanne Calment, jc which is logged in here and at the bottom we have the workflow specification. So we have already loaded it in the engine. So we launch a case and we look at the admin queues and we see, there is one work item "Assess claim" as you would expect and it is assigned to our three users in the system. So that's good and if we go to Jeanne Calment we have this work item here. We accept and start it and then we uncheck the rejection and we complete this first one.

We refresh here and now we have "Categorize claim" again assigned to three users and we can accept and start it with the same user here. And now we can set the category and I will choose "Calculate payment amount" for the travel. So we select travel here, we complete and then we check here "Calculate payment amount" for travel. And now this is assigned to two: Magellan, Ferdinand and Albert Schweitzer and this is exactly what we would expect. So capabilities are straightforward to define. Just watch out that the distribution set doesn't become empty. When you define too many constraints because in that case the administrator will have to distribute the work item manually. It's a little unfortunate that capabilities cannot be defined via variables as it is the case for participants or roles. That would be a feature I would like to see in the future in YAWL. The next topic are positions. So stay tuned!

Supplement_6.zip (6.92 KB)

YAWL BPMS Tutorial 16

YAWL BPMS Tutorial 16 ahense Sat, 05/09/2020 - 14:57

In this video we talk about Positions and Org Groups in YAWL. These are two further components of the YAWL organisational model. We define an example org chart in the YAWL control centre. The zip file below contains a final ybkp file with the org chart in YAWL. 


Hello! Welcome back to the next YAWL tutorial! This one is on org groups and positions. So this is the next component of the YAWL organizational model that you can see on the slide behind me. On this slide, you can see that participants can hold any number of positions. Positions can report to other positions. So this is the relation to the next higher in the hierarchy and positions can also belong to one or more org groups. And all groups form a hierarchy by themselves. The reports to hierarchy and the positions hierarchy can be aligned but don't have to be. So today we will show you how to define such a hierarchy in the YAWL control center. We will not build a workflow this time. Let's draw an organizational chart with some organizational structures and some positions.

So there is a software division. The top organizational structure here and a position called vice president and below that we have a programming department. And perhaps some other structures here. And in the programming department there is a manager. And below that we have team A and team B. And in these teams we have programmer A1, programmer A2, and programmer B1, B2. And now these programmers report to the manager. And the manager reports to the vice president. Let's now enter the org chart we have created in the YAWL control center. So we login as administrator and we go to org data and there, we start with the org groups. And the first or group we will enter is the software division.

And the software division or we have to press new first. So new software division and then the group type is division here and it belongs to no other or group. And we add this. Okay! The next one is the programming department. So we press new, programming department, and this is a department and it belongs to the software division. We add this one. Tthen team A. Team A is a team and this belongs to the programming department. And likewise team B is a team and belongs to the programming department. Now that we have the org groups, we can enter the positions. So we start with the vice president, go to the positions tab: new vice president.

And notice now that we cannot enter the org group at the moment. This is strange. Um ... we first have to add this vice president position and then now we can select the or group. So we say the vice president belongs to the software division. And we can save. The next one is the manager. The manager belongs to the programming department and reports to the vice president. Then programmer A. Programmer A1 is a member of the team A and reports to the manager. And the next one is programmer A2 is member of team A and reports to the manager. And then  programmer B1 and programmer B2, team B, and programmer B2 reports to the manager.

Okay! Now they're all in. Before we created the org chart, we have in fact created a user. And the user also has a role and so we need that in order to test our positions and or groups with the workflow. So let's now go to the YAWL editor and select a task here and go to the resourcing.

And you can see, we can enable system offer now. And we offer this to the role programmer. And then in the org structures, we now have org groups and positions. So for example we can say that this should be offered to a member of team A.

And that's how it works. So you've seen that organizational structures and positions are quite expressive and that they are part of every personal management system and this is the bridge from the more role-based workflow into the organization. That's all for today! See you next time!

Supplement_7.zip (1.51 KB)

YAWL BPMS Tutorial 17

YAWL BPMS Tutorial 17 ahense Wed, 09/09/2020 - 09:19


In this video we talk about two of the so-called resource patterns in YAWL. The first one is the four-eyes principle also known as the separation of duties. The other one is called retain familiar. Both of these patterns appear very frequently in practice. This is why they are implemented in YAWL. The attached zip file contains a complete YAWL specification to start with an a ybkp file with the users and roles. 


Hello and welcome to another YAWL tutorial! Today I've brought with me the book on workflow patterns and we will talk about the four-eyes principle and also the retain familiar pattern. And they are something like two sides of the same coin. So if we look at the four-eyes principle in the book - it is also called separation of duties - it says "the ability to specify that two tasks must be executed by different resources in any given case". This four-eyes principle is often applied when we have something like payments for example. You do not want that only one person is issuing the payment but you want to control this action by another person. Well the opposite pattern of this is called retain familiar. So you want to have the same person that for example has issued a purchase request to execute the work item where this person is informed of the successful or the unsuccessful outcome of this case. Both of these patterns are inbuilt in YAWL and we will take an example of tutorial 10 and extend it to have this. We will also use a set of users and roles to demonstrate how that works. And we will start off with the complete specification that you can find in the supplementary material. Okay! We have the YAWL engine running and the editor open with the specification that we have already prepared and that you can upload from the supplementary material. So you can see, there is a first task "Prepare purchase request". Then there is a complex task "Order" and then, after the ordering is finished, the shipment is received and the invoice as well and after these two are completed, we can proceed to payment. And the first restriction that we have here is that we want to have the same user receiving the shipment that has prepared the purchase request. So here, we use the pattern retained familiar and in the YAWL editor, if we select "Receive shipment", we can see that here under resourcing, if we select that, we see that here there is a check mark "choose completer of task" and here this refers to "Prepare purchase request". So this guarantees that the same user will open this work item here for receiving the shipment. The next thing is that the "Prepare payment" is the same as "Receive invoice". "Receive invoice" is this task and "Prepare payment" is here inside the payment subtask. And if we select "Prepare payment", we look at the resourcing here and we can see "choose completer of task" "Receive invoice" and net is mentioned here because this is part of another subnet.

And the third one is that "Execute payment" is different from "Prepare payment". So here we have "Prepare payment" and here we have "Execute payment". And if we look at "Execute payment", we can see that this is offered to someone with the finance role but we do not want to choose the completer of task "Prepare payment". Now let's see if this is doing what it's supposed to do. Llet's first look at our organizational structure. The organizational structure is here in this Excel sheet.

And you can see all the users with their user ids and they all have the same password and their roles. This can be uploaded from the supplementary material into the YAWL system. Aand so what are we expected to see with the restrictions that we have. The first thing is that we want to check if we use "Prepare purchase request" then we have the same user for "Receive shipment". So we have created two users here with the role requester. And so in "Receive shipment" we should see the same one that we use the first time. The second thing is that "Receive invoice" and "Prepare payment" should be the same. So that's why we have here the role finance and we have two users with the role finance here. And last but not least, the four-eyes principle, we want to make sure that "Execute payment" is offered to a user that has not prepared the payment. We upload the specification to the YAWL engine and launch a new case. And a new case is launched with case id 3. Okay! We look at the admin queues and look at who has work items. And the "Prepare purchase request" which is the first task in our specification is now offered to two users as we would have expected. The two users we have here in our list. And let us now choose the first one here.

So the username is ror. We login and we see "Prepare purchase request", accept, and start. View/edit and we complete this purchase request. And next we look at the admin worklist and see what's happened. So now we have "Approve purchase" which is part of the subnet order. The first task in the subnet and this is assigned to one user because we only have one manager user with the role manager. And so here, we just log out and use this manager user: acceptance, start and we approve this.

Go back to the admin queue and see what's happened. So "Prepare purchase order" is the next task and this is assigned to Peter Parker and Peter Parker is the one that the only user from purchasing. So we have to login as this user and we can just fill in some values here and prepare the purchase order. So now we go back to "Receive shipment" and "Receive invoice". So we should see both work items in our list. And "Receive shipment" is assigned to one user and this is the one we have chosen in the first place. So this is correct. So it's not assigned to both, because here we have used the pattern retain familiar.

So we log in as ror, acceptance start and we enter a shipment number. And complete this. And the other one is "Receive invoice". This is assigned to two users because we have two users in the financial department. And we will just use the first user Fred Flintstone here. Input and invoice number and then we are done. So now these two tasks "Receive shipment" and "Receive invoice" are completed and we proceed to the pay sub workflow and the first task is "Prepare payment".

So here "Prepare payment" is offered to one because we have used the retain familiar pattern here. And this is the one we would expect. So I just refresh here. I get this task and I enter an account number and then we're done. And now the next one because we have used the four-eyes principle.

We would expect that this is not the same user and in fact we can see that this is assigned to Fleur Forsite. So we have to log out and complete it. And then the case is finished. You may have wondered what happens if the manager does not approve of the purchase. We didn't include any logic in here we will treat this topic in a later tutorial when we'll introduce the concept of exlets. So stay tuned!

Supplement_8.zip (10.88 KB)

YAWL BPMS Tutorial 18

YAWL BPMS Tutorial 18 ahense Wed, 09/09/2020 - 09:28

This is the first of four tutorials on flexibility in YAWL. It gives an overview of the worklet service, exception handling using exlets, and Ripple-Down Rules (RDR). 


Hello and welcome to another YAWL tutorial! This is the first of a series of tutorials about flexibility in workflows. There's a saying that states that 95 percent of the discussions are about five percent of the cases in software development. And this is about the same thing for Business Process Automation. So it is important to be flexible on the one hand but not to be forced to specify everything when you first develop a workflow. There are two types of flexibility: in workflows the first one is a flexibility at design time. We have already seen that by the separation of concerns of separating control flow, resources, and data and having a graphical editor, we already get a certain degree of flexibility in workflows. Furthermore, you are able to change a specification in a running system and have the old cases that are already running finish with the old specification and start the new cases with a new specification. So already, we have a certain degree of flexibility. What we will discuss in this and the subsequent tutorials, is an enhanced flexibility, where you also have the possibility of extending the behavior of a workflow specification without changing the specification itself.

The second kind of flexibility is concerned about changing something while a case is running. So this is more a dynamic flexibility. And also here we will have some concepts concerning worklets and exlets in YAWL that will cover this. As already said you cannot think of all possibilities when first designing a workflow specification. So in the first category of flexibility, we have concepts in YAWL like worklets that specify a certain behavior and you are able to invoke those worklets using so-called ripple down rules. Ripple down rules are trees, binary trees with conditions and conclusions that you can use to flexibly extend the behavior of a workflow specification as you find new special cases. These are also called cornerstone cases.

The other thing is that we have the problem that for example exceptions when they occur often imply that you terminate a case. But you want to do something before you terminate a case abnormally. If we would try to implement these with ordinary control flow means, we would have lots of arcs going from certain places to the end of the specification. And this would in the end lead to a graph that is more like spaghetti and is not very clear anymore. And so - for this case - we have the possibility to use exlets and define certain pre- or post-conditions in tasks and then somehow to terminate a case with a certain exception handling and not using these arcs that lead to the end. In the second category for dynamic behavior, we can define external triggers in YAWL and we can modify the behavior of a running case by using these external triggers, write worklets that define new behavior, and add that to the system. And so we obtain a learning workflow management system that incorporates new exceptions as time goes on. Last but not least, it is possible to factor out common behavior in workflow specifications using worklets. This doesn't have to do directly with the topic of flexibility but it is another use of worklets. We have already seen in previous videos that you can have complex tasks with sub workflows inside. The problem of these complex tasks is that they are limited to one specification. If we think of a bigger system with many workflows all around the same topic - let's say we need the possibility to factor out common behavior in sub-workflows - and we cannot do that using complex tasks because complex tasks are only existent in one specification and for this purpose we can use worklets as well with a very simple rule that is always true. And then we can invoke the same workflow specification from different parent specifications.

Okay, this is all for the theoretical introduction. And in the following tutorials we will go into the topics and look at them in the YAWL system.

YAWL BPMS Tutorial 19

YAWL BPMS Tutorial 19 ahense Wed, 09/09/2020 - 11:57

This tutorial is about Ripple Down Rules (RDR). RDR are binary trees that are used in YAWL to gradually extend the handling of special cases in workflows. In combination with worklets and exlets they are providing flexibility to YAWL workflows. The attached zp file the specifications and rule sets needed for installation on your own system.


Hello and welcome to the second tutorial on flexibility! This time we will talk about ripple down rules. Ripple down rules are binary trees with a condition and a conclusion. The condition is something that is evaluated on the data of the case and the conclusion is a worklet.

By constructing these ripple down rules, we are able to dynamically extend the behavior of a workflow specification by adding it to one task in the workflow specification. And then this binary tree can grow as special cases arrive and deal with special behavior that we didn't think about when constructing the original specification.

These ripple down rules are evaluated with a two-phase mechanism. In the first phase, we go down the tree and each time that a condition evaluates to true, we go to the right and each time a condition evaluates to false, we go to the left. We do this until we reach a leaf in the tree. When we come to a leaf, we go to the second phase. And then we go upwards the tree again evaluating each of the conditions. The first condition we find that is true will then determine which of the worklets is executed. Well, this sounds very complex and I think we need to look at it in more detail. So let's look at an example. So the example comes from the YAWL distribution and is about organizing a concert.

Before we do the show in the concert, we check how many tickets have been sold. And if the number of tickets sold is less than a certain threshold, we will do a certain action rebooking the venue. This action is triggered by a so-called work item pre-constrained violation and I will show you the ripple down rule tree associated with it that is in the specification. And so you can get all of the specifications in the supplementary material as usual but you can also find them in the YAWL distribution.

So every ripple down rule tree has a top-level node with the condition true and the default behavior. The default behavior as it is specified in the YAWL specification. And we call this the condition and this the conclusion. So every node in this tree - if it's not a leaf-  has two children. The child on the left hand side is the one that we take if the condition is not evaluated but here it is a  constant true so this is always given. And on the right hand side, we have a node that is taken if the condition is evaluated to true. So in this case, we go here to the right hand side and let's say we want to have a rule that if tickets sold is less than 75 percent of the tickets as a condition and in this case we will change to mid venue.

So change to mid venue is the name of a worklet we have specified before. And then let's say if it's even worse and we have sold less than 50 percent of the tickets we want to change to a small venue. So again, if this is true and if it's less than 75 percent and if it's less than fifty percent tickets sold, we change to small venue. And if it's less than twenty percent we cancel the show.

So this is the rdr tree that is in the specification and in the rule set attached to it. We will see that later when we open this in the YAWL editor. And then we can have we can think of having these leaf nodes here, empty nodes, that are attached to each of the nodes here and just for the sake of generality, I want to show you that it's also possible to extend the tree by nodes on the left  hand side. So for example we could say that if tickets sold is greater than 95 percent then we inform about the fact that everything is sold out. Something like a press information.

Okay! I mean this is not in the YAWL specification but we will just explain the behavior of the algorithm now with this complete tree. So in the first phase, we we start here and the first phase is going down. So each time a condition is evaluated to true, we go to the right hand side. And if it's false, we go to the left-hand side. So this is the constant true. So we go to the left to the right hand side. Let's assume that for the first case we have tickets sold is 40 percent and let's say in case two tickets sold is 98 percent. And then see for the two cases how this works. So in the first case ticket sold is 40 so it's less than 75 percent. It's true it's less than 50 percent. This is true. It is not less than 20 percent. So eventually we end up in this node here. And then we are at a leaf and the second phase starts. So now we go up the tree and the first condition that is true determines which conclusion to take. So this one is false this one is true. So we change to small venue. So in case that we have 40 percent we change to small venue.

Let's now take case 2: 98 percent of the tickets sold. So this is true we go to the right hand side. This is false. We go to the left hand side and this is true. So we go to the right hand side. So what we are in this leaf now. Now is the second phase. We go up a step and this condition is true. So we inform about tickets sold out. Let's take a third case and let's say it's 91 percent. This one is true. This one is false. This one is false and so we come to this node here. Now the second phase with 91 this is false. This is false. This is true. So we do the default behavior. So we do what is said in the specification itself and we do not invoke a worklet here. We can see the organize concert workflow which is the parent process in the bottom layer and you can also see it here opened in the YAWL editor. And we have just talked about the ripple down rule tree. So where can we see the ripple down rule tree in the YAWL editor? The answer is we have to select the task "Do  show" and then we have these number of icons for the worklet service here and if we click on this one "view the rule set for the current specification" we get the ripple down rule tree here in the YAWL editor. This is a little smaller than the one we have just drawn because first, it never mentions the top node which is always true. So this note cannot be edited. So it's not shown in the editor. So we start with the second node. And it also doesn't show all of the leaves we have added to the rdr tree. So let's look at this first node here, the top level node. We can see that it is a work item pre-constrained violation meaning that it will be checked before the work item is started. It concerns the task "Do show" and on the right hand side, we can see the data context for this. So we have the tickets sold 20,000 and the seating 30,000. And if the tickets sold is smaller than seating multiplied by 0.75, then we do the actions here in this list. And in fact the number of tickets sold really has to be lower than 75 percent of the seating in order to be able to edit this rule. The actions that then come is first suspend the work items, so nobody can execute it, then do a compensating action, which is change to mid venue, and then continue the work item. So these three steps, they can be represented in the graphical notation as is shown here in the drawing and in fact when we edit these rules, we get the same notation here in the editor. I will show that in the following video. So we can imagine that this one is suspend work item with this symbol. Then we have the compensating action and then we have the continue work item symbol. The compensating action here is the worklet change to mid venue. We will not look at it for the time being and we can see that this consists of "Cancel stadium", "Book theater", and "Advise fans". So after this is done, then we have completed the "Do show" task. And this is the modified version in this specific situation. Iif we look at the other nodes in the editor, the next one is concerned with if only less than 50 percent of the seats have been sold. Then we change to the small venue. So this can be the second one here in this drawing. And the last one here is "Cancel show" which is different because the case is removed in the end and it's not continued. So compensate "Cancel show" and then we have this stopping of the case or removal of the case.

You can also see that the effective composite rule that is defined by the rdr tree is again shown here in the YAWL editor. So let's try and run this case. So we have already loaded everything into the YAWL system and we will now upload the main specification, the parent specification, and it receives case id 4. And we can see that we have "Book stadium" the first task which is unoffered now. So I will start this task for the user Matt Murdock and I will at the same time log in with this user here. And we can see what's happening. So this one is started and I now have the venue cost, the seating 25,000 and I have the venue name which is ANZ stadium.

Okay! So this task is completed. Just keep in mind that we have a seating of 25,000 and we look at our interface and see the next work item "Sell tickets" which is again unoffered. So I will offer it to the same user. And now we have the ticket cost and the tickets sold and so let's say we have 12,000 tickets sold which is less than half of the seats.

Then we would expect to change to a small venue. And now you can see in the admin interface the "Do show" work item here. This one is suspended because we have suspended it in our actions and then we have the "Cancel stadium" work item here which is enabled and unoffered. Also note that "Cancel stadium" has case id 5 whereas our parent case has case id 4. So a new case is created for our worklet and we start this cancel stadium again for the same user to make it simple.

And then we can cancel the stadium. Now we have the next work item here: "Book concert hall". And now we have a different venue let's say which costs less with a seating of fifteen thousand.

And the next task is called "Tell punters". So we start it again for the same user. So we can now see the seating and the venue name concert hall and now the worklet is done and we have the "Do show" task unoffered here. And "Do show" now is in the concert hall with a smaller number of seats and our tickets sold. That's all! So you've seen that this is quite complex. But it's also quite powerful. As you can see in the graphics here behind me, which comes from the YAWL book, we have three layers on the bottom layer, we have the parent workflow specification with the task "Do show". And then "Do show" is connected to an exlet. This is in the middle layer. And this exlet is a pre-work item constraint violation: for example that the number of tickets sold is not enough. And then there is this behavior defined in this exlet - and we will cover exlets in the next tutorial - and then this exlet as a compensating action calls the worklet that changes to the mid venue here. And this is the top level. So you can combine worklets and exlets in this manner but you can also use worklets alone without exlets. So let's look at this in more detail in the next tutorial. See you then!

Supplement_9.zip (15.5 KB)

YAWL BPMS Tutorial 20

YAWL BPMS Tutorial 20 ahense Wed, 09/09/2020 - 13:29

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!

YAWL BPMS Tutorial 21

YAWL BPMS Tutorial 21 ahense Wed, 09/09/2020 - 14:25

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!

Supplement_11.zip (12.63 KB)

YAWL BPMS Tutorial 22

YAWL BPMS Tutorial 22 ahense Mon, 10/19/2020 - 18:21

This tutorial is the answer to a special request: namely to talk about thresholds and dynamic instance creation in multiple instance tasks in YAWL. We configure these parameters in a specification and show their effect in running a case. The zip file below contains the YAWL specification before and after the configuration.


Welcome to this tutorial on multiple instance tasks! Tutorial 11 was the first one about the basics and Martin asked for dealing with more advanced topics like thresholds and dynamic instance creation. So we will do that in this tutorial. We will start with a specification from tutorial 11 where a number of candidates are interviewed. You can find the specification in the supplementary material below. So in our scenario today, we will start with three candidates initially and we start interviewing the first one. And while we are doing that, there is another candidate that comes up and we want to add this candidate dynamically. But we have also set a threshold to three. That is when we have reached three interviews we will stop the interviewing and for that we will need thresholds and dynamic instance creation. So let's go to the computer! So now we have our editor open with a specification from the supplementary material and we will select the multiple instance task "Interview candidates" and on the left hand side you can see the multiple instance attributes here.

So we will edit those. We have the minimum exactly one. We leave that. The maximum, we put it to no limit and the threshold, we put it to three. And then we allow dynamic instance creation. Okay, and with these settings, we will execute the workflow now. So here we are in the control center with the user that is administrator and ordinary user at the same time. We go to the cases and we select tutorial 11 here and launch a new case: case id 10. And then we edit the candidate list and we can directly start the work item for our user.

And the first work item is "Edit candidate list". So we will fill in three people. These are the initial candidates we have on our list. Complete that. Now we have "Interview candidates". The first work item is started here and the others will appear as soon as we start this one. Sorry, it's not started it is unoffered now. So we will start this work item and then we can see that two new work items appear here and the one is worklisted. So we start the other ones as well.

And then we have three work items in our list. And let's say we start the interview with the third candidate. And we can say this is a good candidate. And now we have a fourth candidate coming up that is not on our list yet. So this is dynamic instance creation. So we have a button here: new instance. And we fill in an empty XML here in order to start this. And now suppose we do the interview with this new candidate. So this is the fourth one. And now we have two interviews left and we do one more.

Now we have three interviews and remember: the threshold was three. So what we have now is, we have check candidate list. And we have the results here. So the fourth interview is not necessary anymore and we're done. Dynamic instance creation is perhaps one of the rarer patterns. You may have noted that creating a dynamic instance by entering XML is nothing that we would like the end user to do. And then thresholds are a little like cancellation regions in YAWL. I hope that Martin's questions is answered now. See you next time!

YAWL BPMS Tutorial 23

YAWL BPMS Tutorial 23 ahense Sun, 10/18/2020 - 16:34

This is a short introduction on process mining using the Business Process Management System YAWL. YAWL can write its logs in XES format. XES is an IEEE standard for process logs.

There is a book on process mining by Wil van der Aalst if you want to read more.


Hello everyone! Welcome to another YAWL tutorial! In the last three tutorials of the series of 25 tutorials, we will talk about process mining. There is a very close relationship between YAWL and process mining as you will see. So let's first recap what we've seen so far. So let's assume that we have our world.

Our world of processes people organizations and so on. So what we did so far was that we had modeled business processes. And in modeling business processes we came up with these YAWL diagrams as some kind of graphical depiction of our process. And then we added to the so-called control flow view some more aspects like the data perspective and the resource perspective. And when we had all that, we had a YAWL specification and the YAWL specification allowed us to generate an IT-system with which we could execute the process. And here we have the YAWL engine.

Probably, some other software around it to make it work to embed it into something. And then this IT system directly supported our business process. And this is something like a closed circle. So if we have changes in the world, which appear quite frequently, we create a new process model. We adapt the process model. We regenerate the new process that is then installed on the engine which then supports the world. And so we have the possibility of flexibly improve and adapt our processes.

So now what is process mining? Every it system generates logs in one form or another. So here we have our process logs. And the system produces these logs as it is running - either in a text file or in a database - in whatever format. The advantage in using YAWL here as our IT system is that YAWL can export directly a standard format for process mining which is called eXtensible Event Stream, XES for short. And we will talk about that in the next video. And then, if we have the process logs then we have process mining.

It's a little like data mining but specialized for processes. And we can for example discover process models just by looking at the logs without looking at the original specification. Or we can do conformance checking looking at if the logs conform to our process model. We can detect key performance indicators for our processes like average execution time or throughput etc. So we can use process mining to analyze and improve our processes. And we get another loop if you like here, where we have process improvement and very flexible adaptation of our processes and then of our IT systems. And this is the topic of the next videos. So stay tuned!

YAWL BPMS Tutorial 24

YAWL BPMS Tutorial 24 ahense Mon, 10/19/2020 - 19:42

In this video we introduce the IEEE standard for process logs called EXtensible Event Streams (XES). XES files can be directly exported from YAWL. Whereas with other IT systems it may take several days to get an activity file for process mining, in YAWL this is a matter of minutes. The zip file below contains the YAWL specification to create your own XES file and the XES file that we have produced for this tutorial.


Welcome to our second tutorial on process mining with YAWL! So in the last tutorial, we covered some basics of process mining and this time, we are talking about XES. XES stands for eXtensible Event Stream and is an IEEE standard for process mining. XES is based on XML. So what are process logs? In XES a process log consists of several traces. And a trace corresponds to a case in YAWL. So in a log there are several cases that are protocolled. Then in each trace, we have events. And each event corresponds to a work item that has been executed. And there can be several events for each of the work items. And in the graphics behind me you can see the schema of XES. And you can see the logs, the traces, and the events. And you can also see the attributes and also that XES is in fact extensible. On the next slide you can see the states that can be logged in the XES standard. So you can see something is started, something is running, or suspended. Something can successfully complete or can fail. All these things are possible. On the next slide you can see the YAWL system with its different components. The engine, the resource service, and the worklet service, and many other components. What you can also see is that there are several places where YAWL is logging. So first the engine is producing some log information but for example, the engine doesn't know about the resources. All the knowledge about the resources are in the resource service. So if we want to see who has executed a work item, we have to look in the log of the resource service. And last but not least, the worklet service has its own log again. And so for producing an XES file with all the log information, there is some logic in YAWL going on that is collecting all of these logs of these three sources and puts them all into one XES file. On the next slide you can see the life cycle of a your work item. Work items in YAWL are first offered, then they can be allocated, then started, and finally completed.

And this life cycle of the YAWL work item closely corresponds to what we have in the XES state chart that I showed you before. And this is not a coincidence. So when we do process mining with YAWL XES files, we can discover lots of information about when did work items start, when were they completed, and we can for example measure the time it has taken for someone to fill in a form. And of course, we can also concentrate on certain events like fail events or complete events and ignore the difference between start and completion. So there are many possibilities here. So in order to demonstrate process mining with YAWL, we will take a specification from tutorial 12, where it was about developing or buying software. And this specification is the basis for our process log now. In the matrix behind me, you can see the eight cases that we have produced for demonstrating process mining with YAWL. So you can see that there are differences between make or buy, develop or procure software. There are also differences in the budget and also if there has been an approval or not. And all these cases are listed here. And these are the cases that go into our log file at the end. After we have finished all of our cases, we go to the control center as the YAWL administrator and select the specification and then click download log. And the result of this is an XES file. And you can find the XES file in the supplementary material. Feel free to also produce your own XES file and do experiments with that. So either with your XES file or with the one from the supplementary material, we will go to the next video and I'll explain you how to handle this XES file in ProM. See you then!

YAWL BPMS Tutorial 25

YAWL BPMS Tutorial 25 ahense Mon, 10/19/2020 - 20:10

This tutorial shows how to filter an XES process log from YAWL in the process mining tool ProM. After filtering we look at the Inductive Miner, the Data Aware Heuristic Miner, and the Fuzzy Miner and compare the results with the original YAWL specification. Here are the links referred to in the video:

Download link for ProM

MOOC on ProM by Joos Buijs

The zip file below contains the XES logs before and after filtering.


Welcome to our third tutorial on process mining with YAWL! So in the last video we have produced the XES file. And in this video, I will show you how to analyze this XES file with a process mining tool. And we are going to take ProM, an open-source tool by the University of Eindhoven, for this purpose. And I will put the download link in the supplementary material below.

There are also other tools than ProM and we have been using Disco and Celonis in the past but ProM is of course the easiest to get and maybe not the easiest to handle. Teaching you how to install and use ProM would be beyond this tutorial series but there is excellent material on the download page. Also there is a ProM user group and there is a MOOC by Joos Buijs which is excellent and I will also put the link in the supplementary material. So we will use the XES file from the last tutorial. And we will use ProM to work on it. So let's go! We have our XES file from the YAWL system open here. So as you can see on the top level, we have the element log. So in XES everything is a log. And a log consists of several traces. So we have the trace element here and the value 1 is the case id in YAWL. And then for this trace, we have events: event 1, event 2, and so on and so forth. So we will now load this file into ProM and filter it and do some analysis on it.

So I will start ProM here. So this is ProM when it's opened up. We are going to import our tutorial XES file. And here we will take the naive version of it because some of the other versions just don't work. Now we have our log file here and we are going to filter it in order to apply functions. We have to press the play button here and then we will filter it with something that is called heuristic filter log using simple heuristics. That's the one we need: select and start.

Now we get a number of different events or event classes here. Schedule, start, complete, and so on. And we are only interested in complete events because we don't want to look at how long someone looked at a form or whatever. We just want to see what happened in the process. So what we will do is, we will put these all to remove accept complete that's the one we keep. And then we have the start events, we press next the end events, we press next and the event filter. "e put it to 100 percent we want all the events finished. The result is a file where we have one process, eight cases, and 50 events. We still have some duplicate complete events. That is always like this in YAWL. So we want to filter those out. So we need another filter. So we go back to our lists of elements. We go to the first one and we apply another filter here. And this one is called: "filter on event attributes". "Filter log on event attribute values", that's the one we choose.

And here we have some tabs and we just go to org resource and the only org resource we have is always the same user. And so we can choose this user and remove everything if this value is not provided and that will eliminate our duplicate complete events. And we press finish. So now we have one process, eight cases, and 25 events. And now we will look at our result. So the first one will be to look at the trace variants. We look at the trace variance and you can see now that we have several variants that we can explore here. The next thing is, we go to the inductive visual miner.

And what we can see now is what has been inferred from the log. So we can see that we have eight cases here and these yellow bubbles are actually the cases that go through this diagram. The plus sign is a parallel split and then we have four cases where cancel requirement was executed. This corresponds to the list we have seen. We have four cases with "Define software development project" and four cases with "Prepare software procurement". Then we have two cases where the project has effectively been started. The other two are the ones that have been cancelled here. And then we have two cases with "Approve proposition", two cases without approval because they have been below the threshold and one case with "Prepare purchase order" from this filtered log. To start with the data aware heuristic miner. So we have to put a different selection here and we enter data and we say we take the data causal net. And down here the data aware configuration we select the estimated cost.

And now we can see that we have "Formulate requirement complete", "Prepare software procurement complete" and we can select these bubbles here below and then we can see for example here we do "Cancel requirement complete" if the estimated cost is less or equal to 95,000.

And we go to "Approve proposition complete" when the estimated cost is greater than 95,000. And this is not the exact value of our selection rule which was at hundred thousand but this is what has been inferred from the log because the original specification is unknown of course here. And in the same way, after defining software development project we have estimated cost greater 80,000 and the other path is estimated cost less or equal to 80,000. So this is another way of analyzing our log.

And last but not least, I want to show you the fuzzy miner. So again, we put in fuzzy here and we accept all the default parameters. And now we can see "Formulate requirement complete", "Defined software development complete", and so on. So this very much corresponds to our original YAWL model and of course: anything that hasn't been used from the original net can also not be in our log. And in this model we have here and the fuzzy model for example says that after "Prepare software procurement", "Approve proposition" then we have "Prepare purchase order". 25 is a good number to stop. So this concludes our regular series on YAWL tutorials. We haven't covered everything. So if you have any questions or you want tutorials on specific topics, please do not hesitate to ask us. Bye bye!

Beginner track

Beginner track robert Sat, 11/08/2014 - 21:37


Installation fmannhardt Tue, 11/29/2011 - 12:50

Use YAWL in 5 Steps

  • Prerequisite:
  • Download the most recent YAWL(currently v4.2) suiting your operating system at  GitHub.
    • YAWL is ready out of the box, so that's the edition to choose for evaluation purpose.
    • YAWL Enterprise should be used in a production enviroment, but needs more configuration and contains no additional features.
  • Install YAWL using the guided installer (Windows), during the installation you will be asked your Java installation path.
    • Afterwards there should be a folder "YAWL vX.X.XX" in your program menu (Windows).
  • Start the YAWL Engine and the YAWL Editor.
    • On Windows you may need to adapt your firewall settings.
    • As YAWL is now running on Port 8080 on your local machine.
  • Examine for example the "/misc/examples/SimpleMakeTripProcess.yawl" specification in the YAWL editor
  • Now point your browser to the url "http://localhost:8080/resourceService/" and login using the credentials "admin / YAWL"
    • Congratulations! Your YAWL system is running.
    • If you would like to evaluate some of it's features, please head on to the next tutorial "Run a sample workflow"
  • If there are any issues, please consult the YAWL manual chapter 2 for more information.


Sat, 03/21/2015 - 23:47

I am trying to install YAWL 3.0 (Mac OSX Maverick). I receive the message:
- Please stop the running YAWL engine (or nay Tomcat instance).
I am not aware having any engine running. This message puzzle me. How can I get thru the install?

Run a sample workflow

Run a sample workflow robert Sat, 12/27/2014 - 17:25

This Tutorial will guide you through the process of running the short YAWL example workflow "Simple Make Trip Process". With the "Orderfulfillment Workflow" there is a more sophisticated example included in each YAWL installation (Path: /examples/orderfulfillment). It is assumed that you have installed YAWL successfully and the Control Center is running.

  1. Login to the Control Center (if the YAWL engine is locally installed - http://localhost:8080/resourceService) with the administrative account (Credentials: admin/YAWL)
  2. Select the tab "Cases"
    • Select and upload the "Simple Make Trip Process" specification (Path: /examples/SimpleMakeTripProcess.yawl)
    • The  specification should appear in the "Loaded Specifications" box as on the following screenshot:
    • Click "Launch Case" to start the workflow.
  3. Select the tab "Admin Queues"
    • Because there is no organisational data loaded in YAWL the first task "register" appears as a work item in the "Unoffered" queue. These work items are net yet assigned to any participant.
    • The administrative user account can not be used to actually perform work. Therefore we need to create at least one participant, who performs the work. 
  4. Select the tab "Users"
    • Create a new participant by clicking on the "New" button.
    • Fill in details as in the following screenshot (Password: test)
    • Click on the "Add" button to save the participant. There will be a warning message about missing role, position and capability that can be safely ignored.
  5. Return to tab "Admin Queues"
    • Select the work item "register" and click on the "Offer" button.
    • Now a list containing the just created user John Smith will appear. Select John Smith and proceed to put this work item into his offered queue.
  6. Logout the administrative user and Login as Joe Smith (Credentials: joe/test)
    • The work item "register" should appear in Joes "Offered" work queue.
    • Click the "Accept & Start" button to immediately move the work item to the "Started" work queue, skipping the "Allocated" work queue. You may also click "Accept" to move the work item to the "Allocated" work queue and perform your work later on.
    • If you click on the "View/Edit" button a page with the work item appears.
    • Fill out the form as you like and click the "Complete" button to check-in the work item back into the YAWL Engine. Due to the AND-Split of the "Register" task the YAWL Engine now instanciates three tasks: "book flight", "book car", "book hotel"
  7. Logout Joe Smith and login as the administrative user
  • All three work items should be in the "Unoffered" work queue. Now you should be able to complete the whole workflow on your own. Simply assign all work items to Joe Smith, fill out the forms and complete them. Afterwards look for the "pay" work item in the "Unoffered" admins queue and repeat the steps. If the "Running Cases" box on the tab "Cases" is empty you have just completed your first YAWL workflow.

Install prerequisites under Windows 10

Install prerequisites under Windows 10 ahense Sat, 05/02/2020 - 16:38

Go to this site


and choose OpenJDK 11 LTS and HotSpot JVM.

Execute the .msi installer and you are done. To check if it worked open a command prompt and enter

java -version

The result should be

openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)
openjdk.png (13.39 KB)

Install YAWL 4.3 in Windows 10

Install YAWL 4.3 in Windows 10 ahense Sat, 05/02/2020 - 17:05

YAWL can be installed under Windows, Mac, and Linux. For YAWL 4.3 you need JAVA 8 or newer. If you don't have a JAVA installation yet look at this tutorial. 

  1. Go to the YAWL foundation web site.
  2. Run the YAWL installer and follow the instructions.
  3. Open the YAWL control panel.
  4. Click the update functionality.

Then the engine will start. You can check whether your installation was successful by clicking on the third button from the left ("Open the YAWL Logon Page"). A window should appear that shows you a login. There you can log in with user name admin and password YAWL.

Automated testing with Selenium

Automated testing with Selenium mRoskosch Mon, 07/01/2013 - 23:33

Testing workflows can be a tiresome task, but automating test cases can save time and make the process easier. Martin Giesler, a student of the Bonn-Rhein-Sieg University, has created an automated test suite for the "orderfullfillment" example using Selenium. This tutorial will show how to run the test suite and what it's prerequisites are.

The Selenium IDE can be downloaded from the homepage. Note that you need version 2.2 to run with Firefox 22. Other browser can be used, but there drivers are not supported be the selenium hq. Attached to this tutorial are the files needed for selenium to execute the workflow.

Next the orderfullfillment example needs to be loaded to the YAWL Engine. The workflow and oranisational data can be found in the YAWL Installation folder in the subfolder "examples\orderfulfillment". There you should find the "orderfulfillment_customforms.yawl" workflow specification and "orderfulfillment.ybkp", which should both be uploaded in the YAWL resource service.

Now that all preparations are complete, the test suite can be run. To open Selenium, you need to open the Firefox browser that has the Selenium add-on installed and start it from the "extras" or "tools" menu:

The Selenium window will open and after loading the "TestSuite" file in the subfolder "Order Fulfillment TestSuite" of the attached archive, the window will look something like this:

Below the Base URL is a slider, that lets you specify the speed at which the test case should be executed. Keep in mind, that a too high value can cause problems in execution. Next to the slider are buttons to start the test suite. If YAWL is running, clicking the button "Play entire test suite" should run the scripts and start the test suite. During execution serveral users will log in and complete the tasks assigned to them until the workflow is completed.


These test suites are important for YAWL developers as well, since adding new features can add bugs and break existing functions. If you have test suites for other example workflows, the YAWL user group would be glad to publish them for other users and doing that, make developing for YAWL easier.

Please note:
This tutorial suppose that the YAWL-Server is in operation on the same machine as your Selenium-IDE.

SeleniumTest.zip (18.2 KB)

How do you upload a ybkp file to the resourceService?

I got the message "Only yawl files with an extension of '.yawl' or '.xml' may be uploaded." after trying.

I give the answer to myself. The ybkp file must be imported as orgData.

Important for testers: This Selenium Script does not work with YAWL3 due to changes of the HTML-Element id's

Selenium test for "Timeout tasks manual"

Selenium test for "Timeout tasks manual" k.schildt Sat, 01/25/2014 - 16:23

If you haven't install Selenium IDE, go to the Selenium tutorial please.
Download the data "TestSuites TimeoutTasks manual".
Please check that you have uploaded the file "TimerManualTimeout" in the control
center and check that you imported the OrgData successful in the control center.

If you haven't the file "TimerManualTimeout.yawl" or the File of the OrgData (YAWLOrgDataExport_o.ybkp), please download these from the tutorial
"Using a timer for the timeout of manual tasks".
As next check , that the roles were distributed to the right members as it is written in the table.
After that you must log out of the control center. The test starts with the login screen.

TestSuite TimeoutTasks manual part1: That test suite is for a normal run of the
workflow without a timeout failure.
Load the data " TestSuite TimeoutTasks manual part1" of the folder " Part1"
in the Selenium tool and start the TestSuite.

TestSuite TimeoutTasks manual part2: The secound test suite should represent a task
timeout for the workflow.
For that you load the data " TestSuite TimeoutTasks manual part2" of the folder "Part2 "
in Selenium.
As next you must toogle a breakpoint in the task " Comment on health" at
the first command ( screenshot) and then go to the options tab and set the time for
default time out on 5000ms.


If you start the TestSuite , the run will be stop at the break point. Wait 2 min (timeout
time) and then click on the "pause/resume" - button. The run will go on now.
The three "comment"- tasks will be fail, but the "decide"-task will be run successful.

How to reset YAWL to its original state?

How to reset YAWL to its original state? fmannhardt Fri, 01/06/2012 - 16:25

Resetting YAWL may be useful, if you want to delete all users from the resource service at once. Also if you've been hit by a bug inside YAWL that may be related to a specification you've uploaded recently. As YAWL stores everything inside the connected database, resetting YAWL just means to restore the initial database. If you've configured YAWL to work with another database than the file based Derby database (Default with YAWL4Study), you should simply delete the contents of your database. If you are using the default Derby database do the following:

  1. Stop YAWL
  2. Remove the file "/engine/apache-tomcat-7.0.55/databases/yawldb.h2.db" (Warning: You will lose all data inside YAWL)
  3. Start YAWL



For YAWL versions prior to 2.3.5

  1. Stop YAWL
  2. Remove the directory "/engine/databases/yawldb" (Warning: You will lose all data inside YAWL)
  3. Copy the directory "/misc/yawldb" to "/engine/databases/yawldb"
  4. Start YAWL

In my Version there is no 'databases/yawldb' and also no '/misc/yawldb'.
Even deleting the whole DB-folder does not lead to success.
Is there another way then reinstalling?

Build a Workflow using Deferred Allocation

Build a Workflow using Deferred Allocation ahense Sun, 11/10/2013 - 15:54

We want to use deferred allocation. An insurance claim will be forwarded to a specialist depending on its content. There are specialists for health, house, car and life insurance. The complete workflow is contained in file DeferredAllocation.yawl. We will outline the steps that are necessary to create this workflow.


The first step is to set up an organisation

First name

Last name
















health specialist





house specialist





car specialist





life specialist



You can either enter this organisation using the control center or you can import the file YAWLOrgDataExport.ybkp.


Instruction to import organisation data:

Please open the control center and log in as "admin" :


XSD Types


Instruction to import data type definitons:


In order to have the specialist roles in a drop down list in a task, we define the following type in the data type definitions of the net:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:simpleType name="SpecialistRolesType">

<xs:restriction base="xs:string">

<xs:enumeration value="health specialist" />

<xs:enumeration value="house specialist" />

<xs:enumeration value="car specialist" />

<xs:enumeration value="life specialist" />





Net variables

We define the following variables in our top level net:

Variable name







A text explaining the claim.




True if the claim is accepted – false otherwise.




The type for the drop down list from the previous section.




A „type conversion“ of variable role, because variables for deferred allocation must be of type string.


Two nets for the control flow

The first plan was to create one simple net for this example.

However, there is a problem: the YAWL User Manual says:

„Additionally, in the Net Parameters panel you may nominate one or more net-level variables that at runtime will contain a value of the userid of a participant or the name of a role (that is, deferred allocation). For a variable to appear in the Net Parameters panel, it must be of type ‘string’ and usage ‘Input & Output’ or ‘Input Only’.“

This means that we want to use variable roleString for deferred allocation we have to change its usage to „input“. The consequence is that we have to enter some value each time we start the workflow. (We do not know the reason for this restriction)

As a workaround we put the deferred allocation task „Choose specialist“ in a subnet and get the following two nets:

as top level containing

We define the following variables in our subnet:


Variable name






Input Only




Input & Output




Input & Output




Input & Output

This variable can now be used for deferred allocation in „Evaluate the claim“.

We have defined the net variables first in order to use „Decompose to direct data transfer“ as much as possible. Most of the mappings are standard an can be examined by loading DeferredAllocation.yawl into the YAWL editor.

One thing worth mentioning is the task „Choose specialist“, where we want to have our drop down list. The variable containing the drop down list is called „role“. The result of the user selection must be in variable „roleString“. The solution is an output mapping of „role“ to „roleString“ and to hide the task variable „roleString“ using extended attributes.


Changing the look of dynamic forms

Changing the look of dynamic forms k.schildt Fri, 05/23/2014 - 20:32

If you have ever found yourself in a position to present some YAWL workflows, but would like to use something looking a bit moe modern, then this tutorial might be something for you.

I am going to present a new stylesheet for YAWL dynamic forms, giving them a more modern feeling using some CSS techinques. Of course this means some older browsers will not be able to display these new features, but for presentation purposes, it can give you an advantage to style the forms in the corporate design or colors of the company. To show the difference between the two styles, a side by side comparison is the best way, so now the results of the face-lift:

What I have done is adding some elements, that you surely have already seen on other web sites. Here is a list of the changes:

  • the form's edges have been smoothed
  • shadows have been added to the text fields
  • fields in focus now glow in a light blue
  • buttons now have a blue color and have an hover-over effect
  • invalid fields glow red instead of the field being filled red
  • other colors have been removed to get a cleaner look
  • required fields are now marked with a "*", instead of having a yellow background


Attached to this tutorial is the stylesheet.css file and the star.png used for the required fields. Both files have to be copied to the sub folder "resource" of the "resourceService" folder in the webapps dircetory of your YAWL installation. To use the new .css file you may need to reload the resource service site without using the cache, because some browsers don't load the css file everytime a website is called and use the cached file instead. In the Firefox browser this is done by the keybord shortcut [Ctrl] + [Shift] +[r].

The original CSS file is already well structured, so the classes used by the dynamic form generator are marked. Here is a list of classes that I have modified to achieve the result above:

  • dynformOuterPanel - the outer panel surrounding the entire form
  • dynformSubPanel - panel that is used to group together fields
  • dynformSubPanelAlt - panel that is used alternately with dynformSubPanel to create a visual distinction
  • dynFormButton - used for the three buttons below the form
  • dynformOccursButton - used for the buttons to increase or decrease number of elements using maxOccurs
  • dynformInput - text field for a not mandatory field
  • dynformInputRequired - text field for a mandatoy field
  • dynformInputError - fields that have invalid values

With CSS you can also use effects like the hover effect on the buttons or the focus effect on the fields. Since some elements could not be changed by just editing these classes, the specifity had to be increased for the date field to take effect:

td span .TxtFld{ ... }

and the checkbox would have received the style of the other text fields, which have to be overwritten by this rule:

dynformInput.CbSpn{ ... }

CSS allows a lot of customization itself and interesting effects can be made with animations. It would be interesting to receive styles that other users have made and give YAWL users a range of styles to choose from.

stylesheet.css (16.69 KB)
star.png (250 bytes)

Use a timer for delaying automated tasks

Use a timer for delaying automated tasks ahense Tue, 12/03/2013 - 10:46

This example uses shell execution and is written for a Linux operating system. The YAWL workflow is here: TimerAutomatedDelay.yawl

We want to build a simple workflow that uses a delay for automated tasks as it is described in the YAWL User Manual. We create a new net that uses the shell execution codelet to create files in a temporary directory. The path to the temporary directory is stored in a net variable named tmpDir. In our case the path is /tmp/.


We create the Delay 10 task with tmpDir as input variable. Then we go to task decomposition and mark the task as automated. We select the ShellExecution Codelet. Note that after this step the variables command and result are automatically inserted into the task. We now populate the task variable command with
        touch {/TimerAutomatedDelay/tmpDir/text()}/Delay10.

Next we set the task timer. According to the YAWL User Manual we can express 10 seconds like this: PT10S.

We set up the tasks Delay 20 and Delay 30 in an analogous way.

Go to the /tmp directory. After starting this workflow you should see files called Delay10, Delay20 and Delay30 appear after 10, 20, and 30 seconds.


(Notice: This tutorial is based on  YAWL version 2.2.x)

Using a timer for the timeout of manual tasks

Using a timer for the timeout of manual tasks ahense Wed, 12/04/2013 - 10:10

A common problem is the coordination of several parties. We want to give a number of participants the chance to comment on something but we do not want to wait indefinitely.
YAWL timer tasks can help here.

For the following workflow, we will be using the same ybkp file as here. The YAWL file is here.

Someone submits a claim and several specialists comment on it before a decision is prepared. The specialists only have a limited time to comment.

We start a new net with string type net variables claim, healthComment, houseComment, and lifeComment. We add a boolean type net variable accept. The task Submit claim takes claim as input and output variable and is offered to the role claimer. The task Comment on health has the claim as input variable and  healthComment as output variable. It is offerd to the health specialist. It times out two minutes after enablement (PT2M).

The other two commenting tasks are similar.

The task Decide takes the claim and the comments as input and accept as input and output variable. This task is offered to the role allocator.


Sun, 12/08/2013 - 14:45


I have a problem with the "Submit claim" task,  I can offer only one submit claim task to one specialist and not to all three. And so I can't reach the task "Decide" .


I hope somebody can help me.

Kai Schildt


Documents in Workflows

Documents in Workflows ahense Wed, 09/24/2014 - 09:29

Document handling in workflows is an important topic. Uploading and downloading documents - possibly from a document management system - is at the core of administrative activities. Fortunately, YAWL has a built-in datatype called YDocumentType for doing exactly that. So let us follow the section on document type of the YAWL user manual to see how it works.

We start the YAWL engine, open the YAWL editor, and add two tasks.


We click on the first task and create a new decomposition called "Upload".


We create a data variable in our net called "document" of type "YDocumentType".


We now edit the data variables of task "Upload", pull the variable "document" from the net variables down to the decomposition variables. We should change the scope to "Output".

We proceed in a similar fashion with task download. The only difference being that the scope of the variable is now "Input".

That should be all. Save the file as document.yawl. We can now upload it to the running YAWL engine with the "Upload this specification to the YAWL engine"-button (7th from the left). When we start the workflow we get the following work item.

Pressing the up-arrow will give us a browse-upload dialog. After choosing a file we complete the activity and proceed to the download activity.

If you don't want to build the workflow yourself and just try the functionality the result of this tutorial is attached here.


document.yawl (6.02 KB)


Wed, 05/27/2015 - 16:58

How to define custom user type in YAWL editor 3.01 based on YDocumentType. If I specify YDocumentType for element of complex type, the Yawl editor return the error:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;
<xs:complexType name="myType">
<xs:element name="myElelment" type="YDocumentType"></xs:element>

Error: 5:54: src-resolve: Cannot resolve the name 'YDocumentType' to a(n) 'type definition' component.

I new define YDocumentType, the Yawl Editor return next error
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;
<xs:complexType name="YDocumentType">
<xs:element name="id" type="xs:long" minOccurs="0"/>
<xs:element name="name" type="xs:string"/>

Error 2:22: [YDocumentType] is a reserved type name.

Michael Adams

Mon, 05/08/2017 - 05:11

YDocumentType is a YAWL internal type specifically designed and used to support document passing and storage within a YAWL workflow instance. As such, it cannot be redeclared, extended, restricted or used as a type for a member element of a user-defined complex type.

Configure YAWL to use database XY

Configure YAWL to use database XY fmannhardt Tue, 02/21/2012 - 18:50


As YAWL uses hibernate as persistence layer it supports every database that Hibernate supports. (see here) All you need to do is to configure the database in the hibernate.properties file of the three web applications "resourceService", "yawl" and "workletService". This is briefly explained in the YAWL user manual section 2.4.4. In the following sections we provide detailed information to get YAWL working with different database management systems.


Regardless the database you'd like to use, there is one (since YAWL 3) configuration file you have to adjust:

  • \engine\apache-tomcat-x.x.xx\yawllib\hibernate.properties

Apache Derby

The YAWL4Study edition is pre-configured to use the embedded database Apache Derby. Although this database provides full support for YAWL it is generally not recommended to be used in a production system. For development or evaluation use it is sufficient. The database is located in the directory \engine\databases of your YAWL4Study installation. Details on building the correct connection url for Apache Derby can be found in the Derby documentation.


## Apache Derby


PostgreSQL is the default database of the YAWL enterprise edition. Therefore the easiest way to use PostgreSQL is to install the enterprise edition of YAWL and you will be asked for details about your PostgreSQL server during installation. But if you already installed YAWL4Study, you have to adjust your hibernate.properties to the following configuration. Details on building the correct connection url for PostgreSQL can be found in the PostgreSQL documentation.


## PostgreSQL
hibernate.dialect org.hibernate.dialect.PostgreSQLDialect
hibernate.connection.driver_class org.postgresql.Driver
hibernate.connection.url jdbc:postgresql:yawl
hibernate.connection.username yawl
hibernate.connection.password yawl


To use MySQL you should install the YAWL enterprise edition, as MySQL is a configuration option during the installation. If you'd like to switch to MySQL later on, then adjust the hibernate.properties files as follows and add the correct MySQL JDBC Driver to the lib directory of YAWLs Apache Tomcat. Details on building the correct connection url for MySQL can be found in the MySQL documentation. You may want to choose the MySQL5InnoDBDialect instead of the usual MySQlDialect if you want YAWL to generate InnoDB tables. (Read more about InnoDB)

MySQL JDBC Driver:

  1. Download JDBC Driver from http://dev.mysql.com/downloads/connector/j/
  2. Copy mysql-connector-java-5.x.xx-bin.jar to \engine\apache-tomcat-6.0.18\lib


## MySQL
#hibernate.dialect org.hibernate.dialect.MySQL5InnoDBDialect
hibernate.dialect org.hibernate.dialect.MySQLDialect
hibernate.connection.driver_class com.mysql.jdbc.Driver
hibernate.connection.url jdbc:mysql:///yawl
hibernate.connection.username root
hibernate.connection.password root

MSSQL (SQL Server 2005/2008)

To use MSSQL you need to adjust the hibernate.properties files as follow and add the correct MSSQL JDBC Driver to the lib directory of YAWLs Apache Tomcat. Please note, the Microsoft JDBC Driver is not Open Source and there are other implementations available. (For Example jDTS) Details on building the correct connection url for MSSQL can be found in the MSSQL documentation.


  1. Download JDBC Driver from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21599
  2. Copy sqljdbc4.jar to \engine\apache-tomcat-6.0.18\lib


## MS SQL Server
hibernate.connection.driver_class com.microsoft.sqlserver.jdbc.SQLServerDriver
hibernate.connection.url jdbc:sqlserver://localhost\SQLEXPRESS;databaseName=yawl;user=yawl;password=yawl;SelectMethod=cursor
hibernate.dialect org.hibernate.dialect.SQLServerDialect
hibernate.connection.username yawl
hibernate.connection.password yawl

I am using YAWL4Study 2.3 on an Ubuntu Linux.

I set up a postgres database with a database called 'yawl' and a user 'yawl' with password 'yawl' who owns the yawl database and has administration rights.

Then I modified the three hibernate properties files like this:

## PostgreSQL
hibernate.dialect org.hibernate.dialect.PostgreSQLDialect
hibernate.connection.driver_class org.postgresql.Driver
hibernate.connection.url jdbc:postgresql:yawl
hibernate.connection.username yawl
hibernate.connection.password yawl

## H2


After restarting the engine, YAWL keeps using the file-based database and does not create any tables in postgres.

What am I missing here?

I tried to run with all 'hibernate.properties' files modified like in your configuration. YAWL creates the tables in PostgreSQL automatically and is running fine. Can you check the console output of YAWL (or log file if used as service) for lines like the following and post them.

- HHH000130: Instantiating explicit connection provider: org.hibernate.service.j
- HHH010002: C3P0 using driver: org.postgresql.Driver at URL: jdbc:postgresql:ya
- HHH000046: Connection properties: {user=yawl, password=****}
- HHH000006: Autocommit mode: false
- Initializing c3p0 pool... com.mchange.v2.c3p0.PoolBackedDataSource@518f739a [
connectionPoolDataSource -> com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@

Thank you. I have tried with several fresh installations of YAWL 2.3: it keeps using the file for persistence and ignores postgres. Even renaming the three hibernate.property files didn't work.

I have tried it with YAWL 2.2: it used postgres right away after changing the hibernate.property files accordingly.

I have looked at all the files in the logs directory of tomcat but there are no lines like the ones you posted. The catalina.out looks like this:

Dec 04, 2012 3:34:22 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Dec 04, 2012 3:34:22 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Dec 04, 2012 3:34:22 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 449 ms
Dec 04, 2012 3:34:22 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Dec 04, 2012 3:34:22 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
Dec 04, 2012 3:34:22 PM org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for /javax/servlet/resources/web-app_2_5.xsd
Dec 04, 2012 3:34:22 PM org.apache.catalina.startup.DigesterFactory register
WARNING: Could not get url for /javax/servlet/resources/web-app_2_5.xsd
log4j:WARN No appenders could be found for logger (com.sun.faces.config.ConfigureListener).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
ContextListener: attributeAdded('com.sun.faces.ApplicationAssociate', 'com.sun.faces.application.ApplicationAssociate@4faa65fe')
Dec 04, 2012 3:34:30 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Dec 04, 2012 3:34:30 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /
Dec 04, 2012 3:34:30 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/21  config=null
Dec 04, 2012 3:34:30 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 8392 ms

Maybe the log4j warnings give some hints?

The log4j warnings are not about the issue. Unfortunately I can't test with Linux at the moment. Recheck if there is a file like "postgresql-9.0-801.jdbc4.jar" in the "engine/apache-tomcat-6.0.18/lib" of YAWL.

Please attach all log files (I just enabled "attaching files in comments"), that includes log files in "engine/apache-tomcat-6.0.18/bin" and "engine/apache-tomcat-6.0.18/logs". Probably it is best to upload  the whole, zipped, YAWL directory and I will have a look.

Christoph Lehnert

Thu, 10/24/2013 - 17:54

I am also using YAWL4Study 2.3.5 on an Ubuntu Linux and faced the same problem.
After adjusting the configuration file \engine\apache-tomcat-6.0.18\webapps\documentStore\WEB-INF\classes\hibernate.properties as mentioned above everything worked fine for me.

matteo spiotta

Wed, 06/08/2016 - 10:19

I'm using YAWL 4 with MSSQL 2008. All work fine aside handling YDocument. Im using YAWL with the data store service. By default the yDoc column in the YDocument table is defined as varbinary(255).
It can be extended to 8000 (maximum size allowed by MSSQL) adapting the function fixH2BinarySize in DocumentSore.java to work also for MSSQL db.
To handle bigger file I had to modify the methods getDocument and PutDocument to store and retrive document directly in/from the filesystem.
Please contact me if you solved the same problem in other ways.

Using YAWL 3.0 Repositories

Using YAWL 3.0 Repositories ahense Fri, 10/03/2014 - 15:57

YAWL 3.0 has a new functionality for storing nets, extended attributes, and data types in repositories. In real life projects it is really important to reuse parts of workflow specifications. One example are extended attributes. The field name of a variable is its technical name by default. If we want to give it a nicer name including blanks or add text above, tooltips, etc. we can do that by giving the variable in a task extended attributes. If the variable appears in ten different places, in YAWL 2.3 we had to do the editing for the extended variables over and over again. This was not only time consuming but error prone. Now the repository concept in YAWL 3.0 tackles this issue. We will build a small workflow to see how it works.

The example is about applying for some post. We define the simple type FormOfEmploymentType as follows:

We define the following net variables:

Technical name Field name Type
postDesc Post description string
formEmpl Form of employment FormOfEmploymentType
stDate Start date date
avail Available boolean

The field name is not part of the net variable but will be entered as an extended attribute of the corresponding task variable. We do this now by defining task "Choose post":

For the variable postDesc we edit the extended attributes by clicking on (=)

Apart from the label, we check that it is a text area and enter some tooltip. We do something similar to the other task variables. We start the workflow to see if all works as expected:

That looks nice - also the tooltips work when we hover the mouse over the fields. Now we will save the extended attributes in the repository in order to reuse them in task "Check availability". We go back to the extended attributes of postDesc and store it in the repository:

We give it the name of the technical variable and put the same in the description.

Now we are ready to proceed to task "Check availability". We open it in the editor and pull the required variables inside and adjust their input/output behaviour as follows:

Next we pull the extended attributes for the variables we have already defined and define some for the variable "avail". We run the workflow to see if it works.

That concludes this short tutorial. The resulting workflow is attached. In the next tutorial we will see how we can import this workflow as a subnet to another workflow using repositories.



repository.yawl (9.4 KB)

Web Service Invoker

Web Service Invoker ahense Fri, 12/12/2014 - 13:28

We will see how the web service invoker service of YAWL can be used. We will create a workflow that invokes a publicly available web service.


The first thing to check is if the YAWL web service invoker is installed. In the YAWL control panel click on Updates. In the line yawlWSInvoker check the mark if it is not checked and click Update.

We create a new workflow and a task with a new decomposition called "Invoke WS". We choose the webServiceInvoker service as the custom service of this decompostion. The editor will then insert the following three task variables:

  • YawlWSInvokerWSDLLocation
  • YawlWSInvokerPortName
  • YawlWSInvokerOperationName

We create corresponding net variables and map them to the created task variables via an input mapping.

Next we look for a simple web service that is publicly available:


shows a web service that does calculations. We can use it to add two numbers x and y and get the result. We add the net variable x, y, and Result to the net and insert two tasks that do the input and output to the user. We initialise our net variables in order to access our web sevice like this:

That's all. Workflow is attached here.

WSInvoker.yawl (11.45 KB)

Note that all types used by the web service invoker must be simple types. This means that if you want to work with web services and use complex types you would have to call web services from codelets.

Using a timer for the timeout of manual tasks

Using a timer for the timeout of manual tasks robert Mon, 03/09/2015 - 17:32

A common problem is the coordination of several parties. We want to give a number of participants the chance to comment on something but we do not want to wait indefinitely.
YAWL timer tasks can help here.

For the following workflow, we will be using the ybkp-File which is attached.

Someone submits a claim and several specialists comment on it before a decision is prepared. The specialists only have a limited time to comment.

We start a new net with string type net variables claim, healthComment, houseComment, and lifeComment. We add a boolean type net variable accept. The task Submit claim takes claim as input and output variable and is offered to the role claimer. The task Comment on health has the claim as input variable and  healthComment as output variable. It is offerd to the health specialist. It times out two minutes after enablement (PT2M).

To set the timer first click on the task which should contain the timer. Now is on the left hand of the editor the properties table there you will find the entry "Timer". At the following picture you see how you set the timer


The other two commenting tasks are similar.

The task Decide takes the claim and the comments as input and accept as input and output variable. This task is offered to the role allocator.



Applying extended attributes to elements of complex types

Applying extended attributes to elements of complex types ahense Sat, 06/02/2018 - 16:33

In YAWL extended attributes cannot be applied directly to single elements of complex types. Let us assume that we want to display the "Comment" element of the "candidateType" as a text area.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:complexType name="candidateType">
      <xs:element name="Name" type="xs:string" />
      <xs:element name="Phone_number" type="xs:string" />
      <xs:element name="Comment" type="xs:string" />
  <xs:complexType name="candidatesType">
      <xs:element name="Candidate" type="candidateType" minOccurs="1" maxOccurs="unbounded" />

We will demonstrate a way to solve the problem in task "Interview_candidate" of the as in the next screenshot:


The input mapping of task variable "Name" is


Variables "Phone_number" and "Comment" are treated in a similar fashion. The output mapping of task variable "candidates_item" is


Task variable "candidates_item" is hidden using an extended attribute. Task variable "Comment" has an extended attribute "Text area". The specification is attached.


This solved my problem. Thanks a lot for the detailed tutorial!

Using Multiple Instance Tasks

Using Multiple Instance Tasks ahense Tue, 12/08/2015 - 13:28


This tutorial illustrates the use of multiple instance tasks.

Imagine a company in the process of selecting candidates for a position. There is a task of editing the list of promising candidates when the applications are evaluated. After this is finished, a task for each candidate of the list should be created. Each task should record the results of an interview by phone. These interview tasks should be offered to all staff in the HR department.

We define the following types for candidates in the specification's data definitions:

<xs:complexType name="candidateType">
      <xs:element name="Name" type="xs:string"/>
      <xs:element name="Phone_number" type="xs:string"/>
      <xs:element name="Comment" type="xs:string"/>
<xs:complexType name="candidatesType">
      <xs:element name="Candidate" type="candidateType" minOccurs="1" maxOccurs="unbounded"/>

We declare a net variable candidates:candidatesType. We use this variable as input/output in task "Edit candidate". We also pull this variable into the MI-task "Interview candidates". Then we click on the button "mark as MI". If all is correct the variable is renamed "candidates_item" (see screenshot).


If we now click on the input mapping we see that the following splitter query has been created:

for $s in /candidates/*
return <candidates_Item>{$s/*}</candidates_Item>

The joining query in the output mapping looks like this:

for $j in /Interview_candidates/Candidate
return $j

The last task is called "Check candidate list" and takes the net variable candidates as input.

Now let's not touch anything and see if it works. We upload the workflow, start a case and assign the first tasks to an existing participant.

The complete spec is attached below.

Dynamic Instance Creation

Next we will explore how dynamic instance creation works. For this purpose, we open the attached spec in the editor, select "Interview candidates" and set the checkmark in the MI-attributes as show here.

We save the spec, start a new workflow, and fill in two candidates.

Next we fill in the first interview form.

In our started queue, we click the button "New Instance".

The next dialoge comes up. We have to fill in the correct XML elements.

We can now edit the corresponding work item.


Advanced track

Advanced track robert Sat, 11/08/2014 - 21:38

Backup a running YAWL system

Backup a running YAWL system fmannhardt Thu, 04/19/2012 - 03:07


YAWL is build out of several independent web services. The two most important web services of a YAWL system are the YAWL Engine, responsible for actual workflow execution and state management, and the YAWL Resource Service, that manages information about the organisation (participants, roles, positions, etc.) and stores the work queues for each participant.

In almost every use case of a workflow management system like YAWL, it is crucial to retain the state of all managed workflows in any case. Usually there are multiple long-living workflows inside the system, loosing information about their state leads to a lot of work and may even result in restarting the case from scratch. Unfortunately every system may crash due to e.g. undiscovered errors, hardware failure or power outage. Then it should at least be possible to roll back the whole system to a consistent state some time before the crash occured.

Therefore a consistent backup of the complete YAWL system should always be kept at a safe place. Please note that this backup must contain the data of all YAWL web services (e.g. Engine and Resource Service) at the same state. For the scope of this article we assume those services all store their data to the same database, called YAWL database. Please note that within the standard configuration of YAWL this is the case.

Backup Database

Depending on your Database Management System (DBMS) there are different ways of doing a consistent backup of a running system. Depending on the available resource for each DBMS the process is described in detail or it is refered to external tutorials.

Backup Log-Files

YAWL offers an integrated logging feature via Log Predicates that can be assigned to tasks, conditions and (sub)-nets. If you don't use this feature, you may skip this section. But especially when a consistent state across distributed external systems is needed, YAWL logging could be very useful. (See below in section additional thoughts)

Additional thoughts

  • If a YAWL workflow interacts with external systems, such as the company’s web services or databases, the situation gets more complicated. Even though it is possible to create hourly backups of YAWLs internal state, rolling back to a consistent state across different distributed systems is far away from trivial. Maybe the logging feature of YAWL can be used as a starting point to recover those information in a case of failure.

  • There is already a PostgreSQL backup script available in the YAWL Wiki at code.google.com.

Backup Microsoft SQL Server

Backup Microsoft SQL Server fmannhardt Thu, 04/19/2012 - 03:14


In Microsoft SQL Server there exist two models of doing a backup:

For our purpose, backup the YAWL database on a live production system, the first model is well suited. There is further information available at Microsoft MSDN.

Backup MySQL

Backup MySQL fmannhardt Thu, 04/19/2012 - 03:09


In MySQL there is a tool called mysqldump available. To get a consistent backup you need to use the InnoDB storage engine and specify the mysqldump option --single-transaction. The backups generated by mysqldump contain the complete SQL code to recreate the YAWL database.


For example a full backup of all databases with MySQL is get by:

mysqldump --all-databases --single-transaction > yawlDatabase.sql

To backup only your YAWL database, you can specify the name (usually "yawl") by:

mysqldump --databases yaug --single-transaction > yawlDatabase.sql


To restore the YAWL database please first shutdown all running YAWL services. Then issue the following command:

mysql < yawlDatabase.sql

You may also supply username and password of a database user.

YAWL generated process log analyzed with Disco

YAWL generated process log analyzed with Disco mstamm Sat, 07/11/2015 - 00:27
YALW - Meal Workflow

In the context of our university project, “Process Mining” at Hochschule Bonn-Rhein-
,  we  are  executing  processes  with  YAWL  and  using  Disco  to  analyze  the
process logs. Please read the whole article here YAWL generated process log analyzed with Disco.
In  this  article  we  are  describing,  how  we  analyzed  a  compact  YAWL  generated
process  log  with  Disco. First  of  all  we  like  to  explain  the  YAWL  process  and  the
analysis of the resulting process log  with Disco. (MealWorkflow.yawl, Meal Workflow process log and Disco project resources)

Furthermore, we will describe our self-written java tool for replacing YAWL generic resources.
(Download java tool: https://drive.google.com/file/d/0B6VLBli5s2MqSW9uMlFueGIxeUU/view?pli=1)

Attachment Size
YAWL generated process log analyzed with Disco (432.72 KB) 432.72 KB
MealWorkflow.yawl (15.19 KB) 15.19 KB
Meal Workflow process log and Disco project resources (35.25 KB) 35.25 KB

Creating and using Codelets

Creating and using Codelets ahense Mon, 02/20/2017 - 09:05

In this tutorial we show in three steps how to work with codelets in YAWL. We first create a codelet, install it and then invoke it from a YAWL workflow. We assume that you are familiar with editing and running workflows in YAWL.

Create Codelet

In the attached zip file you can find a codelet RandomNumberCodelet.java. In order to compile it you need the YAWL library jars from here:


Unzip and put yawl-lib-4.1.jar in your Java project. Also put jdom2-2.0.5.jar in your Java project (both jars are also in the zip file).

Compile the RandomNumberCodelet.java.

Install Codelet

Put RandomNumberCodelet.class  in /opt/codelets/codelet - you can choose any other directory here. Open file


and change the following parameter accordingly:


Run Codelet

Start the YAWL engine and load codeletInvocation.yawl into the YAWL editor. Run the workflow and see if a random number is displayed in the third task.


codeletFiles.zip (2.48 MB)


YAWL and LDAP ahense Wed, 01/13/2016 - 11:10

treesOrganisational data, user names and passwords are at the centre of the resource perspective of workflow management systems. YAWL has its own organisational model, and in the standard configuration, organisational data are entered via the control centre.

In a realistic setting, the workflow management system runs in an organisation where organisational data are registered in a central directory. The standard used here is the Lightweight Directory Access Protocol or LDAP for short. YAWL is an LDAP-enabled application in the sense that it can be configured to obtain its organisational data from an LDAP directory.

In this short tutorial we show how to configure YAWL to use an LDAP directory. Using a real-life directory can be challenging because of security aspects built into these systems. In order to see how YAWL can be connected it is easier to install an LDAP server for testing purposes locally. An excellent introduction on how to install OpenLDAP on an Ubuntu Linux is contained here:

Butcher M. Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services. Packt Publishing; 2007.  

We assume now that you have installed your own LDAP server or that you know how to access a production server.

YAWL has two files where LDAP can be configured:



In the web.xml file you must set the value of the parameter OrgDataSource to LDAPSource. And you must set the parameter ExternalUserAuthentication to true.

The file LDAPSource.properties must be adapted to the LDAP server you want to connect to. The file that is shipped with YAWL is well documented and consist of two parts. In the first part, the connection parameters are set. In the second part, the properties of YAWL are mapped to LDAP attributes. We have mapped the roles attribute to employeeType in LDAP:

# Roles Attributes
# the name of the Role attribute name.

If everything is configured correctly, you should be able to see the LDAP users in the control centre.

Using Worklets and Exlets to reduce Workflow Complexity

Using Worklets and Exlets to reduce Workflow Complexity ahense Tue, 10/18/2016 - 15:51


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:


Rules for task Approve Request
Condition Action Worklet
Max_price < 500 No approval ApproveAutomatically
500 <= Max_price < 10.000 Approval by manager -
10.000 <= Max_price < 100.000 Approval by senior manager ApproveSenior
Max_price >= 100.000 Approval 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.




Rule type



Create request




Approve request













WI post-constraint



Create purchase order

WI post-constraint



Select goods





WI post-constraint



Receive goods

WI post-constraint



Receive invoice

WI post-constraint



Return goods

WI post-constraint




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:



First name

Last name









Manager, Requisitioner




Manager, Requisitioner




Senior Manager, Manager, Requisitioner




Buyer, Requisitioner












Accounts Payable, Requisitioner

All users have the password "pass".


Custom forms for beginners

Custom forms for beginners k.schildt Mon, 04/28/2014 - 15:19

Result of  this tutorial:



This tutorial should help you to create a custom form.

At first what you need is the YAWL Engine and you need a little bit of knowledge about HTML, Java and JSP.






At first we begin with the example of a custom form and with a workflow for integration.

All necessary files are located in the customform folder .

The first step is that you have one participant in your resource service. You can use your own participant or you create a new one.

The second step is to import the folder “transFormer” at the following folder at your YAWL Engine “…/YAWL4Study/engine/apache-tomcat-7.0.52/webapps”.

Later we will give you an explanation of the file “customformexample.jsp“.

The third and last step is to upload the specification “Custom_form.yawl” to your YAWL Engine.



Now let’s take a look at the workflow

This workflow has two tasks. The first task “ShowCustomForm” has three task variables that are displayed in a custom form.

Now you have to set the destination of your custom form. In our example the location of the custom form is on the apache server of the yawl engine.

The adress of our custom form jsp-file is http://localhost:8080/transFormer/customformexample.jsp.

If you want to access the custom form from another system, then you have to change the adress to your ip-adress of your computer.


The next task “PrintValues” shows that the values are in the task “ShowCustomForm” now and the custom form really works.


Creating a custom form

The first step with the workflow is done now, we take a look at the creation of a custom form. In our example it's the file “customformexample.jsp”

To create a custom form, it is useful to use a development environment. In our example we use the development environment “Eclipse”.

Excursion to eclipse

At first we take a little excursion in creating a project in eclipse, because if you create only a jsp-file “Eclipse” doesn’t know many of your code commands.

At first we create a java project named “CustomForm” and create in the folder “src” a jsp-file named “customformexample.jsp” and we don’t use a jsp-template.

To prepare the project we right-click on the folder “JRE System-Library” select “Build Path”->”Configure Build Path”.

At the tab “Libraries”, there is a button “Add External JARs…”. Click on that and select “.../YAWL4Study-3.0beta/editor/YAWLEditor3.0beta.jar”.

Now the library of the YAWL Editor is imported to the project.

Back to the development of the custom form

Now let’s write the code “customformexample.jsp”.

Our first thing is the java code, after that we create the HTML Form, which will show to the end-user.

In order to access the java classes, we import this.

<%@ page import="org.jdom2.Element"%>

<%@ page


<%@ page import="org.jdom2.output.XMLOutputter"%>

<%@ page import="org.jdom2.output.Format"%>

<%@ page import="org.jdom2.input.SAXBuilder"%>

Getting back, when ready we set the redirect URL.

String redirectURL = (String) session.getAttribute("redirectURL");

if (redirectURL == null) {

       redirectURL = request.getParameter("source");

       session.setAttribute("redirectURL", redirectURL);


If the cancel button has been clicked on the HTML form, we clean up any session attributes which are be set, then return to the worklist.

String submit = request.getParameter("submit");

if ((submit != null) && (submit.equals("Cancel"))) {









To retrieve the workitem data’s as xml, we use a workqueue gateway client object. The url is the default value, if you use the apache server of the YAWL Server.

If you use another apache you have to place the “YResourceServiceClient.jar” at the same location.

String wqURL = "http://localhost:8080/resourceService/workqueuegateway";

WorkQueueGatewayClient wqClient = new WorkQueueGatewayClient(wqURL);

If the form has refreshed, it will be stored in a session.

String itemXML = (String) session.getAttribute("itemXML");

If the form is not refreshed, it gets the xml from the gateway. For that we get  the workitem id from the request and the user. In the following we set the variables "itemid" and "handle".

The itemXML contains the data of the work item and we save the three variables in a session, if the form would be refreshed.

if (itemXML == null) {

       String itemid = request.getParameter("workitem");

       String handle = request.getParameter("handle");


       itemXML = wqClient.getWorkItem(itemid, handle);

       session.setAttribute("itemXML", itemXML);

       session.setAttribute("workitem", itemid);

       session.setAttribute("handle", handle);



Now, we take a look in our example workflow, what we get in the itemXML to understand and what we have to do next.














     <enablementTime>Apr:22, 2014 18:00:32</enablementTime>

     <firingTime>Apr:22, 2014 18:00:42</firingTime>

     <startTime>Apr:22, 2014 8:00:42</startTime>













                <var>Change my value</var>

                <var2>Hello World</var2>





We see above, we get the “workItemRecord” with many elements, which we can show at our HTML Form for example “id”,”caseid”,”tasked”,...

We see blue coloured the element “data” that contains the element “var” and “var2”. That’s our variables which are from the scope “InputOutput” and “Input”.

Our “var3” is from scope “Output” that’s the reason why we don’t see it as an element. We don’t use it in our example, but the element “updateddata” contains the saved values, if you implement a save button in your custom form.


Back to the code. Now we have seen above the content of “itemXML” and  we have to prepare them with JDOM. We create three objects from type Element. “wir” contains all element from the root level from “id”,”caseid”.

 If an save button exists, "updatedData" contains elements. “data” checks updatedData contains content, if that set them as content for the form or set the element “data”.


Element wir = new SAXBuilder().build(new StringReader(itemXML)).getRootElement();

Element updatedData = wir.getChild("updateddata");

Element data = (updatedData.getContentSize() > 0) ? updatedData    : wir.getChild("data");


Next we go one level down from element data this element we define as wirData.

Element wirData = data.getChildren().get(0);


If the itemXML contains an error, we have to check it and put out an error message.


String error = null;

if (!wqClient.successful(itemXML)) {

       // show the message to the user in an appropriate way. In this case, we'll

       // simply show it on the form below

       error = itemXML;



If the itemXML is checked, then we use the else statement. In the else item we put our individual code which is in every custom form fitted to the variables of the task.

At first we read the new values as entered on the HTML form and save it in variables and then we define the names from our variables of the task, which was be modelled in “YAWL Editor”

else {

       String var_input = request.getParameter("var_input");

       String var2_input = request.getParameter("var_input2");

       String varName = "var"; //The value with input and output

       String varName3 = "var3"; //The value with only output

Then we check it. If the values of “var-input” and “var2_input” are not null and in another then we check, if the element “wirData” is not null. In that statement we define our updated Element.

In our “itemXML” example, we see that the variable “var3” is missing, so that we have the create as node.

Important! Here we have to hold the order which is defined in YAWL Editor, that’s the reason why we define the output in the editor at last and saved us a sorting of the element “wirData”.

 Now the new Element we have to add to “wirData”. After that we check in,  if the statement  “dataitem” is not null and set the text of the variable “var” and also check if “dataitem2” is not null and set the text of the variable “var3”.


       if (var_input != null && var2_input !=null ) {

             if (wirData != null) {

                    Element dataitem = wirData.getChild(varName); // get data var

                    Element dataitem2 = new Element(varName3); //creating the node for var3


                    if (dataitem != null) {

                           dataitem.setText(var_input); // update data var's value

                           if (dataitem2 != null) {



The workitem has to be updated via the gateway, with the new values. After that we check, if the update via the gateway was successful and remove the session and redirect.

                                  String itemid = (String) session.getAttribute("workitem");

                                  String handle = (String) session.getAttribute("handle");

                                  String dataString = new XMLOutputter(Format.getCompactFormat()).outputString(wirData);

                                  String result = wqClient.updateWorkItemData(itemid, dataString, handle);


                                        // check all is ok - if so, close the form

                                  if (wqClient.successful(result)) {


                                        // clean up our stored session attributes






                                        // now we can redirect back to the worklist.

                                        // if you want the workitem to complete when it posts back, add

                                        // the parameter below and set it to 'true'; if it's false or

                                        // missing, the workitem will update but remain on the worklist's

                                        // 'started' queue (a 'save')

                                        redirectURL += "?complete=true";


                                        } else {

                                               error = result;

                                  }//closing if(dataitem !=null)


At last we close the last 'if' and give them else statements.                                                                                                  

                           //This else condition gives a feedback if the varName3 is null

                           } else {

                                  error = "This workitem does not contain a variable called '"

                                               + varName3 + "'.";


                    //This else condition gives a feedback if the varName3 is null

                    } else {

                           error = "This workitem does not contain a variable called '"

                                        + varName + "'.";


             } else {

                    error = "This workitem does not contain any data for updating.";






Finally, for the web layout we need the html code. Per html it's possible to set the workitem page to their wish.
For each work item page that has same layout, you can implement a css-file in the html code.

In the following, we declare the HTML code and at which point we can implement the css-file.


HTML code first part

At first we determine the title of the html document. This is displayed only on the edge of the browser. Directly under the <title>, we  integrate the link to our "style.css" document.

In order for our html-code can retrieve the settings of the css-document now.

We set the size of the website and the font (in this example) in the head part.

After the <head> part, we start with the <body> for set the specific website structure.

In our example, we use the html command <h1> for our headline.

So that the html code assigned to the settings in the css file, we assign for each pattern piece a fixed id.

The css file references namely to the id. After the header, we want to show the case id and a work instruction. For this we create a table with <table> ( for more variety of our commands).

The the first row <tr> should show the output of Error, if there is one.  In the second row comes the work instruction. The command &nbsp; is used to get a space command.

In the <td> command can you set the width heigth and align for the specific column.




HTML code second part

As next, we divide the parameters into two fields with command <fieldset> . The input values are placed in the first field and the retrieved values in the second field ​​.

The fields we can declare individually with the  <legend> command.

In order to address the individual variables in the rows, we use the command <label>( In this example, we disabled the labels and use the legends for a fictitious example layout). With a unique label or an id, is the variable area for the css-file clearly identifiable.

After both fields, we implement the save and cancel buttons. For that we need the <input> command with the type of "submit".


If you have further questions, feel free to comment.


(Notice: This tutorial was created with build version 3.0beta.)

custom form.zip (68.55 KB)

Using YAWL 3.0 Repositories (part two)

Using YAWL 3.0 Repositories (part two) ahense Fri, 10/03/2014 - 17:57

In a previous tutorial we showed how to use the repository of YAWL 3.0 for extended attributes. We now want to use the complete workflow of that tutorial in a new workflow as a subnet. We use the repository functionality for that.

The first thing we do is to load the workflow attached to the previous tutorial into the editor and use the net menu to store it in the repository. We also store the datatype definition in the repository.

Then we close the specification and create a new one. We first load the datatype definition from the repository.

In the new specification we load the previous specification from the repository and rename the resulting new subnet "Check post".

Now we go to the root net and connect the subnet to the composite task - the label may have to be adapted.

We proceed by defining a net variable fName:string and by defining postDesc and avail for receiving values from the subnet "Check post". We open the data variable dialog for the composite task and get this:

We change the decomposition variables postDesc and avail to scope output.

We define task Register with fName as output variable and tasks Note rejection and Note acceptance with fName and postDesc as input variables.


Testing the workflow shows that the mappings in the subnet are broken.


Two questions remain to be answered. Where is the repository stored? How can I save my repository?

The repository is here ../YAWL-3.0/editor/repository. There are a number of XML files with descriptive names. These files can be saved for future use and can be restored. A good idea seems to be to create one repository for each project.



Stylesheet for removing double complete events in YAWL XES logs

Stylesheet for removing double complete events in YAWL XES logs ahense Sat, 02/04/2017 - 16:34

YAWL creates XES logs directly from the control centre. This makes it easy to do Process Mining with tools like ProM, Disco or Celonis. There is however a little problem: YAWL creates "complete" events twice for every work item. This can be seen in file processMiningSimple0.1.xes in the attachment.

We have created an XSL sheet that removes these double "complete" events. When you apply this like this

$ saxon-xslt processMiningSimple0.1.xes transform.xsl > processMiningSimple0.1.removedDoubleComplete.xsl

you obtain the file processMiningSimple0.1.removedDoubleComplete.xsl which has been uploaded into ProM, filtered on simple heuristics and displays the process model in this picture.


files.zip (7.84 KB)

Reusing YAWL specifications as subworkflows (YAWL 4.0)

Reusing YAWL specifications as subworkflows (YAWL 4.0) ahense Sat, 04/23/2016 - 11:19

YAWL 4.0 features an integrated worklet editor that makes the work of  a previous tutorial much easier. Our goal here is to use the worklet service to create a subworkflow that can be reused in many specifications. In order to demonstrate this, we will create two YAWL specifications. MainProcess.yawl is the specification for the workflow that will call the subworkflow. DisplayValue.yawl is the one that will be called. You can find the specs attached below. Let us now start step by step.

Upload the Worklet

Make sure that your YAWL editor is connected to a running YAWL engine. Open DisplayValue.yawl in your YAWL editor and store it as a worklet.

Add a Rule to the Main Workflow

Close this specification and open MainProcess.yawl. Then add a rule to this specification.

The rule type must be set to "Worklet Selection". The task must be set to "ShowValue". Note that the custom service in the decomposition of task "ShowValue"  must be set to the worklet service (this is already the case in our specification).

The condition is set to the constant "true" because we always want to use the same worklet.

In the "Actions" section we have to select the action "select" ...

and choose our worklet DisplayValue as the target.

Now the dialogue should look like this.

We click "Add & Close" and hopefully get the following message of success.

Export the Rule Set

This step is optional. Exporting the ruleset allows you to reuse it later in another YAWL engine. There is a button for exporting the rule set.

The following selection dialogue appears. Note that the rule set is associated to the specification and its version.

Store the file MainProcess.xrs somewhere. It will look similar to this.

The main process is identified by its name, its version, and its unique identifier. The worklet is identified by its unique identifier only.

Deploy the Workflow

Next we will upload MainProcess.yawl using the button in the editor.

Now we are ready to test if it works. We start a case for MainProcess and assign the workitem ShowValue to some existing user. When the user views the work item it should look like this:

It is important that it says "Display value". If it says "ShowValue" it is not the worklet but the default behaviour of the MainProcess that is displayed.


Working with Data Gateways

Working with Data Gateways ahense Sun, 03/01/2015 - 15:42

This tutorial is written for YAWL 4.x and replaces a previous tutorial for YAWL 2.3.

In addition to using net variables in YAWL we can also store and fetch data directly from a database. In this tutorial we show how to retrieve data from a simple database table using a YAWL Data Gateway. In the previous tutorial for YAWL 2.3 Microsoft database was used. Here we will demonstrate the case with PostgreSQL. We assume that you are familiar with the basics of databases and have installed PostgreSQL and pgAdmin.

We start by creating a new database with name "CustomerDB" and owner "postgres" having password "postgres". In this database we create a table "Customers" with owner "postgres". We create columns ID:integer (primary key), Name:text, Age:integer and fill it with some data:


When we click on the magnifying glass symbol in pgAdmin while table "Customers" is selected we get the SQLeditor. There we choose the tab "Graphical Query Builder", navigate to table "Customers", select "Name" and "Age", and click on the green triangle. We should get the following query:


Now we create a new Java project named "yawlDataGateway" in Eclipse or Netbeans. We download the YAWL Library Jars, unzip them and add the yawl-lib-4.2.jar and YResourceServiceClient.jar to the build path. Furthermore, you need jdom-2.0.6.jar and hibernate-core-4.3.11.Final.jar in the build path.

The code of the class MyExternalDBGatewayImpl is attached here. We deploy yawlDataGateway.jar to ../webapps/yawl/WEB-INF/lib. We restart the YAWL engine and the editor.

We build a simple YAWL workflow as attached here. If everything works correctly, it should look like this:



The Java code is a quick hack - not very robust. Who has a more elegant solution?


Fri, 07/10/2015 - 13:32

Hi Ahense,

I am getting below error (screenshot attached) while using same .yawl or .java file to retrieve data using Data Gateways.
When I am loading (same) dataGateway.yawl

- Java class name is available under Data Gateway properties
-Suggest us location to put .class file (if any fixed location)

Error while binding

Referring same tutorial suggested by you : http://www.yaug.org/content/working-database-gateways
YAWL Version:3.0.1

Thanks in advance for your help

I get the same "not found" error when the compiled jar file yawlDataGateway.jar (here included in dist.zip) is not in the right place. This file goes to .../webapps/yawl/WEB-INF/lib.

Furthermore, the data gateway is not used at net level as in your screenshot but on task level as below.

data binding

dist.zip (3.53 KB)

YAWL Data Gateways With Hibernate

YAWL Data Gateways With Hibernate ahense Mon, 09/30/2019 - 17:00

In many cases, we want to persist entities occurring in workflows in a relational database. YAWL has a mechanism called Data Gateway allowing us to store and fetch data directly from a relational database without using net variables.

In this tutorial, we show how YAWL Data Gateways and Hibernate can be used in conjunction. We perform these steps:

  1. Create a relational database in PostgreSQL.
  2. Write a YAWL Data Gateway using Hibernat.
  3. Specify a YAWL workflow to use the Data Gateway.

Create a relational database in PostgreSQL.

We create a database "messagerepository" owned by user "postgres" with password "postgres". We create a table "message" with two columns using the attached "sqlScript". When filled with values the table will look like this:

filled table

The idea here is that messages will be created by the user during the execution of the workflow cases and that the unique id will be generated by Hibernate.

Write a YAWL Data Gateway using Hibernate.

The following code has been adapted from a Hibernate course by Peggy Fisher.

We are using Netbeans as an IDE. We import the Netbeans project from yawlDataGatewayHibernate.zip and add the attached jar-files to the Libraries. The resulting project should look like this:

Netbeans project

After successfully building the project, there should be a file called yawlDataGatewayHibernate.jar in the "dist" folder of Netbeans. This file should be copied to the YAWL-4.2/engine/apache-tomcat-7.0.65/webapps/yawl/WEB-INF/lib folder. This allows YAWL to retrieve the Data Gateway called "MyDBGatewayImpl".

Specify a YAWL workflow to use the Data Gateway.

Now we create a simple workflow specification like this:

The specification


In the first task, the user enters a message text like this:

The first form


This message text is directly stored in the database table "message" using Hibernate. In the second task, all messages stored so far are displayed like this:

The second form






RPA Tutorials

RPA Tutorials sremp Mon, 03/02/2020 - 15:00

How to use Robotic Process Automation within YAWL #1 - Setup and basics

How to use Robotic Process Automation within YAWL #1 - Setup and basics sremp Fri, 02/28/2020 - 16:34

YAWL 4.2.x

Selenium WebDriver 3.1x

(It should be compatible with newer versions)

Attached files:

  1. The Codelet which contains the RPA script called “FirstTutorialsCodelet.jar”
  2. The GeckoConfig.xml which contains the path to the WebDriver, packed within “.GeckoConfigYAWL”-directory
  3. The YAWL-net “Tutorial1_SearchForData
  4. The GeckoDriver itself (can be downloaded on projects page)
  5. The Codelets source code
  6. The YAWL organizational data "YAWLOrgDataExport"


1 Motivation

Robotic Process Automation describes different technologies that operates on graphical user interfaces and imitate human interaction with such interfaces. There are plenty of approaches how to use RPA in an industrial context. Besides the big market leaders like UiPath or BluePrism there are some free and open source RPA tools like Argos Labs or Automation Anywhere. But as good as these tools are for their main purpose, most of them lack in their ability to integrate the opportunities given by Robotic Process Automation into an industrial established workflow automation system.

With that in mind I would like to present you an approach to automate web-based Business Processes through a combination of Workflow Management and Robotic Process Automation. For this approach I will use the profound researched open source Workflow Management System YAWL and Selenium WebDriver, which represents an open source framework for different programming languages to automate the interaction with a web browser.

In the following weeks I will present you a partwise tutorial on how to set up the right environment for reproducing this approach, as well as how to create own workflows and RPA scripts.  In today’s Part I will demonstrate you how to use Selenium WebDriver in the frame of YAWL to search for a plain text in Google.


2 Basics and set up

As you are already reading this text in a YAWL specific user group, I assume you are familiar with the basics of workflow automation and YAWL. If not, I would advise you to visit the YAWL Foundations website http://www.yawlfoundation.org and especially to read the YAWL user manual http://www.yawlfoundation.org/pages/support/manuals.html, which gives a very good overview about YAWL and the possibilities for a company to automate their Business Processes with this Workflow Automation System.

2.1 Codelet

If you are already familiar with YAWL, you should know that that YAWL offers a service to integrate different users into a Workflow. This can be done by the so-called Resource Service. A not so well-known fact is that you can integrate software as a resource as well by writing a Codelet.  A Codelet is a java class that is directly embeddable as an executing resource in YAWL. This is a very mighty tool and offers many opportunities for different scenarios. Because of the scope of this topic I would advise you to read Chapter “4.12.1: Codelets” (Version 4.2) in the YAWL User Manual or to visit http://www.yaug.org/content/creating-and-using-codelets&nbsp; for further information. 

Here I’ll give you a short explanation on how to integrate Codelets into YAWL. For giving YAWL the ability to find Codelets you have to change the „web.xml“ file which can be found in the YAWL installation directory „\...\YAWL-4.2\engine\apache-tomcat-7.0.65\webapps\resourceService\WEB-INF”. In this XML file you have to customize the element „<param-name>ExternalPluginsPath</param-name>“, because YAWL will use this XML element to start the search for Codelets in this given Codelet root directory. To give you an example I will show you my configuration in Windows which is built with the following Codelet root directory “C:\yawlPlugins” as follows - „<param-value>C:\yawlPlugins</param-value>“.  A not so obvious but mandatory aspect is that you must build a directory structure within the Codelet root directory according to the java package structure you have used for your Codelet. In this case, the Codelet is lying in the java package “codelet”. Because of this, you must create a directory “codelet” within the Codelet root directory. The attached Codelet must be inserted in the “codelet” directory, because otherwise YAWL could find the Codelet, but isn’t able to execute it.

The absolute path to my Codelet root directory is: C:\yawlPlugins

The path used within YAWL to find the GoogleSearchForYAWL.jar is the Codelet directory path + the java package structure + the Codelets file name -> C:\yawlPlugins\codelet\GoogleSearchForYAWL.jar

2.2 WebDriver

Because the framework Selenium WebDriver supports Java it is possible to write a Codelet in which the functionality of the WebDriver can be used directly. There are different WebDrivers for different web-browsers. For this tutorial we will use the so-called Geckodriver, with whom it is possible to automate the Firefox browser of Mozilla. An important step to get the whole approach working consists of telling the Codelet where the executable Geckodriver lies. For this step you can chose between three different options:


  1. 2.2.1 (Strongly Recommended) Tell the Codelet where the Geckodriver lies by a provided config file


There is a directory called “.GeckoConfigYAWL” with a XML file attached. You can change the given path in the XML by changing the text between the “GeckoDriverFilePath” elements. Take care that you refer directly on the executable file. This can be done independent of the operating system, just look up how your file is called and what the path of it is.


Windows example:

<?xml version="1.0"?>








Linux example:


<?xml version="1.0"?>


  <GeckoDriverFilePath> home/Documents/driver/geckodriver </GeckoDriverFilePath>






The directory with the changed XML configuration file should be in the user’s home directory, so that it is possible for the environment to find the directory at runtime.

In my Windows system the location of my folder is “C:\Users\Simon” while in my Linux system it is the “home/Simon” directory. If configured correctly your environment should have no problem to access the Geckodriver. If you followed carefully you may noticed there are more XML elements with empty values. They will be used in later tutorials to configure where RPA-scripts are lying.


  1. 2.2.2 Let the environment search for the Geckodriver in the systems path


You can use your systems path to access you gecko driver. For this you must make an entry at your system path file with a link to your Geckodriver file. All steps necessary for this can be found on following website of the Selenium developers https://selenium.dev/documentation/en/webdriver/driver_requirements/.


  1. 2.2.3 Tell the Codelet where the Geckodriver lies by a YAWL parameter


The last provided possibility to give the environment the information about the location of your Geckodriver consists of transferring the information as a string parameter directly in YAWL. As soon as you define a Task as an RPA task it automatically gets two parameters. One represents the text you are searching and the other represents the Path to you Geckodriver. You can either declare the path as a default value or transfer the path as a text at runtime. Both ways aren’t very comfortable because you need to define the path of the Geckodriver either for every RPA tasks or worse, for every RPA task in every execution. And how we like to say: don’t repeat yourself! So for getting started and “Hello Worlding” it is a pretty easy way, but it isn’t anything you want to consider for the big game.

Note that you can use all 3 options to be safe in the case of an error. The provided environment searches with every option after another until a Geckodriver file was found.

3 Organizational data

If you want to produce the same results as I  you should upload the organizational data as well. For this there is a file provided, too. It’s called “YAWLOrgDataExport”. This file should be uploaded in the YAWL control panel in tab OrgData.

4 Description


The workflow consists of two tasks. First there is a task to enter relevant data for the search and for the configuration, second there is an automated task which hosts the Codelet.

Now that you have set up everything you are ready to go for a first execution. For this upload a new case from the YAWL editor or out of the YAWL control panel. You can now login with the user “Ulfric User” or “Alfred Admin”. Their login is “uu” or “aa” and the password is “1111”. Now you can start the work item and insert a text to search for in google.  

If you used the config file or the systems path to identify the location of the Geckodriver you can ignore the lower field “Path of GeckoDriver”. As soon as you mark your work item as completed a new Firefox browser should open and execute a search in Google.

Note that the YAWL Control Center outputs some Error messages, which you can ignore for now. Second you should know you are not supposed to use you keyboard or mouse while execution the RPA script, because with this you abort the interaction and change to manual mode. Last you should keep in mind that the first execution needs some time (15-30 seconds). After this all further executions should terminate much faster (max 3 seconds).  After the execution you can just close the web browser.

5 Conclusion and outlook

In this tutorial you have seen how to set up a “hello world”-ish environment for automating interaction with google out of a workflow management system. In the next parts I will present to you how to write more complex RPA scripts and how to interact with a rich internet application.  Last I will present you how to use a provided Codelet to manage generic data transfer between the workflow management system and the RPA scripts as well as how to ensure exception management.

How to use Robotic Process Automation within YAWL #2 - Creating new RPA scripts

How to use Robotic Process Automation within YAWL #2 - Creating new RPA scripts sremp Fri, 03/06/2020 - 12:11

Welcome to the second Part of the “How to use Robotic Process Automation within YAWL”-Tutorial. Like already demonstrated in the first Tutorial, Selenium WebDriver is a great framework for automating interactions with a web browser in a Robotic Process Automation manner. In today’s tutorial I want to demonstrate you the basics of writing a Selenium WebDriver based RPA-script in the programming language Java.

The initial idea of Selenium WebDriver is to automate testing procedures of web applications. This still is the main purpose of Selenium WebDriver in software industry. Nonetheless Selenium can be used excellent for automating anything in the context of web browsers. Like they say on their website:

“Selenium automates browsers. That's it! What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that.”

 Selenium offers two different ways to create scripts. On one side there is the already introduced Selenium WebDriver Framework, in which a developer must implement the whole execution logic by himself. On the other side there is Selenium IDE, which represents a software tool with traditional RPA functionalities, like screen scrapping user interactions with a web browser and generating an executable script for replaying the recorded interactions These functionalities are very similiar to the ones of professional tools like UiPath, like described here https://forum.uipath.com/t/why-developers-still-use-selenium-testing-tool/140651.

Unfortunately, Selenium IDE can’t be used as a complete RPA suite because the focus on testing web applications is pronounced strong in this tool and the generated scripts are optimized for unit testing. Anyway, we can use Selenium IDE for generating prototypical RPA scripts which can later be finished by a developer. This gets more interesting as employees of non-technical departments can use Selenium IDE to record their daily web application workflows to generate prototypical scripts rather than waste valuable time in describing and discussing their needs with a software developer or IT-specialist. With this methodology user and IT-departments can be relieved from overhead.



Selenium IDE is rather a straightforward application. After integrating it as an extension into a browser you can easily record further interactions with the web browser. After the recording you can customize the resulting recording. You can change the order of the execution steps, the interaction methods (html id, html class, css …) and manually insert steps like explicit wait commands for slow web applications to load.

If an interaction sequence is recorded like this there will be an exported output similar to following screenshot

As you may have noticed this is a class for automated tests in the unit testing framework Junit. Although this code is not directly usable as a RPA script, it can be transformed to one. You only must change the class into a regular java class and customize the code logic for your purpose.



For this example, I customized the Webdriver creation and deleted unnecessary methods. Depending on your needs it could be required to write new lines of code for extended logic or to add some return logic. Starting here: https://selenium.dev/documentation/en/webdriver/browser_manipulation/ you can explore the unlimited ways of automating web interaction with selenium. This way i wanted to demonstrate you what Selenium itself offers us even without integrating it in YAWL. Altogether I presented how the tool Selenium IDE can be used to generate a RPA script blueprint by an employee for a developer. But with YAWL in mind this approach isn’t satisfying at all, because there are too many ways how exceptions could occur, apart from the fact that you can hardly integrate individual data types with this approach. In the following tutorial I will present you a Codelet which gives you the ability to execute RPA scripts with self-made XML datatypes while managing appearing exceptions.

How to use Robotic Process Automation within YAWL #3 - Use a generic Codelet as Interface

How to use Robotic Process Automation within YAWL #3 - Use a generic Codelet as Interface sremp Tue, 03/31/2020 - 10:42

(At the moment Windows only, bug under Linux will be fixed)


Attached files:

  1. The Jar which contains the generic Codelet “SeleniumRPAForYAWLFinal.jar”
  2. The GeckoConfig.xml which contains the path to the WebDriver and paths to RPA scripts packed within “.GeckoConfigYAWL”-directory
  3. The YAWL-net “ThirdTutorialSearchItemInOnlineShop"
  4. The two RPA scripts BuyItemRPA.jar and SearchForItemInShop.jar
  5. The Codelets and RPAs source code
  6. The YAWL organizational data "YAWLOrgDataExport"


1 Motivation

In today’s tutorial you will see an approach on how to automate business process with YAWL and Selenium with an interface, which offers the ability to transfer individual datatypes and manages exceptions. You will get an idea of the possibilities that lies in such an approach. For this tutorial I provide you a workflow net with two RPA scripts. You will be able to search for items in an online shop an decide whether you want to put them in a basket or not. The example itself isn’t the most complicated but it will show how to integrate Robotic Process Automation into YAWL and on what points you should keep attention. The main idea for this whole approach is to use a single Codelet to integrate multiple RPA scripts through the config file which was introduced in the first tutorial.

The workflow itself is like I said before rather simple. You insert some data to search for in the web shop, after you complete the search form an agent will be executed which searches automatically for an item with the given text. If it found some, the first will be chosen and the price as well as the name will be returned into the net and displayed. If no item was found, this will be displayed, too, and the workflow ends. In case of a returned item, you can decide whether to “buy” this item or cancel the process. For the buying task a new Robot will be executed, which puts the item into a basket. Mind that this is only a mocked web shop, so you don’t run danger into buying anything.

2 Difference in detail

At the first expression this approach doesn’t differ much from the one in the first tutorial except that two different Robots were used, but this impression is wrong. In the background are many steps for data transfer, validation and exception handling done.

But let’s get this done from bottom up. One of the main advantages of this approach is, that you can transfer your individual XML data types to an Robot.

In this example I defined two data types through the data type definition manager in YAWL. I defined an output datatype for returning the items attributes and an input data type for inserting a name to search for. This could be stretched far more out, like giving a max or min price or a color the item must have. A defined data type can be used as an net or task variable.

Like stated in the Codelets description there are some provide and some custom inputs and outputs. If you chose the Codelet to automate a task you must configurate the input Variables “RPAScriptName” and “GeckodriverPath” as well the output Variables “ExecutionFailed” and “Exception”. RPAScriptName is the Codelets input parameter to identify, which of all available Robots you want to execute at this task. GeckodriverPath was already described in the first Tutorial and is used if you don’t want to configure the path of your driver beforehand. Exception and ExecutionFailed are used to handle occurring errors in the net itself. They can be used to execute some compensating actions, so you get a controlled feedback why there was an abortion instead of just a runtime exception. But the exception management will be discussed in detail in an later tutorial.

CodeletInput and CodeletOutput are a bit tricky variables. They aren’t necessary if your wished Robot doesn’t need them. In fact, you are supposed to act carefully that you provide these two only if they are needed, because this will be validated in the Codelet and can led to an Exception if done wrong. The Codelet is able to recognize every valid data type and transfer it to or from the net to the robot as long as you set the variables type as the datatype and give the Robot a hint of the type (see below for more information). Very important here is that you give a default value, if you need an output. This default will be used in case of an exception because if you define an Output YAWL does always except one. In the second automated task, where the robot puts the item into a basket there is no output but an input.

The RPA script must extend the supertype AbstractSeleniumScript which is provided as a jar file. This forces you to implement some methods, to specify whether the robot needs input/output and which types. Please note that the whole validation inside the Codelet can’t be done if you don’t work accurate on this. The stated input/output type must be the same as in the net. If you work properly you can use the Information given in your Script. For this there is the class “XMLTransformer” provided, which transforms the transfered XML-String into a jdom Element, which can be read in runtime, or transforms a jdom Element back to a String for returning data.

The returning inside of a Robot is a bit tricky, therefore here a cutout of the searching Robot


        Element result = new Element("result");

        result.addContent(new Element("ItemNameResult").setText(itemName));

        result.addContent(new Element("ItemPriceResult").setText(itemPrice));

        result.addContent(new Element("ItemFoundResult").setText(("" + itemFound)));

        return XMLTransformer.XMLtoString(result);