Skip to content

Reusable sub-flows

A reusable sub-flow is a flow that other flows can call by name, with design-time binding and validation on its inputs — the closest thing Pipebase has to a function you can share across integrations.

Under the hood, a sub-flow is a flow whose trigger is a Process Direct node (Camel’s direct: endpoint) with a published contract: a list of named inputs (each with a type and whether it’s required) and an optional output type. Any other flow can add a Process Call node, pick the sub-flow from a list, and fill in a binding expression for each declared input.

At deploy time the designer expands the call inline — the runtime never sees a special “call a sub-flow” step, only the same setHeader / setBody / setProperty steps plus a to: direct:<id> you’d have written by hand. There’s no added latency or indirection beyond what a direct: call already has.

  1. Create a flow whose first node is a Process Direct trigger.
  2. In the inspector for that trigger, enable “Reusable sub-flow”.
  3. Declare the inputs (name, type, required, and where it binds — header, body, or property) and, optionally, an output type.
  4. Save. The flow is now listed wherever other flows pick a sub-flow to call.
  1. Add a Process Call node to the caller flow.
  2. Pick the registered sub-flow from the picker. One binding field appears per declared input — fill in the Camel expression for each.
  3. Save/deploy as normal. Missing required bindings or an unknown target show up as a validation error before you can deploy.
  • The picker’s validation is the design-time guard. A sub-flow call deployed by hand (raw API) to an unknown direct: id will silently black-hole at runtime rather than failing fast — consistent with Pipebase’s trusted-private-network threat model.
  • Deleting a sub-flow that other flows still call doesn’t hard-block the delete; you’ll see a warning listing the callers, not a rejection.
  • Flows
  • A bundled example ships under designer/examples/subflows/ in the repo.