Introduction

All right, so we're going to talk about process flexibility today. Pretty much everything in life is a process - or at least when you've been thinking about processes for as long as I have, everything starts to look like a process. So when we think about processes, we think about it in a sequence of our actions where we perhaps transform some data or some service or some product and come out the other end with some value added to that along the way.

Elephant in a Shoebox

So given that we can describe everything in terms of a process I've got a little exercise for you first up and that is that: how do you get an elephant in a shoebox in a process-centric sort of way. Has anyone got any ideas, any guesses? Three steps. I'll just drag this over, so I can get on the video. Anybody? Okay, three steps. Step one: take the lid off the box. Step two: push the elephant as hard as you can inside the box. Step three: put the lid back on the box. So three steps through any process coming to this particular process as I said.

Assembly Line Metaphor

When we think about processes, we're thinking about things in a sort of an assembly line. An assembly line is a natural way to think about how processes run. In fact the workflow management coalition in 2002, in the introduction of workflow document, said much work even office procedures can be processed as an assembly line. So what is it about assembly lines that are a good fit for processes? You know it's the idea that we can take some raw material or some basic service or some application for a loan or something like that, process it in some way, so that at the end we have a finished value-added product or service - much like an assembly line. But an assembly line is not necessarily the best way to think about how work is done, when we try and capture something that happens in the real world and get it into a computerized form - you know - in a program perhaps or you know in a workflow process. Then we're losing some information from the real world. Whatever modelling tool we use, whatever way we choose to describe a process in the real world, we lose some information, because no modeling technique is perfect in capturing all necessary information. Indeed, the way that our programming is done, follows the same sort of model. You have inputs, you process those inputs, and you have outputs. So technology doesn't occur in isolation. Ideas from one area flow into the next. So the idea of an assembly line flowed into the idea or the way of thinking about computing. So Turing's universal machine, the von Neumann architecture of computing, all sort of follow this assembly line metaphor. So assembly lines are fantastic if you're building cars. Very efficient, time saving, get the job done in the best possible way and a lot of business processes too are. I can follow the assembly line metaphor because they run very rigid sort of processes that don't change much through each iteration of that process. But real world being what it is, there are a whole bunch of processes that don't fit well into that assembly line metaphor because there are various ways in which people work to get the job done and it's very hard to fit that sort of work in an assembly line format.

Process Challenges

So as I just mentioned in processing, unless it's a very rigid process, we have problems representing real world activities. On the one hand, you try and make it understandable, so people can look at that model and understand the work that's occurring. But on the other hand - particularly if you want to execute it in some sort of business processing system - it needs to have all of the information that it needs but that it requires to be able to successfully run that process. So the more comprehensive a process model is, the harder it becomes to understand. Particularly if it's a very big model. So for example, there's a very simple model here. But you can see, there are quite a number of different places where decisions are made and so, even in this small example, you start to lose the main flow of what the process is about while dealing with all of these choices. Work practices evolve. So they change over time. Sometimes quite quickly you know. Organizations are always looking at their competition to see how they're doing things and maybe changing up the way they do things as well to match their competitors or they are seeking new efficiencies or they figure out a better way of doing something or a cheaper way of doing something. And so practices evolve. There's a lot of difficulty evolving processes to match the way that work practices evolve over time. Particularly when you start to think about ... well, if I've got a version of a process running and we need to change it in some way. So we've got a new version of the process now. What do we do with the cases that are running on the old process model? Do we migrate them to the new model? Do we wind them back? Do we start all over again? Do we let them run on the on the old more inefficient model? And so on. So all sorts of problems there. And also, there's difficulties in handling deviations from the central flow. So you can see here: we've handled deviations from the central flow by putting in some splits and joins, where decisions might be made. But anything more complex than that, things start to get very difficult indeed. Particularly in large models.

Deviations

