Skip to main content

Workflow Engine

Workflow Engine is a software component that brings workflow functionality to your application. Put simply, Workflow Engine is a combination of two libraries, one of them based on .NET Framework/.NET Core, and the other one on JavaScript. The first library provides functionality for process management and execution, while the second one introduces an HTML5-driven process designer into your web application. Workflow Engine is designed for easy integration with .NET applications.

This article outlines the basic actions required to integrate Workflow Engine with your software, so you can start using its functionality. Let's define the main terms and principles of operation.


Scheme and Process

A Process Scheme is a sequence of steps that your process follows. It describes:

  • Process states
  • Cross-state transitions
  • Commands for starting the transition process
  • Timers that start the transition process at a definite time or time intervals
  • Command access rules
  • Functions that are triggered when a process state is changed
  • C# or JavaScript code to check whether a user is authorized to run a command or change a process state
  • Process parameters description
  • Localization data

To give a few real-life examples, such a scheme can describe a document approval workflow, a process that runs some code at defined time intervals or a process whose actions are triggered by a command originating from an external system.

The scheme can be associated with software code that is subject to execution. If you open the Designer page, everything you see there is, essentially, a scheme.

A Process is a combination of saved parameters and a reference to the process scheme. The process knows its current state and parameters, if they have been set. This, for example, might be a business document approval process, or a process waiting for a command from an external system. One could think of a process as a program instance launched within a system, but it's not exactly like that.

Since Workflow Engine is designed for long-running transactions as well, it would be extremely wasteful to allocate resources to a process that isn't currently expected to perform any actions. That's why, when it's not affected by external commands or internal timers the process is in an idled state which is saved to your database. When triggered, the process loads and runs, then goes idle and stop consuming your app's resources. For each instance on the document page, there's a process that's activated by a command from the associated document form.

Main Scheme Elements

Main Scheme Elements

Activities and Transitions are the key elements of a process scheme.

Activities are process stages at which the engine stops and waits for a triggering event. Each Activity also contains Actions that should be performed as soon as the process moves to said Activity. Also, you can see State items in the scheme. Unlike Activity, which indicates the physical condition of the process, State depicts its business status. Activity is an obligatory item, while State is optional. Hereafter we will explain, how to use these items; in the meantime, please note that every Activity corresponds to a particular State.

A Transition connects two Activities and defines the process execution pattern. A Transition is run by a Trigger. There are three types of Trigger:

  • Automated — Transition will take place when the process enters the first Activity and executes Implementation completely.
  • Command-based — Transition is driven by an external command. You can manage command access rights for different users through the Actor object. You can read about the authorization process in further documentation.
  • Timer-based — the engine allows you to schedule process activities. You can read about timer management in further documentation.

When the trigger associated with the Transition is activated, the system validates its Condition. There are three types of Conditions:

  • Always - Condition is never checked and Transition always happens.
  • Condition - contains a link to a function which is called before a Transition happens. If it returns true, the Transition will happen; if it returns false, the process will remain in the former Activity.
  • Otherwise — Transition happens, unless the conditions of other Transitions have been met. If set together, the Condition and Otherwise types execute similarly to the operators if () then {} else {} in programming languages.

After the conditions get validated, the process passes to the next Activity, executing the Actions from the associated Implementation block. The process either stops and waits for an external trigger, or runs automatically triggered transitions if there are any.

Main Objects

Most of the time you'll be dealing with WorkflowRuntime. This object enables process creation, command list retrieval, command execution, setting a process state, etc. It also provides an API for the Workflow Designer. So, you'll have to create one WorkflowRuntime object in your application or service and call its methods to enable document management functionality.

You have to use persistence providers to connect to the process database. Depending on your database type, you have to create an object and pass it to WorkflowRuntime.

Example of integrating WorkflowRuntime into a web app:

Integrating Workflow Engine into a Web App

Example of integrating WorkflowRuntime into a service:

Integrating Workflow Engine into a Web Service

For a better understanding, download a sample that shows WorkflowRuntime integrated into an application, or use the source code from the WorkflowServer project — a clear example of WorkflowRuntime integration into a web service.

Further, articles provide a detailed step-by-step guide on how to create and configure WorkflowRuntime and Persistence Provider, and integrate a scheme designer into your app. If you are short on time, please proceed to the guide right away.