Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Best practices/Subscribe, don’t hardcode

Subscribe, don’t hardcode

A producer publishes to the bus and stops there. Who receives the message is decided by subscriptions on the consuming side — so adding the next destination is a configuration change, not an edit to the thing that produced the message.

The whole value of the bus is that producers and consumers do not know about each other. A receive port publishes a canonical message; each send port declares a subscription — usually a filter over a promoted variable — and the bus delivers a copy to everyone whose filter matches. The producer’s configuration never names a destination.

Producer (receive port) BUS Send port — ERP filter: type = Order Send port — Lake filter: type = Order Send port — Partner filter: type = Order + new consumer = new subscription producer is never touched

The anti-pattern is any place where the list of destinations is written into the producer: a component that loops over hard-coded endpoints, or a map that branches on “if partner X also send to Y.” Both turn a routine onboarding into a redeploy and re-couple the very things the bus exists to separate. If routing depends on content, express it as a content-based router — still subscriptions, just smarter filters.

Rule of thumb. Onboarding a new destination should never reopen the producer. If it does, the routing decision is living in the wrong place.