Message Router

A component that consumes a message from an input channel and republishes it to one of several output channels based on rules. It changes neither the content nor the envelope — it only decides where to send it.

Problem

An EDI platform receives ORDERS, INVOIC, DESADV, CONTRL — sometimes mixed at the same entry point (especially when transport is a shared AS2 or SFTP for the whole relationship). Downstream, each message type goes to a different handler: ORDERS to the order engine, INVOIC to accounting, DESADV to the WMS. Without upstream routing, each consumer must filter the whole stream itself, coupling everyone to the raw format and multiplying code paths.

Forces

• Heterogeneous downstream consumers. The order engine, accounting and WMS are typically three different systems that should not know about each other.
• One transport entry point. AS2 and SFTP are usually negotiated once per partner — not one per message type.
• Temporal decoupling. The router lets you buffer per channel, so a spike of INVOIC does not block ORDERS.
• Evolvability. Adding a new message type must not require changing existing consumers.

Solution

Hohpe & Woolf (2003, EIP §109) define the Message Router as a stateless filter that: (a) reads envelope or a subset of headers, (b) evaluates a routing rule and (c) republishes the unchanged message on the target channel. The rule can be fixed (routing table) or dynamic (computed from headers). The router never consumes the message in business terms — it changes nothing.

┌────────────────────────┐
─── in ────▶│      Message Router    │
             │  (inspects envelope)   │
             └──────────┬─────────────┘
                        │
       ┌────────────────┼────────────────┐
       │                │                │
       ▼                ▼                ▼
   channel A        channel B        channel C
   (ORDERS)         (INVOIC)         (DESADV)

Topology

Three common variants:

• Fixed Router. A {type → channel} mapping table embedded in configuration. Simple, static, deployed per release.
• Dynamic Router. The table is external (database or configuration service). Allows adding a partner without redeploy.
• Recipient List. Multicast variant — the same message goes to multiple channels (e.g. INVOIC to accounting + customer portal + legal archive).

EDI implementation

In EDIFACT the classic rule inspects the UNH (Message Header) segment to extract the type (ORDERS, INVOIC, DESADV...). In X12 it is element ST01 that carries the transaction number (850, 810, 856). Reading the first 100 bytes is enough: no need to parse the entire file.

Filename                          Routing key       Channel
─────────────────────────────────────────────────────────────
ORD_WALMART_20260514_001.edi      UNH=ORDERS        orders.in
INV_CARREFOUR_20260514_007.edi    UNH=INVOIC        invoic.in
DES_AMAZON_20260514_022.edi       UNH=DESADV        desadv.in
ORD_X12_850.edi                   ST=850            orders.in
ACK_X12_997.edi                   ST=997            ack.in

In practice, the routing table crosses three keys: (a) sender (UNB S002 or ISA06), (b) message type (UNH or ST01), (c) environment (P/T flag in ISA or EDIFACT logical account). That is what lets the same partner have different prod and test channels.

Anti-patterns

• Router that mutates. If the component transforms the message en route, it is no longer a router — it is a Message Translator. Keep responsibilities separate (single responsibility).
• Rules hidden in application code. Routing should be declarative (table, config file). A hard-coded if/else on message type inside a business service creates a coupling that will prevent adding a new partner later.
• Full file parsing. The router should read only the minimum required (header) to decide. Parsing the whole payload wastes CPU and exposes the router to business-syntax errors that are not its responsibility.

Related patterns

• Content-Based Router — when the decision must read the payload.
• Splitter — when a composite message must be split before routing.
• Dead Letter Channel — where messages go when no routing channel matches.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, Message Router (§109). enterpriseintegrationpatterns.com — Message Router
• Apache Camel — Routing EIPs. The open-source reference implementation. camel.apache.org — EIP
• UN/EDIFACT — ISO 9735. Specification of the UNH segment carrying the message type — the EDIFACT routing key by convention.
• ASC X12 — 004010. Specification of element ST01 carrying the transaction number — the X12 routing key.