Process Engine
The engine that runs long-running EDI workflows (days, weeks) without dying on an application crash.
Problem
A PO → ORDRSP → DESADV → INVOIC → REMADV cycle can span 30 days, with timers (48h follow-up), compensations (mid-flow cancellation), and 5 possible human decisions. Simple application code does not hold.
Forces
- State must survive crashes — persistence required at every step.
- Timers must fire even if the application is down (resumed on startup).
- Compensations must be documented by model, not invented in ad-hoc code.
- Business stakeholders must be able to visualise the workflow (BPMN diagram).
Solution
Adopt a Process Engine: Camunda, Zeebe, Activiti, AWS Step Functions, Netflix Conductor, Temporal. The workflow is defined in BPMN (or DSL), deployed as an artifact, executed by the engine. The engine guarantees at-least-once durability, declarative retries, timers, and run observability. Application code only implements `task workers` (atomic actions); the engine orchestrates.
EDI implementation
In EDI, a Process Engine is the pragmatic way to implement Process Manager for complex cycles. Example: an 'expect 856 within 24h after 850 otherwise escalate' cycle becomes a BPMN diagram deployed on Camunda. The `send850` task worker publishes the EDIFACT on Kafka; the Camunda timer fires the escalation; a human task opens a Jira ticket. The pattern pays on business readability: the BPMN diagram is understood by EDI analysts, while Java code is not.
Anti-patterns
- Workflow in plain Java/Python code — not versionable as a model, re-implemented at every change.
- Process Engine for short workflows (< 1 minute) — overengineering, unnecessary latency.
- Process Engine shared across business domains without namespacing — one workflow blocks others.
- BPMN diagram decorated without precise code mapping — documentation drifts from runtime.
Related patterns
- Process Manager — concept of which Process Engine is the runtime.
- Saga Orchestration — explicitly modelled compensations.
- Control Bus — observation and control of runs.
Sources
- Hohpe G., Woolf B. — EIP, Process Manager (p. 312) — conceptual base. www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html
- Camunda — BPMN Engine. docs.camunda.io/
- OMG — BPMN 2.0 specification. www.omg.org/spec/BPMN/2.0/