From FlexRule Wiki
Jump to: navigation, search


Workflow is a special type of flow can go to many Waiting states over time before it is completed. This allows your application to communicate to workflow and pass information as required before the workflow is completed. A workflow may take a long time to be completed (long running business transactions).

To allow an actor (human, or computer system) communicate with workflow in different stages, FlexRule Runtime uses different types of Tasks.

A workflow must support long-running process or business transactions. That means your application must maintain contexts of workflow in different stage of execution (i.e. run or resume). So, those contexts must be maintained in a durable storage as a workflow may take a long time to be completed. And application should provide the relevant (latest) context to engine when required (i.e. resume). FlexRule Runtime can store contexts in a MSSQL database out-of-the-box automatically.


A Task is a step in a workflow that allows external actor (human, or system) communicate to workflow. A task puts the workflow instance in Waiting state. At this state workflow instance will not stay loaded in memory. Engine tries to store the context of the instance in some storage and the keeps listening to related incoming events until it receives them. Then engine will load the workflow instance and Resume it by sending a signal to the reloaded workflow instance.

Receive Task

Receive task allows workflow be Waiting for one or more signals to be received. A Receive Task can be used in:

  1. Sequential: waiting for one signal at a time
  2. Parallel: waiting for multiple signals

In this use-case a workflow is waiting for a single signal at a time. Like any other activity in a flow you can link multiple of Receive Task to each other. In this case the workflow goes to Waiting state multiple times. But in each time one Signal can be received.

Sequential Receive Task


You can use ListenerSplit to listen to multiple signals in parallel. When an associated signal is received, workflow continues on executing that path (i.e. scope)

Allowing multiple options

Waiting for multiple signals in parallel allows application to provide options in a particular state. In the above example, the workflow goes to Waiting state once and will be waiting for each Approve or Reject signals.


A Timeout task allows waiting for an amount of time and then workflow instance automatically will receive a signal to continue on the execution.

Timeout limits amount of time workflow is waiting for approve or decline responses

An example is when you want to limit the time of responding to a Receive Task.

Human Task

Human tasks are used in human workflows. A human workflow enables interaction of humans with workflow to automate computerised and non-computerised tasks using workflow. When a workflow riches this node it goes to Waiting state and uses the registered task service to creates related tasks for participants (WorkItems).

Human tasks enables modeling complex human driven workflows:

  1. Enables outcome driven modeling of a human interactions
  2. Defining Task's Owner and Participants
  3. Assignment of task to participants
  4. Allows setting tasks expiration policy
  5. Allows tasks delegation
  6. Allows defining escalation logic
  7. Enables Tasks renew
  8. WorkItems application to allow working on and interaction with assigned tasks

Check details on Human Task


When generic flow is used, the Run method on RuntimeEngine can be called and it executes the flow until it reaches the End node. But in a Workflow you can also Resume which means you send a signal using Resume method and workflow instance will be loaded back and continues execution based on the signal that is sent.


Engine runs the workflow from its initial state (i.e. Start node). When a workflow is run, there will be a Workflow Instance associated with the model. This instance of the workflow model will go though different states:

  1. Active: When the engine is transitioning from a node to another
  2. Waiting: When the instance reaches a node that requires a external interaction
  3. Fault: When execution is finished because something has gone wrong during the execution.
  4. Completed: When execution is finished successfully.


To resume a workflow, the WorkflowExecutionContext must be maintained. This can be as easy as holding the object in the memory. But for long-running processes and business transactions they must be maintained in a durable storage. (.e.g. database, blob storage...)


A Signal is simply an object of an IReceiverSignal which specifies the Title, and Category of a Task. It can match a Task by below combinations:

  1. Title
  2. Title, Category
  3. Title, Category, NodeName

Or you can implement a custom Match method when required.


A workflow uses managers to enable advanced capabilities (i.e. automatic timeout, human workflow, long running process...). Also manager allows you to inject your custom behaviour into a workflow for any type of customization. Manager objects can be in two types:

  1. Event Handlers
  2. Services

Event handlers and Services can be registered on the engine and there are some handlers on manager registry by default. Each of these custom behaviours using can be registered on WorkflowManager.

Event handlers are objects that allow workflow customization based on workflow events. Services are objects that allow you inject a custom behaviour and access them during workflow execution on different steps of the workflow model.


