Workflow Engine

Workflow Engine is a software component bringing workflow functionality into your application. Put simply, Workflow Engine is a combination of 2 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 HTML5-driven process designer into your web application. Workflow Engine is designed for easy integration in .NET applications.

This article outlines basic activities required for integration of Workflow Engine with your software, so that you could start using its functionality. Let's define main terms and principles of operation.


Scheme and Process

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

  • Process states;
  • Cross-state transitions;
  • Commands for starting transition process;
  • Timers that start 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.

Referring to real examples, such a scheme can describe the 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.

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 the process as of 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 which isn't expected to perform any actions at the time. That's why when it's not impacted by external commands or internal timers the process is in an idled state which is saved to your database. When exposed, the process loads and runs, going idle and stopping consuming your app's resources afterwards. For each instance on the document page there is a process, 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 exposure. Each Activity also contains Actions that should be performed as soon as the process moves to this Activity. Besides, you can see State items on the scheme. Unlike Activity that indicates 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, consider that every Activity corresponds to a particular State.

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

  • 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 Actor object. We will describe authorization process in further documentation;
  • Timer-based — the engine allows for scheduling process activities. We will describe timer management in further documentation.

When the trigger associated with 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, 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, Condition and Otherwise types execute similar to the operators if () then {} else {} in programming languages.

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

Main Objects

Most of the time you deal with WorkflowRuntime. This object allows for process creation, command list retrieval, command execution, setting a process state, etc. It also provides API for the designer. So, you 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 including WorkflowRuntime into a web app:

Including Workflow Engine into a Web App

Example of including WorkflowRuntime into a service:

Including Workflow Engine into a Web Service

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

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