Okay, so what's an exception or a deviation? It's well known in the research - widely researched the fact that any instance of any process there will be some deviations during the running of that process. Deviations meaning ways in which the main flow is not followed. So in almost every instance, there'll be something that happens, some event, some data inside the process, some external event the outside of the process that changes the way that that process is handled or is executed. So there's two types at the control flow perspective. One is expected deviations - are expected exceptions. They are things that you knew might happen but you didn't want to clog up the process model with those things, because it don't happen often enough to warrant their inclusion in the process model. Or they are unexpected exceptions which simply means they're things you didn't think about that could possibly happen. An event or or some data being outside of a range that you never, as a designer, you didn't think about happening at that time and so that just points to well traditionally, it points to an inadequacy in the model. In other words, the model is less than perfect in some way. And so traditionally, you would update the model to capture those things if they happen often enough. Otherwise you would just wear it or you would just deal with an exception when it occurred. And the way they were dealt with, is typically off the system. So when they're dealt with off the system, for one thing, it slows the whole process down. Things become manual. So you're losing the benefits of running our process in the first place. But also the way in which it was resolved is lost to the organization because it's done manually and not you know recorded anywhere, not logged anywhere. So the next time the same thing happens again, someone has to think up a way of handling that again because it's not recorded. So these are problems with exceptions or deviations in in the traditional sense.

Unknown Unknowns

By the way, unknown sorry unexpected exception sounds like unknown unknowns. Things you don't know that you didn't know until you find out about them which sort of echoes what Donald Rumsfeld said.

Flexibility: A Definition

Okay, so when we talk about flexibility, what are we talking about definitely here's a definition, the idea of process flexibility or the term flexibility in business processes, is the degree to which a system is able to support or handle expected or unexpected deviations. Okay, so it's the degree to which we can handle deviations or exceptions, whether they're expected or unexpected without damaging the essence of the process and allowing the process to potentially complete as expected. Okay, so when we talk about flexibility, we're talking about how to deal with these sorts of deviations.

Taxonomy of Flexibility

Okay, so there's four deviations or exceptions. So - sorry - flexibility can be categorized into four different categories. By design: we saw an example of that on an earlier slide where you put a split in a process where you want a decision to be made. So that adds some flexibility at that point because maybe it'll go this way maybe it'll go that way depending on the data and the condition on the split. So that's called by design. That's the easiest way to add flexibility to a process and most if not all workflow systems support that type of flexibility. Then this by deviation which means, you've got a process model but at runtime users or administrators can choose to deviate the path. So miss one or roll back and do one again. In other words, change the control flow. So systems like case handling systems or declarative systems, where the passage is there with no real control flow or maybe a guiding control flow and users and administrators can choose what order to do those particular activities in knowing that whatever order they do it, is moving the product towards the goal. So that's by deviation. The important thing about deviation is the original model doesn't change. It never changes. Third category is: under specification and that means that the process model that design time is left in incomplete. So you'll have things like little placeholder tasks, where at run time, you can plug in or add certain tasks or activities there. Two types late modeling, which means, you allow the user to create a part of a process model at run time to plug into that place and the other one is late binding where you have a set of possible additions at that point already made and you can bind that at runtime in the appropriate place. So that's under specification. The last one is by change and there's a whole side project if you like. Side projects of workflow that allow you or allow an administrator to change the actual process model while it's running. So you can take tasks out. You can put tasking you can change the control flow and that becomes a changed process model the next time. Again running in the change in particular runs into all those problems. What to with different versions. How are they logged? When do we swap in and out current instances? And all that sort of thing.

Flexibility and YAWL

Okay, so there's the four categories. YAWL supports flexibility out of the box, by design. Same as almost all if not all workflow products. So it allows you to do branching, choice, iteration, splits. So XOR splits and OR splits are where choices are made. You can have deferred choices with conditions. And even in parallel branches is a form of flexibility because you're not controlling say you've got an AND split with tasks A and B you're not controlling which one ends first, which one started first. All you're saying is, you're not going to continue until both A and B are complete. So that's a form of flexibility by design also. As well as as well as those basic flexibility by design features . YAWL also supports multiple instance tasks which allow flexibility by adding new instances of a task at runtime or having a range of number of tasks that can be run at runtime. And also cancellation sets are a form of flexibility because they can remove tasks from the process for that particular instance only. So YAWL supports flexibility by design.

Flexibility as a Service

And YAWL also includes a custom service called the worklet service that supports flexibility by design, deviation and under specification. So in other words, every type except by change. Change being the most contentious one. So the aim was to overcome the assembly line restrictions so that it broadens out the benefits of our business process modeling and execution to those sorts of business processes and other processes that are more flexible. In other words, not trying to force every process, every real world process into that assembly line metaphor.

