Send signal: <SignalName>
Description
Emits a signal to all subscriber pipelines. Each signal parameter maps to a typed input pin. When executed, one execution-intent row is enqueued for every subscribing pipeline; a NOTIFY wakes all cluster instances so any JVM can claim and run a subscriber.
When to use
Use Send signal whenever one pipeline needs to notify one or more other pipelines that something has happened — for example, after an order is placed, after a record is updated, or at the end of a long-running job. The sender does not wait for subscribers to finish; it enqueues intent rows and continues executing. Each subscriber pipeline runs independently, potentially on a different JVM instance in the cluster.
The pins of the node are determined by the signal’s parameter list. Each named parameter appears as a labelled input pin, typed to the Model the parameter references. Wire your data values into those pins before the node executes.
Because dispatch goes through the execution-intent queue, the sender is resilient: if all subscribers are busy the intents sit in the queue until a JVM claims them via SKIP LOCKED — there is no blocking or back-pressure on the sending pipeline.
Pins
Execution pins
| Pin | Direction |
|---|---|
| In | Input |
| Out | Output |
Example
A pipeline that processes an incoming order wires the completed Order model value
into the order input pin of Send signal: OrderPlaced, then continues with its
own confirmation email. Meanwhile, a separate pipeline triggered by
Receive signal: OrderPlaced runs asynchronously to update inventory — possibly on
a different instance — without slowing down the order-processing pipeline.