Test Message

The synthetic canary — a test INVOIC every 5 min to check the chain is breathing.

Problem

How to know if an EDI pipeline works when there is no real traffic — at night, weekends, after maintenance?

Forces

• Waiting for a real message to detect an outage = unacceptable delay.
• Component health checks do not cover end-to-end.
• A test message must be distinguishable from real ones (to avoid business pollution).
• The test must validate more than transit — signature, mapping, delivery too.

Solution

Inject periodically (5-15 min) an identifiable Test Message (X-Test: true header, reserved "test-canary" partnerId) that traverses the whole pipeline. The end component (CanaryReceiver) checks SLA reception, intact payload, OK signature, and publishes a metric. Alert if Test Message missing or late.

EDI implementation

In EDI, Test Message is typically a fake INVOIC or ORDERS with partnerId "CANARY-DUNS-000000000". It traverses parser → validator → translator → AS2 client → AS2 server (internal mock) → MDN parser. Metric "canary.latency.p99" < 30s. PagerDuty alert if not received within 5 min. Adopted by Stripe, GitHub, AWS internally.

Anti-patterns

• Test Message sent to a real partner — pollutes their flows.
• Test Message not distinguishable — risk of being counted as a real INVOIC.
• Test Message at excessive frequency — useless overhead.

Related patterns

• Control Bus — triggering channel.
• Wire Tap — Test Messages observation.

Sources

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