Composed Message Processor

Le triptyque splitter → router → aggregator — pour traiter en parallèle un INVOIC à 100 lignes.

Problème

Un message composite (INVOIC à 100 lignes, ORDERS à 50 lignes) doit être traité par item. Chaque item a sa propre logique (validation produit, calcul de prix, vérification de stock). Comment paralléliser tout en gardant la cohérence finale ?

Forces

• Le séquentiel est lent pour les gros messages.
• Le parallèle naïf perd la cohérence finale.
• Certains items peuvent échouer — la stratégie doit gérer le partial failure.
• Le résultat doit être un message reconstruit, pas N messages séparés.

Solution

Pipeline en trois temps : (1) Splitter éclate le message composite, (2) Router/Filter optionnel oriente chaque partie selon son type, (3) Aggregator collecte les résultats et reconstitue un message final. Synchroniser via correlation ID (le messageId d'origine). Gestion explicite des timeouts et partial failures.

Implémentation EDI

En EDI, exemple typique : un INVOIC fractionné en lignes (LIN+QTY+MOA), chaque ligne validée en parallèle (vérification de produit, prix, taxe), puis recomposée en INVOIC enrichi. Implémentation Camel : .split(body().tokenize(LIN+)).parallelProcessing().aggregationStrategy(myAgg). Throughput x10 typiquement.

Anti-patterns

• Pas de timeout sur l'aggregator — un item bloqué bloque tout le INVOIC.
• Erreur fatale sur un item = abandon du INVOIC entier — préférer un partial result.
• Splitter qui ne préserve pas la correlation ID — impossible de reconstruire.

Patterns liés

• Splitter — composant fondateur.
• Aggregator — composant fondateur.
• Scatter-Gather — pattern proche pour appels parallèles.

Sources

• Hohpe G., Woolf B. — EIP, Composed Message Processor (p. 294). www.enterpriseintegrationpatterns.com/patterns/messaging/DistributionAggregate.html