Content-Based Router

When the routing rule is not in the envelope but in the content: ship-to country, total amount, currency, requested transport type. The pattern that turns business semantics into logical destinations.

Problem

All ORDERS arrive on the same input channel but must be handled differently depending on content: an order shipping to Germany goes to Berlin warehouse, an order to the US goes to the New Jersey hub, an order over €50,000 must go through manual approval before integration. The plain Message Router that only reads the envelope message type is no longer enough.

Forces

• Business semantics live in the payload. Country, amount, priority — these are business elements, not transport headers.
• Volume vs latency. Reading the payload is more expensive than reading the envelope (partial or full parse). The content router must still remain fast not to become a bottleneck.
• Rule evolvability. Business rules change often (new threshold, new country). They must be configurable without redeploy.
• Single responsibility. The router decides — it does not process. Transformation and integration live downstream.

Solution

EIP §230 (Hohpe & Woolf, 2003) prescribes: partial parse of the message just deep enough to extract decision fields, application of declarative rules (DSL or rule base), republish to the target channel. The rule must be pure — no synchronous external call, otherwise temporal coupling is reintroduced.

┌─────────────────────────┐
ORDERS ────────▶│  Content-Based Router   │
                │  (reads NAD+ST, MOA+86) │
                └──────────┬──────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
   warehouse-EU       warehouse-US       warehouse-APAC
   (country = DE/FR)  (country = US)     (country = JP/KR)

Topology

Two common decompositions:

• Single content router. One component reads the payload and decides. Simple, readable — but the component grows with the rules.
• Chained predicates. A chain of small filters (EIP §253 Message Filter), each with its rule and output channel. More modular and unit-testable, but more expensive in repeated parsing. Mitigation: parse once, pass the structured result down the chain.

EDI implementation

Three concrete examples:

• Geographic routing on EDIFACT ORDERS. The rule reads NAD+ST (Ship-To) and composes the target channel. The country qualifier is at position 8 of composite C817 (delivery address country).
• Manual validation above a threshold. The rule reads MOA+86 (Message total amount) and compares to the contractual threshold. If exceeded, the message goes to orders.manual-approval instead of the auto channel.
• X12 routing by TD5. On an 856 ASN, element TD5 (Carrier Details) routes to the logistics module for the matching carrier — FedEx, UPS, DHL.

UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+PO-12345+9'
DTM+137:20260514:102'
NAD+BY+8712345600014::9'
NAD+SU+5412345600015::9'
NAD+ST+8712345700421::9+++Berliner Hauptstrasse 12+Berlin++10117+DE'
LIN+1++4006381333931:EN'
QTY+21:24:PCE'
MOA+86:14500:EUR'
UNT+9+1'

Reading: in this ORDERS, the NAD+ST gives a Ship-To address in Berlin with country code DE. The content-based router emits to warehouse-eu.orders.in. The MOA+86:14500:EUR indicates €14,500 — below the manual-validation threshold (€50,000) — so no further branch.

Anti-patterns

• Synchronous external lookup. A rule that calls a reference service (e.g. to resolve a GLN to a country) at routing time turns the router into temporal coupling — if the reference is down, routing is down. If enrichment is needed, do it upstream (see Content Enricher), not inside the routing rule.
• Unreadable nested rules. More than 3 condition levels on the same content = sign to split into multiple Message Filters. Prefer a flat chain.
• No default channel. If no rule matches, there must be an explicit Default Channel ending up in the Dead Letter Channel. Silently dropping a non-routable message is the worst practice.

Related patterns

• Message Router — the base pattern; the content-based router is a specialisation.
• Content Enricher — to add missing fields before routing.
• Splitter — often applied downstream to handle each line separately.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, Content-Based Router (§230). enterpriseintegrationpatterns.com — Content-Based Router
• Apache Camel — Content-Based Router, one of the most used EIPs in the open-source stack. camel.apache.org — Choice EIP
• EANCOM 2002 — NAD segment. Specification of Ship-To and its geographic qualifiers.
• ASC X12 — TD5 Carrier Details. Canonical source of carrier routing on 856.