You can also access this tutorial in German and French.


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! (15.5 KB)