Invalid Message Channel
The queue receiving well-formed but unacceptable messages.
Problem
A syntactically valid parsed message can be business-invalid: unknown currency, non-existent GLN, total TTC ≠ HT + VAT. What to do — ignore it, reject it, pause it?
Forces
- Blocking the pipeline on an invalid message blocks all valid messages behind it.
- Silent drop = data loss, no audit trail.
- Returning an immediate error to the partner is fine for sync APIs, but EDI is async.
- Functional owners want to see invalids to understand causes (broken partner mapping?).
Solution
Route the invalid message to a separate Invalid Message Channel (e.g. edi.invalid.orders). Emit an "invalid.count" metric, a structured log, and an event toward a functional dashboard. The valid queue keeps flowing. An operator can, after analysis, re-inject the corrected message or emit a negative CONTRL/997 toward the sender.
EDI implementation
In EDI, the Invalid Message Channel is typically a dedicated edi.invalid.* Kafka topic, with long retention (minimum 90 days for audit). A Grafana dashboard shows the invalid/total ratio per partner. A workflow replays corrected messages via a Camel route. Distinct from the Dead Letter Channel — DLC = technical problem, Invalid = business problem.
Anti-patterns
- Conflating Invalid Message Channel and Dead Letter Channel — different audiences (functional vs ops) and different SLAs.
- Not notifying the partner — they keep sending invalid messages unknowingly, the ratio climbs.
- Re-injecting automatically without correction — infinite loop.
Related patterns
- Dead Letter Channel — channel for technical errors.
- Exception flow — operational framework.
Sources
- Hohpe G., Woolf B. — EIP, Invalid Message Channel (p. 115). www.enterpriseintegrationpatterns.com/patterns/messaging/InvalidMessageChannel.html