Invalid Message Channel

La queue qui reçoit les messages bien formés mais inacceptables.

Problème

Un message parsé syntactiquement correct peut être métier-invalide : devise inconnue, GLN inexistant, somme TTC ≠ HT + TVA. Que faire — l'ignorer, le rejeter, le mettre en pause ?

Forces

• Bloquer le pipeline sur un message invalide bloque tous les messages valides derrière.
• Drop silencieux = perte de données, impossible à auditer.
• Renvoyer une erreur immédiate au partenaire est OK pour API synchrone, mais EDI est asynchrone.
• Les responsables fonctionnels veulent voir les invalides pour comprendre les causes (mapping cassé chez le partenaire ?).

Solution

Router le message invalide vers un Invalid Message Channel séparé (par exemple edi.invalid.orders). Émettre une métrique 'invalid.count', un log structuré, et un événement vers un dashboard fonctionnel. La queue valide continue de fonctionner. Un opérateur peut, après analyse, ré-injecter le message corrigé ou émettre un CONTRL/997 négatif vers l'expéditeur.

Implémentation EDI

En EDI, l'Invalid Message Channel est typiquement un topic Kafka edi.invalid.* dédié, avec retention longue (90 jours minimum pour audit). Un dashboard Grafana montre le ratio invalid/total par partenaire. Un workflow rejoue les messages corrigés via une route Camel. Distinct du Dead Letter Channel — DLC = problème technique, Invalid = problème métier.

Anti-patterns

• Confondre Invalid Message Channel et Dead Letter Channel — les deux ont des audiences (functional vs ops) et des SLAs différents.
• Ne pas notifier le partenaire — il continue à émettre des messages invalides sans le savoir, le ratio grimpe.
• Réinjecter automatiquement sans correction — boucle infinie.

Patterns liés

• Dead Letter Channel — canal des erreurs techniques.
• Flux d'exception — cadre opérationnel.

Sources

• Hohpe G., Woolf B. — EIP, Invalid Message Channel (p. 115). www.enterpriseintegrationpatterns.com/patterns/messaging/InvalidMessageChannel.html