Workflow engine for Document Approval System

Workflow engine for Document Approval System

Workflow engine for Document Approval System


The Workflow module is an important part of many information systems. As much as 30% of the time and money allocated to a project is easily spent on implementing this module, testifying to the significance of this resource. And yet, in many projects the quality of document flow leaves much to be desired.

This article about how to selecting a workflow engine for Document Approval System and problems when developing of these systems. The article will be more useful to architects, senior developers and managers who are responsible for project.

Source Requirements

Source Requirements for workflow

There are two types of requirements to a Workflow module:

  • Functional requirements
  • Business requirements

Functional requirements include:

  • Creating a workflow scheme
  • Transitions between states
  • Saving the current status in the database
  • Getting the current status

Business requirements include:

  • A scheme with the list of the states of a process and the transitions between the states
  • Description of actions that the system has to take when the document achieves the given state

The team's work on the implementation of the project has to be governed by these requirements.

Choosing a Product

Selecting a workflow engine

Implementation begins with the selection of the workflow engine. Those who use the .NET platform for development have the following options:

  • Windows Workflow Foundation 4 from Microsoft
  • Workflow Engine .NET from OptimaJet
  • Nintex (only if you use SharePoint)
  • Webcon (only if you use SharePoint)
  • NState
  • Objectflow

Nintex and Webcon are relevant only if you use SharePoint. In NState and Objectflow, the process is defined in the code of the project. They do not have a designer.
*Custom development is beyond the scope of this article.

Only two options remain: WF (Windows Workflow Foundation 4) and WFE (Workflow Engine .NET). These options are our focus in the remainder of this article.

The First Stage. Implementation of Basic Requirements

A description of the way to arrange the simplest route and save the state of document flow in the database:

This is a problem-free method (if you nevertheless encounter any a problems, email me and I'll add a detailed description). Let us move on to the issue of how to deal with business requirements.


Let us examine the scheme in detail. The scheme features:

  1. States & transitions

    WF: Supports. States are implemented as Activity objects and transitions as Transition objects.
    WFE: Supports. States are implemented as Activity objects and transitions as Transition objects.

    These objects is very similar.

  2. Commands & Actors (Allow to)

    WF: Not supported. Workaround: Add a parameter with the name of the command. Use the "Condition" block to select the required Transition. Add definition of Actor to the condition in the "Condition" block. Difficulties generating a list of available commands. Due to the existing limitations the lists of commands for each stage must be stored somewhere separately.
    WFE: Supported. To get a list of available commands and states, use the method GetAvailableCommands. In the designer for each transition may include some restrictions for Actors (IWorkflowRuleProvider need be initialized).

  3. Terms for custom actions and calls for external actions

    WF: Supported.
    WFE: Supported. IWorkflowActionProvider must be initialized.

The upshot: the difference between the engines is insignificant. In cases involving Actors and Commands, WFE is much easier to use.

The Second stage. Requirements that surface after the pilot operation

The Second stage. Requirements that surface after the pilot operation

The pilot operation usually adds next requirements:

  1. Transitions history with future states and potential employee for approved

    List of route

    WF: Not supported. No examples.
    WFE: Supports Pre-Execution. An example of this is available on the project website.

  2. Inbox\outbox folders for each user

    WF: Not supported. No examples.
    WFE: Supported. An example is available on the project website.

  3. Versioning a scheme

    WF: Not supported. There are several examples of the schema update, they required that the old routes must save. Version handling in Workflow Foundation 4.
    WFE: Supported.

  4. Impersonation (replacement)

    WF: No supported.
    WFE: Supported.

The upshot: 4:0 in favor of the WorkflowEngine.NET.
Implementing these requirements in WF is a challenging task even for experienced developers. WFE has always offered support for these requirements.


When you start working on a project that includes workflow functions, you need to understand what the set of requirements is that you will eventually have to comply with:

  • Creating/modifying workflow schemes
  • Routing a document
  • Getting the current status
  • Storing routes and states of documents in the database
  • History recording and preparation of the route for the document
  • Inbox\outbox folders for users
  • Schema change of an active document
  • Impersonation (replacement)

Difficulties or the inability to introduce at least one of these requirements can lead to a major headache. That's why the choice of the workflow engine has to be determined not only by the current requirements, but also by whatever requirements may be introduced by the customer further on.

I have tried to provide an objective evaluation of the solutions available on the market. If you have any questions, you are welcome to ask me by e-mail

Document approval system with WorkflowEngine.NET 1.4

  • By Dmitry Melnikov
  • 1/14/2015
  • workflow engine, document approval system