Table of Contents

Elsa + Broker deployment

How the pieces run together at runtime — the broker (Queue + Processor), the Elsa 3 server, SQL Server, and the dispatch/callback hops. Rendered offline with PlantUML; regenerate via docs/scripts/render-diagram.sh.

elsa-broker Elsa + Broker deployment

The flow

  1. Submit / poll — the client calls the Queue API over mTLS on :5001.
  2. Enqueue — the Queue writes a RequestRecord and publishes the message via the EF outbox (one transaction) into the SQL transport.
  3. Deliver — the Processor consumes the message from the SQL transport.
  4. Dispatch — the Processor POSTs { definitionId, correlationId, message, callbackUrl, secret } to the Elsa broker-dispatch workflow and returns deferred (record stays Processing).
  5. Run — broker-dispatch runs the target workflow by id (DispatchWorkflow, WaitForCompletion).
  6. Callback — Elsa SendHttpRequests the outcome to the Queue's internal listener :5080 with the shared X-Callback-Secret.
  7. Finalize — the Queue sets the RequestRecord to Completed/Faulted; the client's next poll sees it.

The shared workflows/ folder feeds both sides: the Elsa server mounts it at /app/Workflows, and the Processor scans it to map requestType → definitionId. Elsa Studio (:13000) is where you author and export those workflows.

See Elsa integration for the convention and the async-callback rationale.