Process Manager
Table of Contents
This page defines the service architecture pattern
Process Manager in the pattern language.
One component holds the state of a multi-step process and decides each next
step from the results so far. In ORE Studio that component is the workflow
engine, ores.workflow.
1. Also known as
- Orchestrator.
- Workflow engine.
2. Context
A process has several steps in different services, it outlives one request, and it must survive a restart.
3. Problem
Where does the state of a process that spans services live, and who decides what runs next?
4. Forces
- Steps that call each other couple every service to the order.
- The process must resume after a restart.
- A later step needs an earlier step's result.
- A person must be able to see where a run is.
5. Solution
A process manager owns the run. It builds the step list from the run's request and a registered definition, persists each step before it dispatches it, sends the step's command, and waits for one completion event. It records the outcome and dispatches the next step, built from the request and the earlier results, addressed by step name. Steps never call each other.
Figure 1: Process Manager: the engine builds the steps from the definition, persists and dispatches each one, and records each outcome.
Source: [[./pattern_process_manager.puml][pattern_process_manager.puml]]. Regenerate with
plantuml -tpng doc/knowledge/service_architecture_patterns/pattern_process_manager.puml.
6. Failure handling
| Concern | What the pattern does |
|---|---|
| Errors | A failed step follows the definition's policy; see Saga. |
| Timeouts | Every step states a deadline; see Timeout. |
| Retries | A restart re-dispatches every step left in progress, under its own identity. |
| Idempotency | Dispatch is at least once, so every step must converge on repeat. |
| Observability | The run and its steps are readable at any time, and every transition publishes an event. |
7. Pitfalls
- A step list that changes between dispatches. The list must be a pure function of the stored request, or a recovered run changes shape.
- A handler that calls the next step. The order then lives in two places.
- An unknown workflow type accepted. The start must fail when the chain cannot be built, or a mistyped run looks like a success.
8. Security
The manager dispatches with the step headers and no caller token; a step that must act as a tenant uses Scheduled Work Acting as a Tenant.
9. Resulting context
- Benefits
- One place holds the order and the state; steps stay single-purpose.
- Liabilities
- The manager is on the path of every run, and its availability matters.
10. In ORE Studio
- The step protocol — the engine builds the step list from the request, dispatches each step and records each outcome.
- Report execution — the engine runs the report chain the run configuration selects.
- Identity — the engine runs the steps the request declares.
- Tenant provisioning — the engine runs the provisioning plan's steps.
- Transporting a package — the coordinator is the manager: it holds each bundle's state and dispatches the next step from the bundles' replies.
11. Related patterns
- Saga — the failure handling the manager runs.
- Idempotent Receiver — what the manager requires of each step.
- Request-Reply — the alternative for work short enough to answer at once.
12. Sources
- Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley, 2003, Process Manager.
- Chris Richardson, Microservices Patterns, Manning, 2018, chapter 4, "Managing transactions with sagas" — orchestration.
13. See also
- Service architecture patterns — the structure note that orders this pattern language, and where to read this page in it.