Activity Theory

Now YAWL is based on a way of thinking about work, the way about people doing work, called activity theory. So in the years after the Russian revolution, the Russians were trying to come up with a new way of thinking about how people worked as a community to correspond with their Marxist views of how work is achieved. And so they came up with this idea what came up with this theory called activity theory. It's not really a theory in terms of we'll make a proposition and see if it see if it works. It's more of a way of describing how people work together. So based on observation, it describes how people actually work without going into much detail about that. We derive some principles from activity theory that sort of ... they related to the way that a flexible workflow system should support work. So activity theory says activities are hierarchical which means you have one activity with a number of actions. So you know, or in process modeling terms, one process with a number of tasks. Whether an activity is a task or an activity depends on the eye of the beholder, in other words, depends on how you're looking at it and who's who's looking at it. Activities are communal which means they involve typically - or mostly - they involve more than one person. They involve people working to together towards a common goal. Activities are contextual which means they always operate within a context. But people who work are aware of the context that they're working in. And people typically think about the context, when they choose how to do a particular task. So people being people, it's human nature to try and find the easiest way to do something or the most efficient way to do something. So given a task you might do it for a while and you'll think of an easier way to do it, or a better way to do it, or a more efficient way to do it. And so you change the way you do it to suit the context of the particular process instance you're working on. Activities are dynamic. We talked before about work practices are evolving over time and they evolve asynchronously which means sometimes they might not evolve much and then suddenly they'll change in a rather large way. So when we're thinking about the context of a particular process instance, then the actions or the tasks, the way we carry out that work, is chosen with a view to the context as I just said. So any particular person may have a repertoire of actions, or a box full of different ways of doing a task that they have in their toolbox if you like. So for any particular instance of an action or task, you will choose the most appropriate way of performing that task. For example, I follow the process to get here today and I'm sure all of you also follow that particular process to get here today. Some of those processes will be similar to each other in some respects and different to each other in other respects. One way is the mode of transport we got here. Some people might have driven or caught a tram or a train or a bus, walked and so on. If you usually drive and you got up you went to the car and the car wouldn't start, then you'll fall back to plan B, whatever plan B might be. The way you decide on what plan B is, is by considering the context of the situation. Okay, if you were coming in to do an exam, then you will do anything - almost anything - to try and get in here. If you're just coming to a boring class and if it's cold and wet outside, you might turn around and go back to bed. It depends on the context. If you've got a bike and it's not too cold, then you might ride the bike. So you can see, all of those decisions are sort of if statements. If the context is right, then I'll take this course of action to be able to perform that task. And that's typically how people work. Plans guide work. So rather than a process model being a prescription that must be followed in every instance, it's just a sort of a guide to get to a goal. You know you have to get here, the car's broken down. Then you'll think of some other way of getting here. You don't have to really consider that until such time as you find the car is broken down. So a process description should merely be a guide to getting to the goal rather than a prescriptive definition of exactly what you should do at every step along the way. And if we're following the assembly line metaphor, then you can see that a plan is very prescriptive in that scenario. The last point I want to say about activity theory is exceptions have great value. Activity theory says, whenever something happens you didn't expect, then that is a good thing, because that leads to a learning experience. You'll learn something more about the process. If you find your car has broken down, then that in, you know when you think about it next week, it was a good thing, because it forced you to think of some other way of handling that situation. And the way you thought about how to handle that goes into the back of your mind and it's there next time, so you don't have to expend so much effort next time that happens. You'll say, well that worked last time, so it'll work again this time. So exceptions have great value because they are a learning experience.

The Worklet Service

