Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Best practices/Normalize onto the bus

Normalize onto the bus

The receive side’s job is to turn whatever arrived into one clean, canonical message and publish it. Delivery is the send port’s job. Normalize once, and any number of subscribers can consume it — without you touching the feed again.

A pipeline component can technically do anything: call a database, post to an API, finish the whole integration in one place. It is the single most tempting shortcut in the product, and it is almost always the wrong one. The moment a component delivers, the feed is welded to one destination and the bus stops doing its job.

Instead, draw a hard line. The receive pipeline parses, validates and maps the inbound payload into a canonical message, then publishes it to the bus. Subscriptions decide who gets it. Each send port owns its own delivery, with its own retry, backoff and dead-lettering. The producer never learns who is listening.

Inbound feed Receive pipeline normalize → canonical MESSAGE BUS canonical subscription Send port Send port Send port ERP Data lake Partner EDI

The payoff is concrete. A second consumer is a new subscription, not a code change. Every message is visible on the bus, so you get tracking, audit and a natural resume/replay point. A slow or broken destination is the send port’s problem, not the receive transaction’s — it cannot poison the inbound feed or block throughput.

The test. If adding a second destination would force you to edit the pipeline, the integration is delivering in the wrong place. Move the delivery to a send port and let it subscribe.

This is the foundation the rest of these practices build on: route through canonical, map at the edges, and keep components out of the delivery business are all corollaries of this one rule.