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.