Okay, so based on all of that, the worklet service in YAWL tries to follow those principles. So it sort of makes the assembly lines format of a process model more flexible, so that we can get to our goal, but choices will be made along the way that we don't really have to think about it at design time that will get us to our goal based on the context. But it does that by providing a repertoire of available actions to wait for particular tasks that are at design time delegated to the worklet service. So you can have a number of different actions depending on the context of the instance, the correct action will be chosen to handle that particular work at that particular time. And so those choices are made dynamically. So you don't have to have a user or an administrator watching over every single process. It will use a set of rules to determine what the most appropriate action is. And you can dynamically extend the set of rules. So that you can keep adding new actions to the repertoire at any time - even while a process is executing. Okay, so a worklet, we're talking about a worklet. A worklet is an action in that repertoire of actions. So each action is called a worklet. The worklet essentially is a YAWL process. Typically a small YAWL process but doesn't have to be. It can be of any size and complexity. It's a self-contained process and complete. So it's designed to handle one specific action at a particular time in the process based on the context of the case. It's in the repertoire. As I said, it's chosen contextually at runtime by evaluating rules that are associated with that particular task. And so you can think about a worklet as a dynamically substituted sub-process for a placeholder in a process. A task being the placeholder that calls the worklet service for the correct worklet to run in that situation. If the workflow service does not have a particular worklet that suits, it will return the task back to the engine and then it can handle that task as it would any other task. So the idea is, a particular task is associated with a worklet service and in this case, there's five different worklets to choose from. Depending on the context of the case the correct, or the most correct worklet will be chosen from that repertoire of worklets.

Bear in a Shoebox

Okay, so how do you get a bear into a shoebox? Haven't covered all of that. Any ideas? No? Same as last time? Not quite. Not quite. So yes, we're still going to take the lid off the box but there's an elephant inside the box. So we have to take that out first, because everybody knows you can't put an elephant and a bear in the box at the same time. So take the the elephant out, then put the bear in and then put the lid back on. So you have to consider the context or the state of the process when you get to that point. So it's considering the state of the process or the data in the process, the context of that particular case that determines how to deal with particular instances.

Capturing Conceptual Data

So we're talking about context. How do we capture context in a computational form? There's two general ways to do it. You won't get into too much detail about that. But one is divide and conquer, where you think about the entire universe of data and context that you will ever cover in a particular process. And then you try and break that down and describe everything there is to know about that particular context. Usually it's impossible to achieve because you can't think of everything. But also it's not really necessary because most or a lot of context isn't required to make decisions, to make intelligent decisions. But also depends heavily on the ability of experts to be able to explain what they do when they do their work. And it's been found that the more expert somebody is, the harder it is for them to explain how they perform their work. So if you're a very highly skilled heart surgeon for example, it's very hard to get that surgeon to be able to specify exactly what he does when you know when he's when he's operating on somebody. There's stories of stories about um fire chiefs at fire sites who just get a feeling that something's gonna happen, get everybody out of the fire before the roof falls in or something like that because he's got that much experience. He knows that something feels wrong but he can't explain why something feels wrong. So it's very hard when you ask an expert, how do you do this, how do you do that, they find it very hard to explain. And that's one reason why a divide and conqueror approach is difficult. The compose and conqueror approach on the other hand is where you start off very simple, start off from the bottom, start local, and build your knowledge base up from very simple facts. Each time you work with a fact that doesn't quite meet the current need or the current context, then you add a refinement of that fact. In doing so over time, you build up a knowledge base from very simple facts to more refined facts. And in fact that's the way the worklet service works through the use of so-called ripple down rules. Now ripple down rules are a hierarchical set of rules in a tree structure. They are a sort of a binary tree and that's been modified slightly. Ripple down rules are used in all sorts of scenarios including those there - I won't read them out - but at all different levels of computing. Different systems in different ways of different contexts. They actually came from medicine. So it was the medical fraternity that began the research into ripple down rules. Now you don't need to understand fully, how ripple down rules work to be able to use the worklet service. But I'll just briefly work through them, so you have some idea of the concept behind them.

Worklet Selection

So a worklet selection is made through a ripple down rule evaluation. So a ripple down rule is a collection of simple rules in a binary tree structure, or a modified binary tree structure. So each each node on the tree has a true branch and a false branch like a binary tree. The true branch is called the exception branch the false branch is called the or branch. There is a root node that just has a default true as a condition. And so that branch is ... so the true branch is always followed from there. If so I'll go back one step. Each node in the tree has a condition that is evaluated and a conclusion. So if a node's condition evaluates to true then the exception branch is taken. If it evaluates to false then the or branch is taken. And again, you keep working down the tree until such time as you reach a leaf node at the bottom of the tree.

RDR Structure

