> For the complete documentation index, see [llms.txt](https://docs.digibee.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digibee.com/documentation/connectors-and-triggers/connectors/queues-and-messaging/event-publisher.md).

# Event Publisher

Discover more about the Event Publisher component and how to use it on the Digibee Integration Platform.

The **Event Publisher** connector enables event-driven communication between pipelines, notifying other pipelines about a state change, an action, or an occurred fact so they can react to it, leveraging the platform's native event routing.

Learn more about [how to use event-driven architecture on the Digibee Integration Platform](/documentation/resources/use-cases/how-to-use-event-driven-architecture-on-the-digibee-integration-platform.md).

## **Parameters**

The table below lists all configuration parameters for the connector. Parameters that support [Double Braces expressions](/documentation/connectors-and-triggers/double-braces/overview.md) are marked with ✅ in the **Supports DB** column.

{% tabs %}
{% tab title="Section Event Publisher Connector" %}

<table><thead><tr><th width="111.79986572265625">Parameter</th><th width="230.79986572265625">Description</th><th width="100">Type</th><th width="109.5999755859375">Supports DB</th><th width="150.19091796875">Default</th></tr></thead><tbody><tr><td><strong>Alias</strong></td><td>A name for this connector's output, so you can reference it later in the flow with <a href="/documentation/connectors-and-triggers/double-braces/how-to-reference-data-using-double-braces.md#referencing-previous-steps-using-previous-steps-access">Double Braces</a>.</td><td>String</td><td><strong>❌</strong></td><td><code>event-publisher-1</code></td></tr><tr><td><strong>Event</strong></td><td>Name of the created event to be published for other pipelines to consume.</td><td>String</td><td>✅</td><td><code>{{ DEFAULT(message.eventName, "new-event") }}</code></td></tr><tr><td><strong>Body</strong></td><td>Payload to be sent with the event.</td><td>JSON</td><td>✅</td><td><code>{{ message.$ }}</code></td></tr><tr><td><strong>Log Each Event Sent</strong></td><td>If enabled, generates an input log for each sent event.</td><td>Boolean</td><td>❌</td><td><code>false</code></td></tr><tr><td><strong>Fail On Error</strong></td><td>If enabled, interrupts the pipeline execution when an error occurs. If disabled, execution continues, but the <code>"success"</code> property will be set to <code>false</code>.</td><td>Boolean</td><td>❌</td><td><code>false</code></td></tr></tbody></table>
{% endtab %}

{% tab title="Documentation" %}

<table><thead><tr><th width="123">Parameter</th><th width="231.19989013671875">Description</th><th width="100">Type</th><th width="109.5999755859375">Supports DB</th><th width="137.79071044921875">Default</th></tr></thead><tbody><tr><td><strong>Documentation</strong></td><td>Optional field to describe the connector configuration and any relevant business rules.</td><td>String</td><td>❌</td><td>N/A</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

## **How does event-based messaging between pipelines work?**

An event-driven setup always has two sides: a pipeline that publishes the event and one or more pipelines that consume it.

First, configure the Publisher pipeline:

1. Add the Event Publisher connector to the pipeline.
2. In the **Event** parameter, enter the name of the event to publish.
3. To send data with the event, define the payload in the **Body** parameter.

Then, configure the Subscriber pipeline:

1. Set the pipeline's trigger type to [Event Trigger](/documentation/connectors-and-triggers/triggers/messaging-and-events/event.md).
2. In the trigger configuration, enter the event name in the **Event Name** property. This value must match the one set in the **Event** parameter of the Publisher pipeline.

With both pipelines configured, every time the Publisher pipeline runs and publishes the event, the Subscriber pipeline is triggered and starts running automatically.

{% hint style="warning" %}

#### Note on redeploying Publisher and Subscriber pipelines

When redeploying a pipeline with Event Publisher, also redeploy the corresponding Subscriber pipeline (the one with the Event Trigger), starting with the Subscriber. If the two sides are temporarily misaligned, event delivery keeps working, but the timeout and redelivery (Allow Redelivery Of Messages) settings may not apply until both pipelines are redeployed. Learn more in [How to interpret event publishing and delivery alerts](/documentation/troubleshooting/deployment-issues/interpret-event-publishing-and-delivery-alerts.md).
{% endhint %}

## **Error scenarios**

### **java.util.NoSuchElementException: Timeout waiting for idle object**

This error means the connector can't keep up with the number of events sent at the same time. To solve this, you have two options:

* **Increase the number of pipeline replicas**: distributes the event load more efficiently and reduces pressure on the connector, so it can process events more smoothly.
* **Implement error handling with Retry**: retries sending the events that caused the error automatically, which helps with temporary load spikes or events that occasionally fail.

## **Messages flow**

### **Input**

The connector waits for a valid message in JSON format. No specific attribute is expected. You can reference the input message with Double Braces in both the **Event** and **Body** parameters. For example, say the following message is passed to Event Publisher:

```json
{
  "eventName": "example",
  "body": {
    "id": "1",
    "description": "Description of the case"
  }
}
```

You could define a Double Braces expression in the **Event** parameter to get the value of the `eventName` attribute:

```
{{ message.eventName }}
```

You could configure the **Body** attribute the same way:

```
{{ message.body }}
```

### **Output**

The connector passes along the message received from the previous connector, without any change. In the example above, the output message is:

```json
{
  "eventName": "example",
  "body": {
    "id": "1",
    "description": "Description of the case"
  }
}
```

## **Next steps**

Now that you know how Event Publisher works, read [Event Trigger](/documentation/connectors-and-triggers/triggers/messaging-and-events/event.md) to configure the pipeline that consumes the published event.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.digibee.com/documentation/connectors-and-triggers/connectors/queues-and-messaging/event-publisher.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.