Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Patterns/Transformation/Normalizer

Normalizer

Many dialects in, one language out. Each source format gets its own inbound map that converts it into the single canonical message — so the rest of the system never sees a partner’s native shape.

A normalizer is the many-to-one front door. A partner sends X12, another sends a flat file, a third sends JSON; each lands on its own receive port with a map tailored to that format, and all three produce the identical canonical structure before anything is published. This is route through canonical made concrete on the inbound side.

X12 CSV JSON map → canonicalmap → canonicalmap → canonical canonical message one shape on the bus

Onboarding a new source is one new map plus its receive port — and it immediately reaches every existing destination, because those already consume canonical. The normalizer is where edge validation belongs too: reject what does not fit the canonical shape before it is published.

In Art2link the conversion lives in the inbound map. Each partner format is its own message type, and the receive port’s map runs in Typed mode — a table keyed on the source message type — mapping PartnerAOrder, PartnerBOrder and the rest each onto the one canonical Order. From the moment it reaches the bus the message is canonical, so every downstream subscription, map and pipeline only ever has to speak Order.

One map, one direction. A normalizer map only ever produces canonical. If it is also formatting output for a destination, split it — output formatting is a send-side job (map at the edges).