Process Automation, Workflow Engines and BPM Suites
Scope
How models become executable, what a BPMS provides, and the workflow patterns that map notation to engine behaviour.
Core rules
- A BPMS typically offers a modelling environment, process repository, execution engine, worklist and task management, integration adapters and services, rules engine, and monitoring dashboards.
- BPMN task types: user (worklist item), service (automated call), business rule (decision engine), script, manual (outside the system), send and receive.
- Workflow patterns: sequence, parallel split, synchronisation, exclusive choice, simple merge, multi-choice. A BPMN XOR split is exclusive choice; an XOR merge is a simple merge; an AND split is a parallel split; an AND join is synchronisation.
- Orchestration has one process controlling all participants; choreography defines peer-to-peer interaction without a controller.
- Executable models need engine-specific attributes such as service endpoints and data mappings; an analytical Level 2 model is not deployable as drawn.
- RPA automates presentation-level tasks; a BPM suite orchestrates end-to-end flow including human work.
Worked example
An approval process is modelled with an exclusive gateway. In the engine this becomes exclusive choice, and the merge behaves as a simple merge, so the instance continues as soon as the chosen branch arrives. If the engine instead enforced a synchronising merge there, the instance would deadlock, because only one token can ever arrive. Reasoning: workflow patterns expose semantic mismatches between the diagram and the engine.
Traps that cost marks
Assuming every engine supports every BPMN element. Confusing orchestration with choreography. Using a parallel gateway as a decision point. Expecting a descriptive model to run unchanged.