Skip to content

Integrations and authoring

ECA

The orchestra_eca submodule wires Orchestra to ECA in both directions, so processes and events trigger each other without code.

  • ECA → Orchestra. A StartProcess ECA action launches a process instance from any ECA event. Model "when a node is published, start the review workflow" entirely in ECA.
  • Orchestra → ECA. An eca_event task type emits a custom ECA event when a token reaches it. Drop the node into a workflow to fan out into anything ECA can do (send mail, set a field, call a service) and, if the node parks, resume the token once that work signals back.
flowchart LR
  event([ECA event]) -->|StartProcess action| inst[Process instance]
  inst --> node[eca_event task] -->|emits ECA event| eca([ECA reacts])

Visual authoring (Modeler)

The orchestra_modeler submodule lets you draw workflows in BPMN.io through the Modeler API. A model owner maps Orchestra's nodes and flows to BPMN components and back:

  • Round-trips id-stable. A node's id is preserved across edits, so saving an unchanged diagram does not renumber nodes; running instances are never orphaned.
  • Element templates carry each node's task type and its per-node settings (outcomes, result variable, assignment fields, join/split) in the property panel; flow conditions ride on the links.
  • A running-instance guard. A subscriber warns before you edit a workflow that still has running instances, since a structural change can strand them.

The optional orchestra_bpmn_io submodule adapts the BPMN.io editor to Orchestra: it preserves a workflow's diagram layout when the same workflow is saved from another modeler (Orchestra stores the node positions itself), and it trims the editor's context pad to the shapes Orchestra can model, so the pad never offers a native end event, intermediate event or shape-morph that the workflow would silently drop on save.

Complete modeler (form-based)

The orchestra_cm submodule is a form-based alternative to the BPMN.io canvas: it edits the same workflow as a list of node and flow sections, mapped to the Modeler API by the same kind of model owner. It is the place to author the node-level structures a diagram cannot show (escalation timers, assignments).

Each node, each flow, each node-feature editor, and the add-node / add-flow controls are collapsible sections collapsed by default, so a large workflow stays scannable: open only the ones you are working on. Every edit re-renders the structure in place (an AJAX Apply); the sections you have open stay open across that rebuild (a just-added or just-renamed item, and any section with a validation error, open automatically).

In-editor Clone node and Clone flow buttons duplicate a single node, or a conditioned flow, within the workflow you are editing, a quick way to repeat a node-feature setup without retyping it. This is distinct from cloning a whole workflow (see Cloning, import and export).

Cloning, import and export

Moving and duplicating workflows needs no Orchestra-specific tooling: it comes from the Modeler API (which Orchestra is a model owner of) and the config-entity ecosystem:

  • Import / export: because Orchestra is a Modeler API model owner, the Modeler API adds a Models collection with an Import tab (import a model from a raw or archived file) and Export / Export as recipe operations on each model. So a workflow exports as a file or a shareable recipe and imports elsewhere, all from the UI.
  • Clone: the Entity Clone module adds a Clone operation that duplicates a workflow under a new machine name, a quick way to base a new workflow on an existing one.
  • A workflow is also a plain config entity, so drush config:export / config:import round-trips it as YAML for developer config workflows.

So a workflow authored on one site can be cloned, exported and re-imported elsewhere through tools already in place.

Examples

The orchestra_examples submodule ships ready-to-run workflows, each demonstrating one capability. Enable the module, then start any of them from the UI or WorkflowEngine::start().

Workflow Shows
example_linear A linear flow that parks on a wait and resumes when signalled.
example_exclusive An exclusive choice (approve / reject) driven by flow conditions.
example_parallel A parallel split and an AND-join waiting for both branches.
example_inclusive An inclusive split and a matching join over the live branches.
example_quorum A synchronous quorum (wait_all + merge + count) whose three ballots also demonstrate every task-assignment form.