Aggregator

The opposite of the Splitter. Multiple correlated messages arrive within a window; one consolidated message comes out. The stateful pattern par excellence — and therefore the trickiest to size.

Problem

In EDI we regularly consolidate messages received separately: a customer order produces 5 DESADV across days while shipments leave in batches, then one consolidated INVOIC must be emitted grouping the 5 deliveries into a monthly invoice. Or: a 100-line Split processed in parallel must answer with a single global status to the original sender. Without aggregation we multiply downstream messages and add noise for interlocutors.

Forces

• Stateful by nature. Unlike most EIPs which are stateless, the aggregator must hold partial messages until completion. That imposes a store.
• Non-trivial completion. When do we know we have everything? Fixed size? Explicit last marker? Timeout? Three strategies, three trade-offs.
• Backpressure. An aggregator can buffer indefinitely if completion never fires. Always foresee a cap and an expiry.
• Order-independent. The pattern must work even when messages arrive out of order (5/12, 2/12, 11/12...).

Solution

EIP §268 (Hohpe & Woolf, 2003) models the Aggregator as a three-responsibility component: (a) correlation — assign each incoming message to a group (e.g. by RFF+ON or order number), (b) accumulation — store the group's messages in a buffer, (c) completion — decide when to emit the composite and build it from the stored partials. Once emitted, the group is purged.

┌────────────┐
   │ DESADV #1 │──┐
   └────────────┘  │
   ┌────────────┐  │     ┌──────────────────────┐
   │ DESADV #2 │──┼───▶ │      Aggregator      │ ───▶ monthly INVOIC
   └────────────┘  │     │ (correlation = PO)   │      consolidated
   ┌────────────┐  │     │ (completion = D+30) │
   │ DESADV #N │──┘     └──────────────────────┘

Completion strategies

Hohpe identifies four common strategies:

• Fixed wait. Emit after a fixed delay (e.g. 30 days at month-end for consolidated billing).
• Wait for all. Emit when N children have arrived — useful if the upstream splitter provides the total in each child.
• Timeout. Emit as soon as no message in the group arrives within T minutes. Robust but reacts late.
• External event. Emit on an external signal (end of accounting period, manual trigger). Useful for monthly billing.

In production, the combination wait-for-all + timeout-fallback is the most robust: wait for all children when possible, but finalise on timeout to avoid buffering an incomplete group forever.

EDI implementation

Three typical use cases:

• DESADV → INVOIC consolidated billing. Over a monthly period, aggregate all DESADV linked to a given order (correlation RFF+ON) then emit one INVOIC whose LIN lines sum the delivered quantities and MOA+86 sums the amounts. Heavy use in retail.
• Partial response aggregation. An ORDERS split per warehouse site produces N partial ORDRSP. The aggregator reconstructs a single ORDRSP for the sender (correlation BGM+RFF+ON, completion on expected warehouse count).
• Monthly X12 997. Instead of responding 997 on each received 850, some partners consolidate into a daily or weekly 997 that acknowledges 100+ functional groups at once. Correlation is then on (sender, day).

UNH+1+INVOIC:D:96A:UN:EAN008'
BGM+380+INV-CONSO-202605+9'
DTM+137:20260514:102'
RFF+ON:PO-12345'
NAD+SU+5412345600015::9'
NAD+BY+8712345600014::9'
LIN+1++4006381333931:EN'
QTY+47:120:PCE'   /* aggregated total : 24+48+48 = 120 */
MOA+203:36000:EUR'
LIN+2++4006381444042:EN'
QTY+47:30:PCE'
MOA+203:8500:EUR'
MOA+86:44500:EUR'   /* aggregated total */
UNT+12+1'

Reading: this consolidated INVOIC carries a single RFF+ON (order number), a single NAD+BY + NAD+SU pair, but QTY+47 (Quantity Delivered) are summed across the partial DESADV (24+48+48 = 120), and MOA+86 gives the aggregated total. Completion is triggered here by an external event (D+30 cutover or operator "invoice now" button).

Anti-patterns

• No timeout. Without expiry, a group that never completes (a message got lost) stays buffered forever. Always enforce a maximum timeout (D+1 to D+30 depending on flow) with partial emission + alert.
• Correlation too wide. If the correlation key is too generic (e.g. just "sender"), all messages fall into the same group and the composite becomes unusable. Narrow the key to the minimum needed.
• In-memory state. Instance crash = every open window lost. Persist.
• Partial-complete emit without alert. If timeout triggers a partial emission, it is almost always an incident — alert explicitly, do not finalise silently.

Related patterns

• Splitter — the inverse pattern; the two are often paired (split-process-aggregate).
• Exception flow — when a group fails to complete in the window.
• Claim Check — to avoid duplicating large payloads in the buffer.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, Aggregator (§268). enterpriseintegrationpatterns.com — Aggregator
• Apache Camel — Aggregate EIP, completion strategies and stateful persistence. camel.apache.org — Aggregate EIP
• EANCOM 2002 — INVOIC Application Guideline. Documentation of consolidated billing per period and per purchase order.
• AWS Architecture Blog — Building event-driven architectures with EventBridge Pipes (2023). A modern application of the pattern in the serverless stack.