Workflow is a special type of flow that can go to many resumable intermediate states (i.e., Waiting, Suspended, etc.) at execution time before it goes to a completed state. This allows external actors to communicate with workflow and pass information as required before the workflow is completed on those intermediate states. A workflow may take a long time to be completed (i.e., long running business transactions).
To allow an external actor (human or computer system) to communicate with workflow in different stages, FlexRule Runtime uses different types of nodes:
- Tasks (i.e., receive, human, etc.)
In those intermediate states, external actors (human, or system) will be able to communicate with Workflow and navigate based on the workflow model.
When a workflow goes into an intermediate state, the workflow instances will not stay loaded in memory. FlexRule tries to store the context of the instance in some storage and then keeps listening for related incoming events until it receives them. Then engine will load the workflow instance and resume it from the last step.
A workflow must support long-running processes or business transactions. That means applications must maintain contexts of workflow in different stages of execution (i.e., run or resume). So, execution contexts must be maintained in a durable storage, as a workflow may take a long time to be completed. An application should provide the relevant (latest) context to the engine when required in order to continue the Workflow (i.e., Resume).
A Workflow can be suspended temporarily during execution using a Pause step. This will put the Workflow into Suspended state. Later on, the application can Resume the workflow and it will continue the execution onward.
A workflow can have as many Pause nodes as required. These can be placed between all different types of nodes (e.g., inside loops, after/before database calls, etc.).
Tasks can be:
- Sequential: waiting for one signal at a time
- Parallel: waiting for multiple signals
The Receive task allows workflow to be 'Waiting' for a signal to be received. That's the simplest form of the task.
In this use-case a workflow is waiting for one signal at a time. Like any other activity in a flow, you can link multiple Receive Tasks to each other. In this case, the workflow goes into the Waiting state multiple times, but each time one Signal can be received.
Waiting for multiple signals in parallel allows the application to provide options in a particular state. In the above example, the workflow goes to the Waiting state once, and will be waiting for each Approve or Reject signal.
A Timeout task allows waiting for a certain amount of time and then the workflow instance will automatically receive a signal to continue the execution.
An example of this is when you want to limit the response time for a Receive Task.
Timeout node must be used in the parallel scopes between Split and Join Listeners.
Human tasks are used in human workflows to define Work and enable the interaction of humans and systems. These automate computerised and non-computerised activities in a workflow. When a workflow reaches the Task node, it can create a WorkItem and Assign it to the participants of the Work.
Human tasks enable the modeling of complex human driven workflows:
- Enabling outcome driven modeling of a human interaction
- Defining task's Owner and Participants
- Assigning tasks to participants
- Setting tasks expiration policy
- Delegating tasks
- Defining escalation logic
- Allowing multi-participant interactions
- WorkItems application to allow working on and interaction with assigned tasks
Check details on Human Task