Test Message

Le canari synthétique — un INVOIC de test toutes les 5 min pour vérifier que la chaîne respire.

Problème

Comment savoir si un pipeline EDI fonctionne quand il n'y a pas de trafic réel — la nuit, le week-end, après une maintenance ?

Forces

• Attendre un message réel pour détecter une panne = délai inacceptable.
• Les health-checks de composants ne couvrent pas le end-to-end.
• Un test message doit être distinguable des messages réels (pour ne pas polluer le métier).
• Le test doit valider plus que la traversée — aussi la signature, le mapping, la livraison.

Solution

Injecter périodiquement (5-15 min) un Test Message identifiable (header X-Test: true, partnerId réservé 'test-canary') qui traverse tout le pipeline. Le composant de fin (CanaryReceiver) vérifie réception dans le SLA, payload intact, signature OK, et publie une métrique. Alerte si Test Message manquant ou en retard.

Implémentation EDI

En EDI, le Test Message est typiquement un INVOIC ou ORDERS factice avec un partnerId 'CANARY-DUNS-000000000'. Il traverse parser → validator → translator → AS2 client → AS2 server (mock interne) → MDN parser. Métrique 'canary.latency.p99' < 30s. Alerte PagerDuty si pas reçu en 5 min. Adopté par Stripe, GitHub, AWS internally.

Anti-patterns

• Test Message envoyé à un vrai partenaire — pollution de leurs flux.
• Test Message non distinguable — risque de comptabilisation comme INVOIC réelle.
• Test Message à fréquence excessive — surcharge inutile.

Patterns liés

• Control Bus — canal de déclenchement.
• Wire Tap — observation des Test Messages.

Sources

• Hohpe G., Woolf B. — EIP, Test Message (p. 569). www.enterpriseintegrationpatterns.com/patterns/messaging/TestMessage.html