> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/connector-configuration/utils/controls/joineach.md).

# Join Each

{% hint style="info" %}
For most loops, use [Each](/connector-configuration/utils/controls/each.md) with **Sequential** turned on and [Continue Each](/connector-configuration/utils/controls/continueeach.md) at the end of the loop instead. It processes the items in order, and **Add to Result** in **Continue Each** collects values from every item into `result` on the `done` port of **Each**. **Join Each** is for loops that run the items in parallel (**Sequential** off).
{% endhint %}

### Overview

The **JoinEach Component** is designed to work with the **Each Component**. It collects multiple incoming messages based on a specified count and outputs them as a single batch when all expected messages have arrived. If some messages do not arrive within a timeout period, it outputs the partial batch along with count information.

### Usage

#### Input Ports

| Port    | Description                                                                                  |
| ------- | -------------------------------------------------------------------------------------------- |
| `in`    | Receives individual messages to be aggregated. Each message must contain a `correlationId`.  |
| `count` | Specifies the total number of messages expected. Must be provided before aggregation begins. |

#### Output Ports

| Port      | Description                                                                                                    |
| --------- | -------------------------------------------------------------------------------------------------------------- |
| `out`     | Fires when all expected messages arrive, emitting an array of collected messages.                              |
| `timeout` | Fires when the timeout is reached before all expected messages arrive, providing the partial batch and counts. |

#### Output Data for `out` Port

| Field   | Description                      |
| ------- | -------------------------------- |
| `items` | The array of collected messages. |

#### Output Data for `timeout` Port

| Field     | Description                                            |
| --------- | ------------------------------------------------------ |
| `items`   | The array of messages that arrived before the timeout. |
| `count`   | The number of expected messages.                       |
| `arrived` | The number of messages that actually arrived.          |

### Instructions

1. **Set Up with Each Component**
   * Ensure messages sent to `in` contain a `correlationId` matching the one from the **Each** component.
2. **Define Expected Count**
   * Send a message to the `count` port specifying how many messages the component should wait for.
3. **Processing Messages**
   * The component collects messages based on the `correlationId`.
   * When all expected messages arrive, they are sent as an array to the `out` port.
   * If not all messages arrive before the timeout, the `timeout` port emits the partial batch.

### Notes

* **Works with Correlation IDs**: Ensures messages from the same batch are correctly joined.
* **Timeout Handling**: Prevents indefinite waiting if some messages fail to arrive.
* **Batch Processing**: Useful for grouping messages into structured outputs for further processing.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.appmixer.com/connector-configuration/utils/controls/joineach.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.