BPMN - a close family

I have always considered BMPN (Business Process Modelling Notation) to be the 'best' language in its domain - very expressive and well thought out, able to describe real world situations without using strange hacks and without oversimplification. However, I have never thought about implementing it in NGinn - full BPMN 1.1 implementation seemed too complex to be an open-source project objective, especially single-person project.

So I have turned to less complex ideas after reading a bit about YAWL and decided to implement similar language for .Net. But it turns out that YAWL (and NGinn as a consequence) use very similar concepts that can be found in BPMN. That's because all of them are all based on Petri nets, but differ in everything that was added over basic Petri-net specification. For example, BPMN defines several control structures based on non-local events, such as errors (exception handling), compensation and cancellation - quite useful. NGinn has no special constructs for exception handling and no notion of compensating. But when we analyze what 'workflow patterns' can be imlemented in these languages, it turns out that there are no patterns in BPMN that could not be implemented in NGinn or YAWL. It's only a matter of convenience - for example, error handling or compensating is easy to do in BPMN and not so obvious in NGinn (custom logic required). Maybe a material for 2.0 version.

Here's a link to a very nice website about BPMN - Dive Into BPM. Enjoy the dive!

Today I'd like to describe some examples of processes that are known to be working in current version of nginn. The focus is on control structures, not the actual task functionality (which is very incomplete as for now). I have selected rather complex and not very obvious examples because the basic ones such as parallelism (AND-split), sequences and decisions (XOR-splits), well, should just work or there wouln't be much to talk about.

Deferred choice with a timeout

This is a very common pattern - deferred choice with a timeout. It can be used for adding some time limits to manual or other tasks. When token is placed in 'start', both tasks are enabled - 'eval_candidate' and 'timeout'. When 'eval_candidate' completes first, timeout is cancelled. When timeout completes first (deadline is reached), eval_candidate is cancelled. 

Deferred choice - complex situation

This proces is an example of more complex implicit choice. There are two places with implicit choice (p1 and p2), each having two possible tasks. However, they share the t2 task. Functionality here is that system enables all tasks: t1, t2 and t3 after tokens arrive at p1 and p2. This construction ensures that either t1 and t3 can complete, or t2 can complete. When t2 completes, t1 and t3 will be cancelled. When t1 completes, t2 will be cancelled and t3 will stay enabled. When t3 completes, t2 will be cancelled and t1 will stay enabled.

OR-join with 'escaping' tokens

This is rather a complex example, so I was very happy to see it working. What we have here. First of all, there's t1 task with an OR-split. The split can choose V1 or V2 path, or both of them. The eval_candidate4 task is a corresponding OR-join.

The catch here is that we have a deferred choice in place p1, and eval_candidate3 task can 'steal' token from p1, effectively moving it out of OR-join's scope. Situations where either V1 or V2 path is chosen are not very interesting. However, if both V1 and V2 are chosen, the eval_candidate4 OR-join should wait for two tokens to arrive before eval_candidate4 can be enabled. But if eval_candidate3 steals the token, eval_candidate4 should 'change its mind' and wait for one token only. Why? Because no more tokens can arrive in such situation, so all possible OR-join's input paths don't contain more tokens.

OR-join with tokens 'stolen' by a cancellation (cancel sets)

Here the situation is similar to the previous case - we have an OR-split and OR-join and two paths V1 and V2. However, there's this little red arrow from t3 to p2. This arrow is a cancellation (cancel set), meaning that when t3 completes all tokens should be removed from p2 (effectively cancelling the eval_candidate2 task). 

Effect is that when both V1 and V2 are chosen, you need to complete eval_candidate and eval_candidate2 before eval_candidate4 will be enabled. Alternatively, you can complete t3, then you will not have to do eval_candidate2. After you complete eval_candidate2, completing t3 has no side-effects.

Short update about current development status

Recently I have made some important changes to the NGinn engine and feel that it's getting close to what I'd like to achieve. Here's the list of most important changes made:

1. ProcessInstance class makeover. Most important change is that tokens no longer have an identity. At the beginning it was assumed that each token is an independent object and tracking the relation between tasks and tokens has been quite complicated. However, all tokens are the same, they don't convey information - so it was sensible to get rid of their identity. Now only numbers count - all we need to know about tokens is how many of them sit in each place. Results: 50% of code thrown away while retaining the same functionality. Performance and clarity improved.
2. Custom process state serialization. I have decided to use custom XML serialization instead of binary serialization used previously. Main reason is that binary serialization doesn't support versioning and upgrading the library breaks old version of processes. It adds some work to task implementation, but we have complete control of persistence.
3. Introduced distributed transactions (each step of process is run in a separate transaction).
   
4. Basic infractructure is working. Now I need to concentrate on details and providing complete functionality. Especially, task implementation is quite behind.
   
5. Number of examples was added to NGinn.XmlFormsWWW project. It demonstrates how to start and cancel process instances and how to handle worklist functionality (manual tasks). Simple TODO List web application is working (sort of).
   

Summing up, NGinn API is maturing and there are no heavy public interface modifications. It's time to start documenting it. I hope to use the engine in some commercial project, so this should speed things up and improve the quality. Sounds nice.

Tasks in NGinn

Tasks are what the workflow is 'really' made of - they provide the functionality. The rest of workflow definition - places and arrows - just defines how the tasks are interconnected and what are run-time dependencies between them.
So let's try to describe what are the most common types of tasks and what can they do. NGinn is not complete yet, so this will rather be a wish list than a typical technical documentation.

1. Manual task
   
   Manual tasks are tasks that are assigned to people (application users). Usually application will provide some kind of 'TODO' list where each user can see tasks currently assigned to him and from where he/she can pick up next task to be done. NGinn provides 'Manual task' building block, but it does not contain actual TODO list or GUI implementation - this is application specific and NGinn does not restrict the implementation.
   Manual tasks have the following configurable parameters:
   
   • Assignee - id of person responsible for the task
   • Assignee group - id of group responsible for the task (either Assignee or Assignee group must be specified)
   • Task title (short summary)
   • Description (textual description of the task)
   Much more can be said about manual tasks, for example we haven't touched at all the subject of resource management (people database) and organizational structure (groups). I'm going to give you more details on this in next posts.
   
   
2. Timer task
   
   Timer tasks are used to introduce configurable delays into the process. In runtime, timer task 'starts' when it is enabled (that is, when it gets all required input tokens) and then waits specified amount of time before completing. Task has two parameters:
   
   • Delay amount (for example: 00:00:30, meaning 30 seconds) or
   • Due date (fixed moment in time when the task will complete). Exactly one of these parameters needs to be specified, depending on situation.
     
     
   
   
3. Subprocess task
   
   As the name suggests, it's a task for starting a sub-process. When this task is enabled it initiates an instance of sub-process and waits until the sub-process completes. Then the task will also complete.
   To start a sub-process we need to know it's name (definition ID) and we need to have input data in correct structure (as defined by process input variables). In this case subprocess task's input data becomes the input data for the newly created process, and when the sub-process completes it's output data becomes Subprocess task's output data. Therefore we need to make sure the subprocess task has the same input/output data structure as the sub-process.
   
   
4. Notification task
   
   Notification task is used for sending email / sms / other notifications to users.
   
   
5. 'Receive Message' task
   
   The 'receive message' task waits for a message. It is used in scenarios where communication with external systems is necessary and when our process needs to wait for some information sent by external party. Each external message that can be received contains some data and must contain a special ID, called Message Correlation ID (MCID). The MCID is a runtime parameter of the Receive Message task, that is we need to specify what is the MCID for each Receive Message task. We are free to choose any MCID, but it must uniquely identify the task waiting for the message. By default (when not specified), MCID is assumed to have the following structure: [process instance id].[task id], for example e3bc903829badca321.wait_task.
   The structure of message is defined by Receive Message task's output variables - the message should simply contain values of these variables. When message is received its contents are retrieved and put in Receive Message task's output variables. Then the task completes.
   The most important fact here is that the MCID must be known to the external party when it sends us the message. So either the MCID is mutually agreed on, or our process needs to send the MCID to the external system before it can receive the message from it.
   
   
   
6. Script task
   
   Script tasks are used for adding custom logic to the process. Currently they can be programmed in 'Script.NET' language. Script tasks are synchronous, they cannot be 'put to sleep' and reactivated by NGinn execution engine. Script code can access and modify task's variables, but it can also communicate with other objects in application's runtime. They can be used for communication between business processes and the rest of the application.
   
   