When you reach a leaf node, if the rule is satisfied, then its conclusion is returned. The conclusion in our case is a worklet. It so returns the worklet, the workflow surface loads that worklet into the engine and then runs that as a separate case. If that rule is not satisfied, then the conclusion on the last node that was satisfied on that path is returned. So here's an example of the ripple down rules for a the casualty treatment process which is an example process in the worklet service. You can see at the top there's a a node which has true as a condition so that will always of course evaluate to true and a default condition which is never used. So because it's true, we follow the exception branch if that node is true, then because there are no other paths to follow on the exception branch there, then that is returned. If that node's condition evaluates to false, then it will move down the or branch to the next node.

Adding a New Rule

Now importantly, this allows you to add new rules because you might have a rule return - sorry - a conclusion returned that meets the context of the case based on previous runs of the case but is not exactly the best way of handling the current situation because of other contextual factors in the case. So in that instance, we have to add a new rule. And the way a rule is added is, if the terminal node that we have reached through the path to the tree, if that rule was satisfied, then it is added as an exception branch to that tree. It's called an exception branch because it means this this new rule is a refinement of the more general rule above it - more general parent rule. If the conclusion returned was not the least node, in other words, it went back up to three because this one was not satisfied, then it gets added as an or node there. And that's the way the rules are added, which we can demonstrate using this example.

A Simple RDR Example

So every RDR tree has a root node as I said with a true condition. So we'll always evaluate the true. So here we're starting off with a very general rule base with one rule in it basically. The condition is: if it's a bird. And the conclusion is: it will fly. It's a very general rule. In most cases, if it's a you know if you see a bird we can assume that it can fly. So that we're running our system for a while and everything's hunky-dory, everything's working well, and then we get a new case which is a penguin. Now a penguin is a particular type of bird. And penguins can't fly. So our rule base, we get a case where we have penguins and a rule base we'll say we have well that's a bird so it can fly and it will return can fly. So an administrator or user will say: well, hang on a minute. Penguins can't fly. So we have to add a new rule as an exception to the more general "birds can fly". So that goes there as an exception because the terminal node was successfully evaluated. So now we've got another node in the tree. Birds can fly unless they're penguins in which case they can't fly. And everything runs well until we get a new case of a cat. So is it a bird? No! So this tree is no longer followed because that does not evaluate to true. The default condition is returned from the root node which means there's no suitable conclusion for the concept of the cat in our rule tree. So because of that, that cat is added as an or branch off the bird node. Is it a bird? No! Is it a cat? Yes, cats can't fly. So you can see we have two nodes here with the same conclusion. So you can have two or more nodes with the same conclusion but the conclusions are the same because of different different contexts. Well again do we get a plane. Is it a bird? No! So it follows the false branch. Is it a cat? No it's a plane. So that gets added under the cat. And the conclusion again is: it it can fly. We get a baby bird. Is it a bird? Yes, that will follow this path. Is it a penguin? No! So that goes under there. Baby birds can't fly. They are a bird but they're a penguin. Finally, we're going to get a very strange case. If we have a penguin who can fly because he can get into a plane, then: is it a bird? Yes. Is it a penguin? Yes. But this particular penguin can fly, so he gets added there. So you can see every branch on this path is a more refined exception of its parent node. And over time, if you can think about a business process, over time you can get quite large rule trees that make the selection, the correct selection, more precise.

Rule Evaluation Data Sources

Okay, so where do we get our context from? We can get it from the data of of the task to the work item. We can get it from the case level data. We can get it from the process state. So which tasks are complete, which tasks are active, how long the tasks have been running for. Anything you can get from process state can be used. External sources, process logs, so previous runs of this instance, historical data, external databases, other services - for example there's another service called the cost service, which calculates how much a particular instance is costing the organization. You can use that data to choose the appropriate worklet. And also any user defined functions and values can also be used. So there's a wide variety of sources of data that you can use to make those contextual decisions via the id archery.

Suitability of RDR for Worklets

So how suitable is RDR for worklet? They're very suitable because they allow that hierarchy of rules from more general to more specific. They're local, they capture local data. You don't need a knowledge expert to create the rules. The rule creation doesn't happen until a worker and end user notices that the condition returned - sorry - the conclusion returned doesn't match exactly the needs of the particular instance. So you don't have to have an expert sitting down saying, this is a rule, this is a real business or rule. Rules are only defined, when the return conclusions aren't precise enough and the rules that can evolve over time and add more precise choices to the repertoire of worklets.

Exception Handling in YAWL

