orchestra

Orchestra runs business processes modelled as a graph of nodes connected by flows. A running process is advanced by tokens: a token sits on a node, the engine executes that node, and the token is then either consumed, producing new tokens on the outgoing flows, or parked to wait for an external signal. Parallel work is many tokens advancing at once; synchronization is many tokens meeting at a join; a human step simply parks its token until someone completes it.

Design goals

• Lightweight kernel. The orchestra module is the engine and nothing else: no UI, no editor, no dependencies beyond Drupal core. It runs headless, advancing tokens through a queue on cron.
• Everything is a plugin. Node behavior (TaskType), routing (FlowCondition, Split, Join) and task assignment (Assignment) are all attribute-based plugins. You extend Orchestra by adding plugins, never by patching it.
• Optional weight in submodules. Human tasks, a browser UI, a BPMN editor, ECA integration and a cross-site HTTP API are each a submodule you enable only when you need it.
• Multi-tenant from the start. Every install has one default tenant and behaves exactly like a single-tenant site; isolation into several realms is opt-in.

Features

• Composable routing. Branching is not a special node type: it falls out of per-flow conditions, a node's split (which live flows to take) and its join (when to fire). The classic gateways (exclusive, parallel, inclusive) are just presets over those knobs, and a quorum ("two of three approved") is a wait_all join, a merge and a count condition, with no special node.
• Human tasks. The orchestra_inbox submodule parks a token as a task in an inbox, to be claimed and completed. Tasks are pooled by default or targeted at users, roles or any custom audience through pluggable assignment, and can be handed off for completion, either to the built-in review form or to an external site over a signed URL.
• Distributed execution. A transport-agnostic client contract drives a workflow the same way in-process or on a remote site, over an OAuth-gated HTTP API, so the same caller code runs same-site and cross-site.
• Visual authoring. The orchestra_modeler submodule edits workflows in BPMN.io through the Modeler API, round-tripping id-stable so running instances are never orphaned.
• ECA integration. Start processes from ECA events, and emit ECA events from process tasks.

Module layout

Shipped today:

Module Responsibility orchestra Engine kernel: entities, plugin types, the engine service and queue worker. orchestra_inbox Human tasks: assign, claim and complete parked work from an inbox. orchestra_content Bind a process to a content entity and edit it as the work of a step. orchestra_content_moderation Drive a content entity's moderation state from a process (a state-transition task). orchestra_content_eca ECA glue: start a process for an entity, and expose a process's attached entity to ECA. orchestra_action Run a Drupal Action plugin as automated work in a process (Maestro's batch function, on Drupal's action system). orchestra_ui Browser UI to start, observe and manage instances. orchestra_modeler Author workflows visually through the Modeler API (BPMN.io). orchestra_cm Author workflows in accessible Drupal forms, without a diagram canvas. orchestra_bpmn_io Preserve the BPMN.io diagram layout across modeler switches. orchestra_eca ECA integration: start processes from events, emit events from tasks. orchestra_api The client contract and its in-process implementation. orchestra_server_api OAuth-gated HTTP API exposing the contract to remote consumers. orchestra_client Drives a remote Orchestra over HTTP. orchestra_views Expose processes, tokens, variables and tasks to Views, with readable labels, a tenant filter and ready-made dashboards. orchestra_vbo Bulk actions on processes and tokens (cancel, delete, signal) from a dashboard, via Views Bulk Operations. orchestra_vbo_inbox Bulk actions on the task inbox (claim, complete, reassign) via Views Bulk Operations. orchestra_examples Ready-to-run example workflows.

Planned:

Module Responsibility orchestra_domain Resolve the active tenant from the current domain.

Core concepts

Concept Stored as Role Tenant Config entity An isolated realm; instances, tokens and variables partition per tenant. Workflow Config entity The template: nodes, flows and the start node; shared or tenant-scoped. Process instance Content entity One running execution of a workflow. Token Content entity A marker on a node; the unit of execution. Variable Content entity A named value carried by an instance.

Multi-tenancy

Instances, tokens and variables each carry a tenant field, stamped at create time from the active tenant, so a query, a listing or a purge in one tenant never reaches another's rows. The active tenant is decided by tenant resolvers: services tagged orchestra.tenant_resolver that return a tenant machine name or NULL to defer. The first non-null answer wins; with none (the single-tenant case) the default tenant is used. A workflow is either shared across every tenant (the default) or scoped to a single tenant. Mapping a tenant to a domain will arrive as the planned orchestra_domain resolver.

Requirements

• Drupal 11.3 or newer
• PHP 8.3 or newer

Status

Early development, under active work. See the issue queue for the roadmap.