ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

Messaging Bridge

The bridge between two brokers — to migrate progressively from a legacy system to a modern platform without disruption.

Problem

An organization modernizes its EDI hub: new flows on Kafka, legacy flows still on the IBM Sterling AS2 hub. During the transition, legacy consumers must see new flows, and vice versa.

Forces

  • A hard cutover between two brokers breaks partner integrations.
  • A bidirectional bridge must avoid infinite loops (a message bouncing back).
  • Both brokers have diverging semantics (acks, ordering, idempotency) — the bridge must translate.
  • Bridge throughput must not become the bottleneck.

Solution

Deploy a dedicated bridge component that consumes from broker A, translates headers and ack semantics, and publishes to broker B. The bridge is stateful (cursors on both sides), idempotent, and observable. Loop-avoidance patterns: a `_bridged_from` header or a dedicated topic not re-polled. Implementations: Apache Camel routes, Confluent Replicator, Kafka MirrorMaker 2.

EDI implementation

In EDI, Messaging Bridge is the most common migration tool. Typical case: an AS2 hub Sterling Integrator pushes received MDNs to an MQ queue; an MQ→Kafka bridge publishes each MDN into `edi.mdns` with enrichment (`partner_id`, `business_correlation_id`). On the return path, the Kafka→MQ bridge pushes acknowledgments back to Sterling. Critical: maintain a mapping table to translate legacy ↔ modern identifiers.

Anti-patterns

  • Bridge without loop protection — a message bounces between both brokers indefinitely.
  • Bridge without header translation — partner_id semantics get lost across brokers.
  • Stateful bridge without persistence — a restart loses cursors.
  • Synchronous blocking bridge — a broker B downtime blocks the entire chain A.

Sources