Okay, so that's the worklet service. Now thinking about the way that makes processes more flexible allows us to also think about how we can use that type of service to handle exceptions. So exceptions are a particular subset of the wider flexibility issue or problem and so the worklet service idea of ripple down rules and making appropriate selections based on context can be extended to the handling of exceptions. Exceptions as I said, exceptions occur or deviations occur, when the process model, either accidentally or deliberately, has some choice choices left out of it.

The Exception Service

So the exception service is part of the worklet service, uses the same repertoire idea the same ripple down rule technique. It can handle both expected and unexpected exceptions at run time while it's running - hopefully with minimal input from administration. So for a particular specification as well as having a set of selection rules for a task as we've just seen, it can also have a different rule tree for each of up to 10 different exception types. And some of those exception types are at the work item or task level. So each task will have its own tree for a particular exception that will return. We'll talk about what sort of exceptions can occur in a moment. So at runtime, if an exception occurs or if a trigger for a possible exception occurs and a specification has a rule defined for that particular exception type, then it will be tested. And if the rule is satisfied, then a particular exception handler is raised to deal with that particular exception. If there's no associated rules for that particular exception or if there are rules but the context of the case means no rule is satisfied, then the exception is simply ignored.

Unanticipated Exceptions

Okay. When an unanticipated or unexpected exception occurs, then we can add a new handler to the repertoire of exception handlers for that particular task or case using the same techniques as we used to add a new rule to the selection side of things.

Exception Perspectives

Okay. So if you look at the middle table first, these are the exceptional events that can occur during the life of the process that the exception service can handle. So the first four are constraint tests. So constraints are tested when a case starts and when a case completes and also when a work item starts and a work item completes. What that means is, the data in the case at start and end or the data in the work item when it starts and when it completes is sent to the exception service and that data is run against the rules that are against those constraint exception rule sets. If the values of the data in the task or case are outside of a constraint, then a particular handler will be triggered there. A timeout can also occur if you have a timer on a task and it times out before the task completes, then the exception service will receive a timeout notification and it can handle that timeout. Case internal - sorry - case external item external means that something external to the process has happened that will affect the successful completion of the process and so you may want to have an exception handler to handle that particular event that is triggered by a user that raises that particular event and has occurring and then if there are rules for that, then that will be handled. A resource unavailable event occurs, when the resource service tries to allocate a task to a particular resource and that resource is unavailable for some reason. I'm not sure if you probably haven't covered resource unavailability yet in the resource service but that's where the color that comes into play where a resource may be away or on holidays or whatever. Or a secondary resource is not not available as well. Item abort means a particular service has been delegated a task and that service can't complete that task. And so that they raised that type of exception and the constraint violation is also raised by an external service when the data it receives or the data it changes while performing that task violates some constraint. So all they're the 10 different sorts of exception type and then you have targets on the left. So you've got the work item or task level, case level. All cases of this particular specification in our version, in ancestor cases and I'll talk more about interesting cases in just a moment. So any of those targets can take these actions or have these actions taken against them. You can you can suspend a work item or case for example. Continue means unsuspend. You can restart a work item, you can complete the work item, you can fail a work item, remove it. The difference between complete - complete means it will complete norm normally with the data it has in it at the moment - a fail means it will be marked as a failed completion but the process will still continue. A remove is like a cancellation if you cancel a work item then any work on that particular path won't continue from that point. Or you can take the action to compensate. Now a compensation handler is a worklet. Okay, so you can have a number of different worklets as compensation handlers and they will run depending on the context of the case through the rule set. Same as the other way.

Exlets

Okay. You can define so-called exlets which are exception handling routines in the editor, in the plug-in in the workflow plug-in. So easily do to be done graphically. So here we've got a pre-constraint pre-case constraint violation and what we want to do is suspend the case, run some some compensation handler, and then continue the case from that point. So if we're starting a case with some data and the data isn't isn't right, if it's outside the bounds of some constraints, then we can run some compensation handler to collect the correct data from the user or to to manipulate data in some way so that is that it is correct for the case. The icons across the top are remove work item, remove case, remove all cases, suspend case, all cases. Okay, work item case, all cases, continue, case worklet of all cases, restart, complete and fail a work item or a compensation down the bottom there. So as well as being able to do them graphically like that draw them graphically, you can also add them to the table in a tabular format in the in the plugin as well. You'll see that in a moment. So worklets can run in parallel with their parents, so in this case, we're choosing to suspend the case and then run at the compensation while the parent case is suspended. Because we want to gather some data that we need before the case as the parent case starts. But you can choose to run compensations without first suspending the parent case as well.

