BPMN support
The engine documents what it actually runs. Supported means the parser and runtime execute the element. Partial means common patterns work and edge cases still need fixtures. Visual-only shapes round-trip in the modeler and do not execute.
Core elements
These are supported in release v1.1.0:
- Process deployment from BPMN XML, none start and end events, and conditional or default sequence flows.
- Message, timer, and signal start, catch, throw, and boundary events.
- Error boundary and end events, escalation events, conditional events, terminate end, and link events.
- User, service, script, business-rule, send, receive, and manual tasks.
- Exclusive, parallel, inclusive, and event-based gateways.
- Embedded sub-processes, call activities, multi-instance tasks, event sub-processes, and compensation.
- Cancel events with transaction sub-processes.
Timers accept an ISO-8601 duration such as PT5M, an absolute RFC3339 date, and a repeating cycle. User-task due dates create an SLA_DUE_DATE_BREACHED incident and publish user-task.due-date.breached once per job. Call activities can pin artificialflow:calledElementVersion. Otherwise they call the latest deployed version.
Not an execution feature
- Complex gateways and ad-hoc sub-processes are not supported.
- Data objects, stores, and inputs are visual only. Variables are the execution model.
- Pools, lanes, message flows, annotations, and groups are visual. A lane label can hint at user-task candidate groups.
- Foreign modeler extensions are not a native execution contract. Import notes are in the repository.
Versions
Each deploy of a BPMN process id creates a new process row with the next version and its own definition key. Starting by numeric definition key runs that exact version. Starting by BPMN process id runs the latest version unless the request includes version. The Processes page starts the row you select, which pins that definition key.
Open instances stay on the definition they started with. ArtificialFlow does not move tokens onto a newer version. The production default is to drain: leave running work on the old definition and start new work on the new one. A move to another model is a remodel and a new start.
Decisions and incidents
Business-rule tasks call a JSON decision table through artificialflow:decisionRef. See Decisions. An overdue user-task due date creates an SLA_DUE_DATE_BREACHED incident and publishes user-task.due-date.breached once per job. List incidents with GET /incidents. The Incidents and Decisions console pages are hidden in v1.1.0. The HTTP APIs stay available.
Diagrams from another modeler
ArtificialFlow executes BPMN 2.0 XML with artificialflow: extensions. A zeebe:taskDefinition type becomes artificialflow:taskType. Assignment and candidate groups become artificialflow:assignee and artificialflow:candidateGroups. Call activities use calledElement, with optional artificialflow:calledElementVersion. The lint tool reports blockers and rewrites:
go run ./tools/external-bpmn-lint --file path/to/process.bpmnExit code 0 means no blockers. Exit code 1 means the file must be remodeled before it will run.
Connectors
Official connectors are external workers. Set artificialflow:taskType on a service or send task. Input names and the worker loop are in Workers.
| Job type | Inputs |
|---|---|
io.artificialflow.connector.http | url, method, headers, body, timeoutMs, failOnNon2xx |
io.artificialflow.connector.webhook | webhookUrl, payload, webhookToken |
io.artificialflow.connector.kafka | kafkaTopic, kafkaKey, kafkaValue |
io.artificialflow.connector.email | emailTo, emailSubject, emailBody |
io.artificialflow.connector.s3 | s3Bucket, s3Key, s3Body, contentType |
The full matrix, including status notes and fixtures, is docs/BPMN_SUPPORT_MATRIX.md.
make test-bpmn-matrix