Skip to main content

Event

1. Overview

The Event component (event) allows different flows to talk to each other through events: one flow "publishes" an event with a name, and another flow (or several) "listens" for that same name and reacts to it. This is known as the publish/subscribe pattern.

Use it when two or more flows need to communicate without being directly connected (for example, one flow fires an "order created" event and another, completely independent flow listens for that event to send a notification). Don't use it for direct, synchronous calls within the same flow — the Function/Function Caller component is better suited for that.

2. Prerequisites

  • For events with LOCAL scope: no additional requirements, everything happens within the same application instance.
  • For events with SHARED scope (shared across instances/applications): a RabbitMQ server configured and accessible by the platform is required, with a username and password defined in the application's configuration (not in the component itself).
  • Network requirements: access to the default RabbitMQ port (5672) when scope is SHARED.

3. Authentication and Connection

The component doesn't expose authentication fields directly — the RabbitMQ connection (used only in SHARED scope) is configured at the application level, not per flow.

FieldRequiredTypeDescriptionExample
eventNameYesTextEvent name. Must be the same on both the publisher and the listener."customer-updated"
eventScopeYesText: LOCAL or SHAREDLOCAL: communication only within the same application instance. SHARED: communication across different instances/applications, via a message queue."SHARED"
eventTypeNoText: SYNC or ASYNCDefines whether the publisher waits for a response (SYNC) or just fires and moves on (ASYNC). Default value: empty (no type defined)."SYNC"
timeoutNoNumber (milliseconds)Maximum wait time for a response in synchronous events, or the message's lifetime in the queue. Default value: 3600000 (1 hour).30000
executeOnExpireNoTextName of a function (registered with the Function component) to call if the message expires before being processed."handleExpiredEvent"

4. Configuration / Supported Operations

The component acts in two ways within a flow:

  • As a trigger (listening): the flow starts when the configured event is published somewhere.
  • As an action (publishing): at another point in the flow, the component publishes an event with the configured name, sending the message's current body.

When publishing a synchronous event (eventType: SYNC), the publisher waits for the listener's response, within the time set in timeout. When publishing an asynchronous event (eventType: ASYNC), publishing doesn't wait for a response.

Error behavior: if the message expires (past the time set in timeout before being processed), the event isn't executed and, if executeOnExpire is configured, that function is called to handle the expiration. If event execution fails, the error is propagated to the publisher (for synchronous events).

5. Practical Examples

Simple example: two flows within the same application. The first publishes an event named "customer-updated" with eventScope: LOCAL whenever a record is changed. The second flow listens for that same event and updates an internal cache whenever it happens.

Input for the publishing flow:

{
"customerId": 456,
"changedFields": ["email", "phone"]
}

Configuration of the component that publishes the event:

{
"componentName": "event",
"configurations": {
"eventName": "customer-updated",
"eventScope": "LOCAL",
"eventType": "ASYNC"
}
}

Configuration of the component that listens for the event (start of the reacting flow):

{
"componentName": "event",
"configurations": {
"eventName": "customer-updated",
"eventScope": "LOCAL"
}
}

The listening flow receives exactly the same body that was published:

{
"customerId": 456,
"changedFields": ["email", "phone"]
}

Advanced example: two different systems (running on separate instances) need to exchange information synchronously. Flow A publishes a "validate-stock" event with eventScope: SHARED and eventType: SYNC, waiting up to 30 seconds (timeout: 30000) for the response from flow B, which is listening for that same event in another application. If flow B takes longer than that, the message expires and the function configured in executeOnExpire is called to log the failure.

Input for the publishing flow:

{
"productId": "SKU-789",
"quantity": 5
}

Configuration of the publishing component:

{
"componentName": "event",
"configurations": {
"eventName": "validate-stock",
"eventScope": "SHARED",
"eventType": "SYNC",
"timeout": "30000",
"executeOnExpire": "handleExpiredEvent"
}
}

Response received by the publisher, when flow B responds in time:

{
"responses": [
{ "body": "{\"available\":true,\"stockQuantity\":42}" }
]
}

6. Points of Attention

  • In LOCAL scope, the event is only seen by flows running in the same application instance.
  • In SHARED scope, publishing and listening depend on an accessible RabbitMQ.
  • Synchronous events wait for a response up to the configured timeout — it's worth sizing that value based on the actual expected processing time.

7. Common Errors and Troubleshooting

Error / SymptomLikely CauseHow to Fix
Published event is never receivedeventName isn't identical between publisher and listener, or the scopes (LOCAL/SHARED) differ.Check that the event name and scope are exactly the same on both sides.
Synchronous publish takes too long and returns an errorNo one is listening for the event, or the listener takes longer than the configured timeout.Confirm there's an active flow listening for that event and increase timeout if needed.
"Timeout at [time]. Skipping execution" (in the log)The message arrived after the time limit set in timeout.Review whether timeout matches the real expected processing time, or investigate consumer slowness.
Event in SHARED scope doesn't workRabbitMQ isn't accessible or is misconfigured in the application.Check RabbitMQ connectivity and credentials configured in the application.