YAWL - The Language behind Lynx Workflow

YAWL stands for "Yet Another Workflow Language". It is an open specification of a graphical language for modeling business process control flow. YAWL was created by mathematicians in the University of Eindhoven and the University of Technology of Queensland. The need for such a language became clear when previous research conducted at the Institute of Technology of Queensland identified a complete set of the workflow patterns and then compared these patterns to languages of existing workflow management products.

YAWL is based on Petri Nets (a formal mathematical tool for modeling and analyzing processes), but it adds a number of constructs, which make it easier and more intuitive to model some of the more complex patterns. You could start by thinking of YAWL process definition as a beefed up flowchart with more rules, constraints and symbols. Of course, once you draw the process definition in YAWL, it can be used verbatim as the core of your software system!

YAWL diagrams consist of tasks, conditions and arcs, to connect the first two items. A "Task" generally corresponds to just that - a task within a business process. A "Condition" is a holding place where the process waits after tasks are completed or before a new task begins. "Arcs" connect tasks and conditions and show process flow. Arcs always connect a task and condition, or condition and task, but never connect two tasks or two conditions. The symbol for a condition is a circle; a task is (generally) a rectangle; and an arc is a directed line (arrow):

	Task (atomic - see below)
	Condition
	Arc

YAWL diagrams always start with a special condition called the "Input Condition" and end with another special condition called the "Output Condition". Those symbols are:

	Input Condition
	Output Condition

Some tasks can be executed in parallel; others should be executed sequentially. Also, some tasks can be started only if all preceding tasks have been completed. Others can be started after one task has been completed. In Example 1, Task2 and Task3 can be started in parallel after completion of Task1. Task4 can be started only after both Task2 and Task3 are completed:

To deal with multiple execution paths, YAWL uses splits; to indicate pre-requisites YAWL uses joins. In the example above, Task1 uses an "AND" split, meaning that all of the paths after Task1 should be executed. Task4 has an "And" join, meaning all of the paths of execution prior to it should be completed before it starts. Splits and joins are part of the task. The different type of splits include:

	AND-split: Execute all tasks following this one.
	XOR-split: Execute only one task following this one.
	OR-split: Execute one or more tasks following this one.
	Not specifying any split works the same as an AND split.

In the case of an XOR-split or an OR-split, the workflow needs custom logic to determine which paths of execution must be taken. The different types of joins include:

	AND-join: All preceding tasks must be completed.
	XOR-join: One of the preceding tasks has been completed.
	OR-Join: This is the most complex join. Simply put, all pipelines leading to this task must be completed. If there is a "pipeline" (path of execution leading to this task) that leads to this task but has not yet arrived at the task, then this task cannot be executed.
	Not specifying any join works as an AND join.

Following are some examples using these joins and splits. Here is an example using an XOR-split/XOR-join

Here is an example with an OR-split/OR-join:

The OR-join is the most interesting and useful. However, proper implementation can prove extremely difficult, and its use often slows overall performance. Lynx Workflow adds another type of join - "Quasi-OR", abbreviated - QOR-join:

QOR-join: Works like an OR-join in most cases, but it facilitates better performance than the OR-join. For more on these differences, see article...

A QOR-join would perform in Example 3 exactly the same as OR-join (see Example 4):

Another useful feature of YAWL is the removal task. Imagine a claim approval process. At some point after the start of the process, some information may arise that will cause a roll back of approvals and require some additional investigation. In example 5 below, the workflow shows how to handle such a situation. After approvals have started, a user can process the task "Cancel Approvals", which will either roll back the approvals to the beginning, or cancel/end the approval process altogether:

The dotted blue box indicates those tasks that can be cancelled. The dotted blue line connects them to the removal task (in this case "Cancel Approvals").

YAWL has more underlying details and aspects. For a more formal introduction to this wonderful new technology, please see its formal specifications and number of articles on the topic.

---