Loopback port
Loopback ports reshape messages without leaving Art2link ESB. They subscribe to the bus, run the message through an outbound flow, fold back through a mirrored inbound flow, and republish to the bus with a new Message Type.
A loopback port is a flavour of send port. It runs through the same outbound stages and the same inbound return stages as a two-way send port — with one critical difference: there is no adapter. The message is folded directly from the end of the outbound stages into the beginning of the inbound stages, then published back to the bus. Loopback ports are two-way by design — there is no one-way mode.
The use case is in-flow message reshaping. A message published to the bus can be picked up by a loopback, transformed, retyped, and republished — all without leaving the system. Downstream subscribers see the new shape with a new Message Type and react accordingly.
Outbound map & pipeline, with surrounding variable assignments — optional; same as a send port's outbound flow
Inbound map & pipeline, with surrounding variable assignments — optional; same as a send port's two-way return flow
Publish Message Type Fallback — optional; the Message Type assigned to the looped-back message if the inbound pipeline did not classify it. Without classification and without a Fallback, the loopback raises an error rather than publishing an untyped message. See Message types
No adapter — the loopback turnaround replaces the adapter; the message never leaves the system
The loopback port has two map hookpoints — an outbound map before the turnaround, and an inbound map after it. Both sides take the same three configurations: None (no transform), Typed (a table of maps keyed on source Message Type), and Universal (a single map applied to every message regardless of source). See Maps — Selecting a map for the map-level concept. Typed table rows are unique by source Message Type — the UI enforces that.
The two sides differ on direction. The outbound side moves a message off the bus into the turnaround; the inbound side brings the reshaped message back onto the bus. That difference decides whether a Publish Message Type Fallback applies.
Outbound side — off the bus into the turnaround. The loopback’s subscription expression picks the message off the bus where it already carries a Message Type. That resolved Message Type drives the Typed-table lookup. No Publish Message Type Fallback on this side — nothing needs to fall back to. A loose subscription expression that can match multiple Message Types makes Typed worthwhile, giving the loopback a clean per-type dispatch without forcing one loopback per Message Type.
Inbound side — from the turnaround onto the bus. After the turnaround the message has often been reshaped enough that its Message Type needs to be reclassified before publishing back to the bus. The inbound pipeline can classify it at runtime; if classification doesn’t happen, the port’s optional Publish Message Type Fallback assigns the Message Type. If neither resolves a Message Type, the loopback raises an error — the bus does not accept untyped messages. Pipeline classification to a Message Type that does not exist in the application also errors. The mechanics mirror the receive port inbound.
The loopback’s subscription expression matches a message on the bus and pulls it in. The outbound stages run first — same shape as a send port’s outbound flow, just without an adapter at the end.
As soon as the subscription expression matches and the message enters the loopback, an optional set of variable assignments runs. Capture or compute values from the bus message — correlation IDs, segment counts, routing hints — for use by downstream stages, including the inbound side after the turnaround.
The outbound map transforms the message from the canonical bus shape into whatever shape the inbound side will work with after the turnaround. The map step has three modes — None, Typed (a table of maps keyed on source Message Type), or Universal (one map regardless of source). The source Message Type is whatever the bus message carries, so no Publish Message Type Fallback applies on this side. See the Map configuration on both sides section above.
Pipeline components apply intermediate processing on the way through — formatting, decoration, splitting, or any operation that should happen before the turnaround. Unlike a send port, there is no wire-format concern here because the message never leaves the system; the outbound pipeline runs purely for application-level processing.
A second optional variable-assignment stage runs immediately before the turnaround. Useful for capturing the final shape of the outbound-side output so the inbound side can reference it during reclassification or remapping.
The message folds from the end of the outbound flow into the beginning of the inbound flow without leaving the system. No adapter dispatch, no transport involved — the inbound stages execute on the in-memory result of the outbound stages.
The inbound stages mirror a receive port’s inbound flow. The message goes through variable assignments, an optional pipeline (which can classify it to a new Message Type), an optional map, more variable assignments, and is then published to the bus.
An optional variable-assignment stage runs immediately after the turnaround. Capture values that frame the inbound transformation — segment indexes, computed identifiers, or any flag the inbound pipeline or map will need.
The inbound pipeline pre-processes the message before mapping. A pipeline component can classify the message to a Message Type at this stage — that classified type becomes the source Message Type the map step uses and, in most cases, the Message Type the message will publish with.
The inbound map transforms the message into the canonical shape the bus expects. The map step has three modes — None, Typed (a table of maps keyed on source Message Type), or Universal (one map regardless of source). The Message Type comes from inbound pipeline classification; if classification didn’t happen, the port’s Publish Message Type Fallback assigns it. Without either, the loopback raises an error — the bus does not accept untyped messages. See the Map configuration on both sides section above.
A final optional variable-assignment stage runs immediately before the message is published to the bus. Useful for capturing values from the transformed message that downstream subscribers, routing rules, or tracking will need.
Two options are independent of port type and direction — they apply equally to receive, send, loopback, and null ports.
Exceptions. When enabled, the port has a configured exception Message Type. An error during processing swaps the in-flight message's Message Type to that exception Message Type and re-publishes it. The payload itself is untouched.
Subscribe to the exception Message Type from another port to handle failures centrally — typically a send port that emails an alert, writes to a log, or files a ticket. Error traffic flows on its own Message Type rather than mixed with the original. On the Tracking screen, runs handled by a configured exception path appear as Exceptions; runs that failed without one appear as Errors.
Tracking. Per-port setting with three levels controlling what — if anything — is persisted to the Tracking store on each run.
Set the same level across every port of a flow for a coherent end-to-end view on the Tracking screen. The system also maintains its own minimal internal tracking for running and suspended transactions (used for the runtime dashboard) — that's separate from this configurable Tracking and is always on. Every tracked step writes to the tracking database — mind the cost tradeoff with retention and reindexing jobs.
Send, loopback, and null ports each carry a subscription expression — a Boolean filter evaluated against every message published to the bus. Two-way receive ports carry the Response Subscription Expression for the same evaluation, used to identify which message on the bus is the response to send back to the caller through the same port.
Pub/sub. When a message hits the bus, every subscription is evaluated independently. Each matching port gets its own copy and runs the message through its own flow. The same message can be picked up by any number of ports.
Message Type is the string identifier every bus message carries (similar in concept to BizTalk’s). A subscription expression most often checks the Message Type, but it can reference any of the following:
| Token / source | Resolves to |
|---|---|
{{Message.MessageType}} | The current message’s Message Type identifier |
{{Promoted.Name}} | A promoted property defined on the Message Type (see Message types) |
{{Variable.Name}} | The current value of an application Variable |
| xPath expressions | Values resolved against the message body |
| Custom functions | Runtime-evaluated logic |
That's the loopback port
Reshape a message and republish it to the bus without ever touching an external transport. The way to re-classify or transform a message in-flight inside an application. Next: Null port.