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
Message Type on the looped-back message, always present, not a separate setting; the message enters the loopback off the bus already typed and every component and map it passes through leaves a Message Type on it explicitly, so it reaches the bus typed. 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: Port Type Loopback, one of the four values that dropdown carries, Way pinned to Two, the same Solicit tabs the send port has (Subscription, Open Variables, Map, Pipeline, Close Variables) and the same Response group, Exception Message Type included. Because it borrows the send-port editor, the groups read the send-port way round: Solicit is the leg leaving the bus and Response is the leg coming back onto it, which on a loopback is the turnaround rather than a wire. See Components classify the Message Type for the four positions.
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, in the sense set out in Components classify the Message Type: direction belongs to the position, not to the pipeline or the map. The outbound side moves a message off the bus into the turnaround; the inbound side brings the reshaped message back onto the bus. The typing rule is the same at both, every component sets a Message Type on every message it emits, and a map replaces it with the map’s target type.
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, and that type drives the Typed-table lookup. 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 it should publish under a different Message Type. This is an inbound position, the message is entering the bus, and the rule that governs the two adapter-backed inbound positions holds here too: nothing reaches the bus untyped. On a loopback there is no adapter and so no adapter handoff to stamp at, the message folded in off the bus already typed, and each pipeline component sets a Message Type explicitly on every message it emits while a map replaces it with the map’s target type. Naming a Message Type that is not defined in the Application is an error. The mechanics otherwise mirror the receive port inbound, see Receive port.
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 the one the bus message was published under, which is what it carries when the subscription expression picks it up. 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. Every message a component emits carries a Message Type set explicitly on it, so a split into many messages means many types set, and that holds here as it does at every other pipeline position. See Components classify the Message Type. 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 (whose components set a Message Type on everything they emit, commonly a new one), 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. Each component sets a Message Type explicitly on every message it emits here, whether that is the type it was handed or a new one; the type the last component leaves 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 source Message Type is whatever the message is carrying when it reaches this stage: the type it folded in with if no inbound pipeline ran, otherwise the type the last component set on it. 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, and write a subscription expression, the Boolean filter evaluated against every message on the bus, that selects which messages this port consumes. Tracking is not set on the port: one of the three levels is chosen on the Application and decides what every one of its ports persists. All 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.