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. 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
In the port editor a loopback is the send-port dialog with the Adapter picker empty: Type Loopback, Way pinned to Two, the same Solicit tabs (Subscription, Open Variables, Map, Pipeline, Close Variables) and Response group, Exception Message Type included.
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 uses the same modes described above (None, Typed, or Universal). 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 uses the same modes described above (None, Typed, or Universal). 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.
Exceptions, Tracking, and Subscriptions work the same on every port. Set the port’s Exception Message Type to re-publish failures on their own Message Type; choose one of the three Tracking levels for what each run persists; and write a subscription expression, the Boolean filter evaluated against every message on the bus, that selects which messages this port consumes. These three behave identically on every port and are documented once, with diagrams and the full subscription token list, under Options available on every port and Subscriptions and Message Types on the Ports overview.
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.