7. Empty task
   
   Empty task does nothing - completes just after being started. But all variable bindings do their work and they can be used for synchronization without side effects - and this is the main purpose of empty tasks.
   
   
8. REST/WS call task
   
   Synchronous communication with external systems, using XML/HTTP or SOAP. The task sends a HTTP request containing it's input data and expects to receive XML with the output data (XML structure is defined by task's output data structure). Currently there's no implementation of web service calls - I'm waiting for the right idea.
   
   
9. Custom tasks
   
   Custom tasks can be used to introduce some custom or application-specific components into NGinn process description language. Custom tasks can be implemented in any CLR language, they just have to implement few interfaces and conform to some rules. This is a good topic for separate post.
   

And this is it, I consider the list to be complete and broad enough at the same time. Almost all real-time task examples can be implemented using one (or more) of NGinn tasks, and what can't be implemented or is difficult to stuff into built-in task type can be done as a custom task.

Great resource on workflow patterns

Here's a link to 'Workflow Patterns' website - a great source of information about workflow definition patterns. Please take a look at animated examples of how each pattern works - this is very much like it is implemented in NGinn. No wonder, however, as the website was created by YAWL guys.

First presentation of NGinn

Today I had a short presentation of the NGinn project at 'Zine day' - Warsaw based meeting of .Net geeks from around the Poland . My presentation was a part of open source project contest (and has even won a second prize, thanks guys!). What really pleased me was that many people got interested in the project and were asking lots of questions about how they could use the nginn engine in their projects. That gives me some clue on what features should be implemented in nearest future and how important it is to release the first version. The presentation was in polish, here's the file - sorry, no english version for now.
I enjoyed the meeting very much and would like to give my thanks to organisers, attendees - especially those who gave their votes to nginn.

Data handling in workflows

In order for workflows to be usable, they must convey some information and process it. NGinn provides a simple to understand data model that allows for easy integration with external applications.

Each instance of NGinn process contains some data. It is called process instance data. This data consists of variables, each variable having a name and holding value of some type. These variables are global to process instance. There is also 'task data', that is a set of variables containing data for a task instance.

More on variables

Variables are the base of NGinn data handling concept. Each variable has a name, type specification, 'requiredness' and direction. Here's an example of process variable definition:

<variable name="requestorName" type="string" required="true" isArray="false" dir="In" />

This line defines a 'requestorName' variable holding a string value, which is required. The variable is single instance (isArray="false") and it is an input variable.
Let's explain this a bit:

• direction (dir="In"). In NGinn, variables can be input (dir="In"), output (dir="Out"), both ways (dir="InOut") and local (dir="Local"). Think of them as procedure arguments. Input variables are used for passing data to process or task instance. Output variables can return execution results from a process or task instance. Local variables are local to process or task, that is they are internal only and invisible to the outside world.
• type (type="string"). Variables can be of some type. NGinn supports basic types, such as string, int, date, bool and complex types (like 'structs' in C or C#), explained later.
• array (isArray="false"). Variables can be single instance, holding only one value, or multiple instance, holding an array of values of the same type.
• required. Variables can be required or optional. Required variables must be passed to process or task. Optional variables can be ommitted, and there is an option for providing default value for optional variables. Default value will be used when the variable is not specified.
  

Process data consists of a set of process variables - each process has its own set of variables. The names and types of variables are defined in process definition. Each task executing in the process instance has its own data, held in task variables and completely separated from the process data. It means that a task can operate only on its own variables and cannot access parent process' or other task's data.
So, there is a question - if there is a complete isolation between task and process data, how do they exchange the information?
The answer is: through data bindings.

Data bindings

Data bindings define how process data is mapped to task input data, or how task output data is mapped back to process data.
Each task has a set of input bindings and output bindings. Input bindings define what information from process instance data will be put in task's input variables. Output bindings define what will happen with task output data - what process variables will receive the values of task output variables.
Input bindings are executed before the task is started. Output bindings are executed after the task completes.

<input-bindings>
<binding variable="requestor" bindingType="CopyVar" sourceVariable="requestedById" />
<binding variable="requestorName" bindingType="CopyVar" sourceVariable="requestedByName" />
</input-bindings>
<output-bindings>
<binding variable="managerApprovalDecision" bindingType="Expr">
   <expression>decision</expression>
</binding>
</output-bindings>

This is an example of task's input and output bindings.

Each binding defines variable that receives the data ('variable' attribute). In case of input bindings it is a task input variable and in case of output bindings it is a process instance variable. In this example, first input binding defines that 'requestor' task input variable will receive the value of 'requestedByName' process variable. 'CopyVar' binding type means that the binding is a simple value copy - from sourceVariable to variable.
The output binding above is more interesting. It is a binding for managerApprovalDecision process variable and this is expression-based binding (type="Expr"). It means that in order to get the value for managerApprovalDecision, expression will be evaluated. Here the expression is 'decision' - so it returns a value of 'decision' task variable. Of course, expressions can be more complex.

Data types

NGinn has built-in support for several basic data types, but the list of types can be extended by custom type definitions.
Supported basic types are:

• string
• int
• double
• date
• datetime (time stamp)
• future releases may add more simple types

Complex data structures can be built out of simple types, in a recursive way. Each process definition contains 'processDataTypes' section, where custom data types can be defined.
There are two kinds of custom data types that can be defined in NGinn - records (structs, similar to C/C# structs) and enums (enumeration of possible values).
Here's an example of a struct:

<processDataTypes>
  <struct name="OrderItem">
      <member name="code" type="string" required="true" />
      <member name="name" type="string" required="true" />
      <member name="quantity" type="int" required="true" />
  </struct>
</processDataTypes>

This is a definition of 'OrderItem' type, which is a struct with three fields: 'code', 'name' and 'quantity'. Each field si required and is single value (not an array).

And here's an enum type with two possible values: YES and NO:

<enum name="YesNo">
    <value>NO</value>
   <value>YES</value>
</enum>

Process data and XML

Data structures in NGinn are designed so that they can be easily converted to XML and back, so data exchange with external applications is simplified. Process or task data definition can be converted to XML schema, so by defining process or task data structure we also get XML data schemas for data exchange.
For example, let's take some process data definition:

<processDataTypes>
<enum name="YesNo">
 <value>NO</value>
 <value>YES</value>
</enum>

<enum name="WeekDay">
 <value>Sun</value>
 <value>Mon</value>
 <value>Tue</value>
 <value>Wed</value>
 <value>Thu</value>
 <value>Fri</value>
 <value>Sat</value>
</enum>

<struct name="DeStrukt">
 <member name="Decision" type="YesNo" required="true" isArray="false" />
 <member name="Day" type="WeekDay" required="true" isArray="false" />
</struct>


</processDataTypes>
<variables>
<variable name="value" type="DeStrukt" required="true" dir="In" />
</variables>

This definition contains two enumeration types and one struct type. And here's how it converts to XML schema:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="YesNo">
<xs:restriction base="xs:string">
<xs:enumeration value="NO" />
<xs:enumeration value="YES" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="WeekDay">
<xs:restriction base="xs:string">
<xs:enumeration value="Sun" />
<xs:enumeration value="Mon" />
<xs:enumeration value="Tue" />
<xs:enumeration value="Wed" />
<xs:enumeration value="Thu" />
<xs:enumeration value="Fri" />
<xs:enumeration value="Sat" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DeStrukt">
<xs:sequence>
<xs:element name="Decision" type="YesNo" minOccurs="1" maxOccurs="1" />
<xs:element name="Day" type="WeekDay" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:element name="DataStructs">
<xs:complexType>
<xs:sequence>
  <xs:element name="value" type="DeStrukt" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Why is it important? Because it defines the structure of XML message with process input data, so we can start new process instance by sending xml similar to this:

<DataStructs>
<value>
    <Decision>YES</Decision>
    <Day>Fri</Day>
</value>
</DataStructs>

With the XML schema auto-generated from process definition it's much easier to integrate NGinn with external tools. For example - we can take this schema and feed it into Microsoft InfoPath form designer. Then we can design an InfoPath form that can be used to start new process instance, and the InfoPath designer will know the resulting XML data structure from the schema.
Not only process input data can be defined in XML, this applies also to process output data and to task input/output data. This way, XML can be used to integrate NGinn with external applications without introducing custom protocols.