Content-based router

One message in, the right destination out — decided by what the message contains. In Art2link this is not a special component but a set of filtered subscriptions over the same published message.

Take a single inbound stream — orders arriving on a receive port (the adapter does not matter) and classified on the bus as the AmazonOrders message type, which carries a promoted property StoreNumber lifted from the payload. Each store's orders should leave through their own send port. In Art2link you build this entirely with subscriptions — one send port per store, each subscribing on a different value of the promotion:

EXPRESSIONsend port — Store 123

{{Promoted.AmazonOrders.StoreNumber}} == "123"

EXPRESSIONsend port — Store 909

{{Promoted.AmazonOrders.StoreNumber}} == "909"

The bus evaluates both expressions against every published message and hands each order to whichever port matches. Because the promoted token names its own message type, each expression already restricts to AmazonOrders — no separate {{Message.MessageType}} check is needed. And because the routing lives in subscriptions, opening a third store is a new send port with a new expression, never an edit to the producer.

Where the choice depends not on a fixed value but on a destination computed at runtime — a lookup that yields an address — reach for a dynamic router instead. And where the message should go to several chosen destinations at once, that is a recipient list.

Always include the else. A message whose StoreNumber matches no branch must go somewhere — wire the default to a dead-letter channel so surprises surface instead of vanishing.