Skip to content
Art2link ESB HomeDocumentationBlogContact
Updated August 2, 2026
Best practices/Map at the edges

Map at the edges

Shape data on the way in and on the way out, never in the middle. The receive port’s inbound side turns the source format into canonical; the send port’s outbound side turns canonical into the destination format. Between them, the bus carries one stable shape.

Every message has exactly two edges where its shape is allowed to change: the point where it enters the system and the point where it leaves. The inbound map runs on the receive port and produces the canonical message. The outbound map runs on the send port and produces whatever the destination wants. Everything in between is canonical and untouched.

Source format Receive map in-edge canonical no transformation here Send map out-edge Dest. format

Keeping transformation at the edges is what makes the canonical guarantee real. If a component partway through quietly reshapes the message, every downstream subscriber inherits a surprise and the bus no longer carries a single known shape. It also keeps each map small and one-directional, far easier to read, test and hand to the AI Accelerator than a map that does input parsing and output formatting at once.

Enrichment is an edge job too. Adding fields a destination needs belongs in the send-side map or a content enricher feeding it, not a mutation of the shared message mid-bus.