Worklet-Exlet Hierarchy

Okay, and when you run a worklet as an exception handler, then you may run other worklets from that worklet as a compensation may have its own exception handlers which in turn will run compensations and those compensations may have exception handlers and so on. In this case we have a parent process with a task to do show, tasks with a number of item pre-constraint events. There's a data in that do do show the event fails constraints in some way then depending on how it fails, we could run the appropriate exlet or exception handling routine. That's the ripple down rule tree for the item pre constraint exlet for that particular task. So depending on how many tickets are sold, you probably can't read that up there, but depending on how many tickets are sold, we can run a particular worklet to either book a smaller venue or cancel a show or take some other action. So in the compensation there, we run a worklet as as a compensation handler inside the exlet.

Ancestor Cases

And because we can run worklets as compensation handlers and worklets can contain their own exception handlers, then you may have instances where you have a number of worklets running as a parent child relation. In that case, if you choose to suspend or cancel ancestor cases it will suspend or cancel all of the worklets from the one you're actually suspending up to its parent, it's eventual in our top ancestor. So that's what the ancestor cases means.

Editor: Worklet Management Plugin

Okay, so as I said a moment ago, the editor has a worklet plugin which allows you to specify rules to create worklets and save worklets to load worklets into the editor for creation and editing, to load rule sets from outside in files. Importantly, there's a way of rejecting and replacing worklets. So this is the rule substitution that I was talking about if if a worklet is returned that doesn't exactly match the context of the case, but it is the correct worklet based on the current rule tree, then we can add a new rule to a running case. And it will then make the appropriate choice.

Adding a New Rule

And this is what it looks like very quickly. So up the top there we can choose what particular rule type, whether it's an exception type or the selection handling type, we choose a task if it's a task level exception and then we can create a condition there. So this is the condition we want to evaluate to true so that this exlet is run. Here you can see the exlet in tabular format. So the exlet in this case is, we're suspending the case, then we're running the compensation handler called "change to smaller venue" and then after that's finished running, we can then continue the case. We could also describe that in the graphical editor by clicking on the little boxes button there. Importantly, this is the cornerstone data in other words the data that was required or that it was that was there when the rule was created. Importantly, this data has to evaluate to true from that condition. In other words, around the condition must evaluate to true based on the data that's in this table. And that is because the service uses that data to find the rule that was returned that was not the most correct rule. So that it knows where to plug this one into. So you don't have to think about where in the tree this rule goes. The system will work out where it goes based on the value in that data. So that's adding a new rule. Usually, when you start a new rule as we saw in our example, we started with one rule and that is the ideal way to do it. Start with one rule and then gradually build up with experience over time. But in practical terms you may have you know a handful of rules that you add to begin with.

Browsing a Rule Set

This is browsing a rule set. This is you can see in the in the green box. It's the same as it was on the previous screen when we added a rule. So you can see there the rule type, the task, the conditio,n its conclusion, in other words it's exlet, and the data that was available for this rule to make that particular condition true. You can see on the left hand side is a diagram of the rule tree and so you can choose rules there to see what is inside each rule node and down the bottom here, it will show you the composite rule. So in other words, we're not in our previous example we weren't saying if it's a bird and not a and not a pet not a penguin and a baby bird we don't have to we don't have to build those, we don't have to join rules together because the rules are evaluated step wise as it goes down the tree. So this just builds another way of thinking about that particular rule. So by working down the tree we say tickets sold at a certain value, then run a particular exlet, except if the tickets are less than in other words following the exception path, except if the value is even less, then run some other worklet. There's exception handler or sorry running some other exlet, except if again some other condition then some other exlet. So this sort of just reads down the rule tree as to what is actually going to happen at run time. So it's a good way of understanding how the tree evaluates.

Dynamic Worklet Replacement

