Composed Message Processor
The splitter → router → aggregator triptych — to process a 100-line INVOIC in parallel.
Problem
A composite message (100-line INVOIC, 50-line ORDERS) must be processed item-by-item. Each item has its own logic (product validation, price computation, stock check). How to parallelise while keeping final consistency?
Forces
- Sequential is slow for large messages.
- Naive parallel breaks final consistency.
- Some items may fail — the strategy must handle partial failure.
- The result must be a reconstructed message, not N separate messages.
Solution
Three-stage pipeline: (1) Splitter breaks the composite message, (2) optional Router/Filter dispatches each part by type, (3) Aggregator collects results and reconstructs a final message. Synchronise via correlation ID (the original messageId). Explicit timeout and partial-failure handling.
EDI implementation
In EDI, typical example: an INVOIC split into lines (LIN+QTY+MOA), each line validated in parallel (product check, price, tax), then recomposed into an enriched INVOIC. Camel implementation: .split(body().tokenize(LIN+)).parallelProcessing().aggregationStrategy(myAgg). ~10x throughput typically.
Anti-patterns
- No aggregator timeout — a stuck item blocks the whole INVOIC.
- Fatal error on one item = abandoning whole INVOIC — prefer a partial result.
- Splitter that does not preserve correlation ID — impossible to reconstruct.
Related patterns
- Splitter — building block.
- Aggregator — building block.
- Scatter-Gather — close pattern for parallel calls.
Sources
- Hohpe G., Woolf B. — EIP, Composed Message Processor (p. 294). www.enterpriseintegrationpatterns.com/patterns/messaging/DistributionAggregate.html