When a workflow is executed, it raises events on state changes. These events give your application an opportunity to manage state of the workflow instance.

Below is the list of events:

  • PreStart: Before a workflow is started
  • PostEnd: After a workflow is finished (execution is completed)
  • PreResume: Before a workflow instance is resumed
  • PreStore: Before a workflow instance is being stored
  • PostStore: After a workflow instance is stored
  • HandlerAdded: When custom event handler has added to the WorkflowEventsManager

Event Handlers


  1. ExpiredReceiversManager: Automatically sends signal for Timeout task when its configured time is expired.

Long running process

A long running business transaction requires maintaining the context to resume the workflow instance when a signal received. And then storing the context to a durable storage when workflow goes to waiting state. Below behaviours are used to manage this scenario:

  1. IWorkflowInstanceOwnerManager: When a workflow is about to resume, the actor can take acquire a lock and resume the workflow. This means no one else can resume or interact with the workflow until it is completed or it goes to Waiting state again.
  2. IWorkflowInstanceStateManager: When a workflow instance is going to go to Waiting state, it should store its context to a durable storage. This interface defines the behaviours of managing the state of context in the storage.
  3. IInstanceIdentity: This defines a workflow address to your workflow model. When a workflow instance context is stored, this interface allows you to associate the context to the actual workflow model so you can distinguish between different contexts in the storage and identify them when required.
  4. NewWorkflowInstanceIdWriter: Writes a new workflow into the configured storage and retrieves the WorkflowInstanceId and sets it on the context. This enables all workflow instances have the WorkflowInstanceId available.

To enable the long running workflow, you need to:

  1. have an MSSQL installed
  2. create required tables (check database setup section of this page)
  3. use EnableLongRunningProcess method to enable long running behaviour

Human Task

  1. TasksHandler: inject an instance of TaskService to workflow instance to use to manage Human Task behaviour
  2. ITaskService: Allows implementing the complex human task behaviours (i.e. expiration, delegation, escalation, WorkItem management...)


Enabling long running process

When an instance of RuntimeEngine is create (e.g. engine) then by calling EnableLongRunningProcess on Workflow you can enable the long running processes. Just make sure you have setup the required database tables.

Your application may manage only one workflow model or may deal with different workflow models.

Single Workflow Model

  1. public void LoadLongRunningWorkflow()
  2. {
  3.   var cnnString = ConfigurationManager.ConnectionStrings["ProcessStateStore"].ConnectionString;
  4.   var config = new LongRunningProcessConfig(
  5.        cnnString, // connection string to the database to manage contexts and timers automatically
  6.        );
  8.   engine.Workflow.EnableLongRunningProcess(config);
  9. }

Multiple Workflow Models

When your application deals with multiple workflow models, it must provide an identity for each workflow model. This identity is created based on the root attributes of the Workflow models:

  1. name
  2. namespace
  3. version

This identity is created and set on the engine level automatically when EnableLongRunningProcess is called. Also, it can be accessed by Address property of engine.

  1. class YourWorkflowApp
  2. {
  3.   public void LoadLongRunningWorkflow()
  4.   {
  5.    var cnnString = ConfigurationManager.ConnectionStrings["ProcessStateStore"].ConnectionString;
  6.    var config = new LongRunningProcessConfig(
  7.        cnnString, // connection string to the database to manage contexts and timers automatically
  8.        );
  10.    engine.Workflow.EnableLongRunningProcess(config);
  11.    // Workflow engine identity
  12.    var address = engine.Workflow.Address;
  13.    // database Id for the workflow address
  14.    var addressId = engine.Workflow.AddressId;
  15.   }
  16. }

Timeout callback

When a Timeout node expires, workflow can automatically continue the execution. This behaviour requires ExpiredReceiversManager to be registered on the WorkflowEventsManager. But in a long running processes this registration is done as part of enabling the workflow to handle long running processes. The application can receive a callback when a Timeout expiry happens, for the callback, you need to set the TimeoutNodeExpiredCallback property on configuration object (LongRunningProcessConfig).

config.TimeoutNodeExpiredCallback = timeout_node_expired; // callback to your application, when a timer is expired

Database scripts

By default FlexRule supports MSSQL for workflow persistence behaviours. The following database scripts must be run to create required tables for Workflows management:

  1. Long running process: To manage workflow contexts and timers. Database script