A simple process definition example

NGinn is under development and almost every part of it keeps changing. It also happens to the language itself. Currently NGinn is based on XML description of process structure and there is no graphical representation. It is important to have graphical design tools for process graphs, but I think it is too early to develop them -XML form is enough for now. Graphical NGinn representation will be developed after the language becomes stable enough.

OK, so how does NGinn process definition look like?

First of all, NGinn process is a Petri-net, so the definition contains the net structure. Petri net consists of places, transitions and connections between them. Then process-specific extensions are added, such as specialized tasks and process data specification. Let's see an example:

1. Here's a simple process

2. And here's the XML description of this process:

<?xml version="1.0" encoding="utf-8"?>
<process version="2" name="TimerTask" xmlns="http://www.nginn.org/WorkflowDefinition.1_0.xsd">
 <places>
   <place id="start" type="StartPlace"></place>
   <place id="end" type="EndPlace"></place>
 </places>
 <tasks>
   <task id="init" type="EmptyTask" splitType="AND">
   </task>
   <task id="timeout" type="TimerTask" joinType="AND" splitType="AND">
     <timerTask>
       <delayTime>00:01:00</delayTime>
     </timerTask>
   </task>
   <task id="timeout2" type="TimerTask" joinType="AND" splitType="AND">
     <timerTask>
       <delayTime>00:01:00</delayTime>
     </timerTask>
   </task>
 </tasks>

 <flows>
   <flow from="start" to="init" />
   <flow from="init" to="timeout" />
   <flow from="init" to="timeout2" />
   <flow from="timeout" to="end" />
   <flow from="timeout2" to="end" />
 </flows>
 <processDataTypes>
 </processDataTypes>
 <variables>
   <variable name="delayAmount" type="string" required="true" dir="In" />
 </variables>
</process>

OK, so let's see what we have here:

• the main process element is the root of process definition file. Contains process identification attributes, such as name and version number
• The 'places' section - contains list of places in the process definition. Here we have only starting and ending place (note the 'type' attribute identifying the start and end place)
• The 'tasks' section - contains a list of tasks, that is transitions in Petri-net terminology. Tasks can be of several types, offering different functionalities. Here we used empty task (init), which does nothing but is present for synchronization purposes, and two timer tasks which wait for specified period of time. Each type of task is defined in 'task' element, however internal structure of 'task' element depends on the task type.
  Note the 'joinType' and 'splitType' attributes of tasks. These are very important attributes - they specify the synchronization logic between tasks. There are three types of split and join: AND, OR and XOR, we will discuss each type in later posts.

• The 'flows' section, connecting places and tasks. Each 'flow' has its starting node (from) and ending node (to).

That's the Petri-net structure description. However, there is an inconsistency with Petri-net specification. Note that the 'init' task is connected directly to 'timeout1' and 'timeout2' tasks, without intermediate places. Petri nets forbid that - there can be flow only from place to a transition and from transition to a place, place-place and transition-transition connections are not allowed. In NGinn two tasks can be connected. In such case and implicit place is inserted between these two tasks. In our example, there would be an implicit place between init and timeout1 and second implicit place between init and timeout2. The purpose of such construct is only to simplify process definition, however in some cases we will need to specify places explicitly.

There are two more sections in the process definition XML:

• 'processDataTypes' section - contains definitions of data structures used for representing process data. Here it is empty, and data structures will be discussed in later posts
• 'variables' section, containing definitions of process variables. Process variables are like arguments of a function - there can be input variables (input arguments), output variables (return values) and local variables. Also, input-output variables are possible. Here we have only one  variable - 'delayAmount' string.

OK, done with process definition. But what does this process do?

1. Init task is executed. It does nothing, but then the execution is split in two parallel flows(remember the 'AND' split). So the 'init' task consumes one token from the 'start' place and produces two tokens in the implicit places for timeout1 and timeout2 tasks.
2. Timeout1 and Timeout2 execute simultaneously - each of them waits exactly 1 minute and then completes, consuming token from the implicit place between 'init' and itself and producing token in the 'end' place. 
3. There are no tokens except for the 'end' place, so the process is completed.

Process definition

NGinn process model is based on Petri nets extended with process-specific information. Picture below shows a basic Petri net. It consists of places (circles) and transitions (rectangles), connected with arrows.

 

I will not explain here how Petri net works - it can be found in many sources, for example here. Most important principle is that tokens (black dots) represent current process status. Each transition consumes tokens from its input places and produces tokens in output places, so effectively tokens move across the Petri net. In NGinn, we add two special places to the picture - a start place and an end place. Start place is the process starting point - process starts when a token is placed in the start place. End place is the finish point - process finishes when all tokens reach the end place. In the picture above, we could say P1 is the start place and P4 is the end place. 

Transitions in NGinn are called tasks. Tasks are the basic building block of a process and they represent various actions that are needed to complete the process. There are many types of tasks in NGinn, they will be described later. When a task completes, it consumes one or more tokens from its input places (which tokens are consumed depends of task 'join' type - described later) and produces one or more tokens in output places (how many tokens are produced depends on task 'split' type - also described later).

Places in NGinn have 'original' Petri-net meaning. They are just a places where tokens are held during periods of inactivity (when nothing happens in a process or when we are waiting for a task to complete).

NGinn idea is based on the YAWL language -process building blocks are generally the same, so you can read about YAWL to get the idea on how the process definition looks like. However, NGinn provides completely different implementation of the engine and process tasks.

Introduction

Hi, this blog will be dedicated to the 'NGinn' workflow engine. Here I will document its functionality and the development process. You can find nginn at http://code.google.com/p/nginn.

You can wonder why someone would create a workflow engine for .Net if there is one freely available from Microsoft and built in .Net - Windows Workflow Foundation. My opinion is that WF does not provide the functionality expected from a business process engine. First of all, WF is low level, that is provides basic constructs that could be used to build workflow engine but are not very useful for modelling business processes. WF looks like a set of components useful for programmers (actually it looks like a graphical representation of some procedural code) and developers probably are happy with it. However, business process analysts would find it difficult to program directly in WF. Secondly, WF does not provide process description standard - programmers are free to model process logic and process data as they want, there is no standard process representation. This limits the portability of process definitions and makes it difficult to integrate different applications and processes.

NGinn will focus on providing more standard and restrictive process description language in order to enhance portability, and at the same time it will offer higher-level process building blocks that can be understood and used by business analysts. NGinn will also include additional components needed for running business processes:

• Resource management - so the information about people and organizational structure can be accessed and used in process definitions
• Embeddable and standalone process execution engine
• GUI for end users (a 'proof of concept' worklist application)
• Integration and communication components (email notifications, web service calls, etc)

* highlighter
* cnj