And this is the important part, this is where you replace a currently running worklet with a new one. And in so doing, you're building the rule tree and building the repertoire of worklets that are are available. When you open up this dialogue, you'll see at the top all of the currently running worklets in the engine and you can see which ones what are what rule they were started for. Whether it's a selection or an exception. So you choose one, it will tell you the rule and the exlet that were chosen to run that worklet. So that was the most appropriate choice. Over here, we've got the cornerstone no rule last cornerstone data. In other words, the data content that was available when that rule was made compared to the data that is available in the currently running case. So by clicking on that, everything in blue are the values that are different now used to the ones that occurred in cornerstone case. So we can see here the value for fracture is still the same, the weight's still the same, and the other things are still the same, but the name's different, the blood pressure's different, the height is different, and so on. So obviously, one of those values in blue the value that made the user think the choice that was made was in was incorrect for that particular data. For example, this particular patient presented with a rash, so the worklet that was returned was to treat the rash. But you can see here, the value for heart rate is is really high. And so even though we need to treat the rash and that's true, maybe we need to think about getting that getting his heart rate under control first. So the heart rate is what causes us to need to create a new rule. Now the rule will be when we type it in their heart rate greater than 150 or something like that. And a new worklet. So to treat heart rate. And then that will add the new rule to the rule set, add the worklet to the repertoire, and replace that workload in the engine with the new worklet. All on the fly. And importantly that new rule will be there every time a similar case occurs in in the future. So you won't have to do it every single time someone presents with a high heart rate because it's already there.

Worklet Approach: Key Benefits

Okay, well that was a very brief overview of the worklet plugin to the YAWL editor. So the key benefits of the worklet approach means, you can describe the standard or the happy time if you like path through the process and any exception handlers and any selection plug-in worklets using the exactly the same modeling methodology. So in other words, if you know how to create a YAWL process, you know how to create a worklet or a compensation handler as well. There's reuse involved, it's modular. So it makes it easier to verify, because you're verifying smaller pieces of a larger process rather the entire process. As one verification that allows for evolution of processes because you don't have to change the parent process. You just need to add more worklets to the repertoire. And that implicitly changes the parent process. If you get an unexpected event, then an administrator, as we just saw, can add a new rule and a new exlet or worklet based on that particular context of that case that caused the selection to be incorrect in the first place. And all of those complexities as to downtime and migration and different versions and restructuring models are avoided. Okay, that's the end of the talk. Any questions?

Questions

Thank you very much! I would have a question. Okay. So you can actually absolutely do that as a worklet. So in very simple cases you've got choice between a control flow split and join or you can replace that with a worklet if you like. Either way is effectively the same except that if you think of new ways of handling this loop, then you can let the worklet repertoire grow over time. If you think new ways of handling this loop by a split in the control flow, then you have to change the entire process. So the advantage would be that the process looks nicer if I don't show the loop? Yeah. That's right and the ability to visualize what's going on behind that worklet enabled task is a problem for another project. So okay, so would you advise starting with a very simple model and then let everything happen while the workflow is running? It depends on what you're designing the process for. If it's for understandability, if you're designing a process that you want to show to people and say, this is how the process works, then you don't really want to hide that much from you know your your managers and your business consultants and that sort of thing. But over time, if you want your process model to capture the essence of what it's supposed to do and use worklets as a more exceptional behavior then that would be the way to go with those, yeah. Another question is the ripple down rule. Yeah. I remember that there was an explanation that every condition is evaluated. So depending on the value, it goes either left or right until you reach your leaf and then the evaluation goes back until it meets the first node that is true. Is that really the operation of the way it's done. Or is it rather done with the rules you showed us? It's done the way that it's done the way that I showed you. Essentially, what happens is, as it works its way through the tree, it returns the last node that was tested but also it keeps track of the last node that was satisfied. So it returns both nodes back. So it's not evaluated twice. No it's not evaluated twice. But it passes back two nodes and then they just they're compared if they're the same node then it was a leaf it was reached. If they're different nodes then it was not, yep. Ah no because no. Because as ripple down rules work from the more general to the more explicit. To do that would be to destroy the integrity of the tree. But you can modify a tree by by adding new leaves and work the same way, yeah. You can delete nodes from the tree because removing a node just moves up one. So you don't lose the integrity of the tree by doing that. But you would if you inserted a node somewhere else in the tree. Okay. I wish you a merry Christmas and a happy new year and we'll see next year. The exercise today is there, but I will not be there. Okay, thank you again!