◷ Reading Time: 4 minutes
Workflow enables rich interaction between human and systems. This behaviour puts instances of a workflow in different states which then Managers allow your application to manage these states in your own ways.
Managers
There are two types of managers for every workflow:
- Event Handlers
- Services
Event handlers are based on different events that might be raised inside the engine when a workflow instance goes to different states. And Services are a generic service that you might need then available to complete a Workflow, they are not based on events.
Event Handlers
Workflow supports injecting behaviour on the below events:
- PreStart: Before a workflow is started.
- PostEnd: After a workflow is finished.
- PreResume: Before a workflow instance is resumed.
- PreStore: Before a workflow instance is being stored.
- PostStore: After a process is stored.
Instance Storage
When a workflow instance goes into different intermediate states, the hosting application should store the Workflow Execution Context in a durable storage. And on the resuming a workflow instance, engine must be able to to retrieve the latest context from the storage to be able to continue the workflow instance.
This behaviour is supported via IWorkflowInstanceStateManager event handler.
Model Identity
Each workflow model has an identity that can be resolved via its manager. This behaviour is supported via IWorkflowIdentityManager event handler.
Ownership
When a Workflow instance is in progress, it is owned by someone (actor) to process the instance and move it to the next stage. When a workflow instance is owned with an actor, no one else should be able to process that instance for the period of the ownership.
This ownership behaviour can be managed by IWorkflowInstanceOwnerManager event handler.
New Instance Id
When a new instance of a Workflow is just being created and started, it is not yet stored in the storage. In some scenarios it is desirable that the new instance be storage in the storage as soon as it is started. That ensures the Workflow Context has the WorkflowInstanceId available all the times.
This behaviour is managed by NewWorkflowInstanceIdWriter event handler.
Timeout
When there is a Timeout activity on a Workflow, that can be monitored using a handler called ExpiredReceiversManager. This checks the back-end storage periodically for the next expiry time. And will load the workflow and progress it automatically when the timer is expired.
For more information check ExpiredReceiversManager
Services
Task Service
When a workflow execution reaches a Human Task uses this interface to create and assign works (i.e. WorkItem) to a Participant.
For more details check ITaskService service.
Directory Service
Identifying the participants of a task is done by using the Directory Service. A Directory Service can lookup participants by Name as a unique identifier (e.g. login, email, etc.) or by their Roles.
For more details check IDirectoryService service.
Registering Managers
Managers can be registered on the Workflow Manager on the Runtime instance using the Registry property.
Example of adding Custom Service:
engine.Workflow.Registry.AddService<ITaskService>(new TaskSystemRepository()); engine.Workflow.Registry.AddService<IDirectoryService>(new InMemoryDirectoryService());
To register a custom handler you can use AddHandler method:
engine.Registry.AddHandler(new NewWorkflowInstanceIdWriter());