Resequencer
Le composant qui remet les messages dans l'ordre — utile quand les workers parallèles publient en désordre.
Problème
Un INVOIC fractionné en 100 segments traités en parallèle peut arriver dans un ordre arbitraire chez le destinataire. Si l'ordre compte (HEAD avant LINE avant SUMMARY), comment remettre dans l'ordre ?
Forces
- Le parallélisme casse naturellement l'ordre.
- Reséquencer demande un buffer en mémoire avec timeout — risque OOM si le timeout est mal calibré.
- Certains messages peuvent être perdus — le resequencer doit prévoir un mode dégradé.
- EDI a souvent une notion d'ordre métier (Header → Detail → Summary).
Solution
Un consumer qui buffure les messages, indexés par sequenceId, et les republie dans l'ordre. Mécanisme typique : maintenir un compteur nextExpected, mettre en attente les messages avec id > nextExpected, libérer dès que le prochain attendu arrive. Timeout configuré (5-30 min en EDI) pour ne pas bloquer indéfiniment.
Implémentation EDI
En EDI, le Resequencer est utilisé pour reconstruire un INVOIC depuis ses segments parallel-processed, ou pour remettre en ordre des MDN qui arrivent en désordre (rare mais possible avec proxy/load balancer). Implémentation Apache Camel : `.resequence().header("sequenceNumber").timeout(30000)`. Performance : penser à libérer le buffer en cas de timeout pour éviter OOM.
Anti-patterns
- Timeout infini — leak mémoire à la première séquence incomplète.
- Resequencer en aval d'un splitter — Composed Message Processor est mieux.
- Ordre garanti par défaut sans validation — un message manquant bloque indéfiniment.
Patterns liés
- Splitter — souvent producteur de désordre.
- Aggregator — recompose après reséquençage.
- Composed Message Processor — alternative haute niveau.
Sources
- Hohpe G., Woolf B. — EIP, Resequencer (p. 283). www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html