Send port
Send ports are how messages leave Art2link ESB. They subscribe to the bus, run the matched message through optional variable, map, and pipeline stages, and hand it to an adapter for dispatch.
A send port is the mirror of a receive port. Where the receive port accepts a message and publishes it to the bus, the send port subscribes to the bus and dispatches matching messages out through an adapter. The subscription expression selects messages off the bus, every message that satisfies the expression is picked up and run through the outbound flow.
One-way mode ends at dispatch. Two-way mode keeps the integration thread alive and captures whatever the adapter produces in response, then publishes it back to the bus where the integration can continue.
Variable assignments, optional; can run before and after the map and pipeline stages, in both directions. See Variables
Outbound map & pipeline, optional; transforms and post-processes the message on the way out. See Maps and Pipelines
Adapter, required; defines the protocol (HTTP request, file write, email send, queue enqueue, etc.). See Adapters
Inbound map & pipeline, optional, used only in two-way; pre-processes and transforms the response
Publish Message Type Fallback, optional, two-way only; the Message Type assigned to the response if the inbound pipeline did not classify it. Without classification and without a Fallback, the port raises an error rather than publishing an untyped response. See Message types
In the port editor the Solicit group carries the sublabel Bus → Adapter and lists these stages in their running order: Subscription, Open Variables, Map, Pipeline (an Outbound Pipeline selector), Close Variables; the Response group (Adapter → Bus) holds the two-way return flow.
The send port has two map hookpoints, an outbound map on the request side, and (in two-way mode) an inbound map on the response side. Both sides take the same three Map Assignment values: 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 request side moves a message off the bus to the partner; the response side brings the partner’s reply onto the bus. That difference decides whether a Publish Message Type Fallback applies.
Request side, outbound from the bus. The send port’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. With a loose subscription expression that can match multiple Message Types (for example one keyed on a partner identifier rather than a Message Type), Typed gives the port a clean per-type dispatch without forcing one send port per Message Type.
Response side, inbound to the bus. The response is whatever the partner returned through the adapter, so its Message Type is not yet known when it arrives. 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 so the response can publish to the bus. If neither resolves a Message Type, the port 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. Once typed, the map step proceeds in whichever mode is configured.
The send port's job ends the moment the adapter dispatches the message. There is no return path, the adapter does its work, and the integration thread for this message terminates. This is the model for fire-and-forget destinations: file writes, queue enqueues, and any flow where the integration has no interest in what happens after the message leaves.
Once the send port's subscription expression matches a message on the bus, that message enters the port. An optional set of variable assignments runs first. Capture or compute values from the source message (target endpoint URL, recipient address, batch number, correlation IDs) and store them as variables that downstream stages and the adapter itself can reference. A single message on the bus can satisfy multiple subscriptions; every matching send port handles its own copy independently.
The outbound map transforms the message from the canonical shape on the bus into the shape the destination system expects. The Map step uses the same Map Assignment modes described above (None, Typed, or Universal). The source Message Type is whatever the bus message carries when the subscription expression picks it up, so no Publish Message Type Fallback applies on this side. See the Map configuration on both sides section above.
The outbound pipeline applies post-processing on the way out, compression, encryption, signing, or framing the message for the wire.
A second optional variable-assignment stage runs after the pipeline, immediately before the adapter takes over. Useful for setting last-mile values such as outbound headers, request identifiers, or tracking values that depend on the final wire-shape of the message.
The adapter takes the prepared message and handles the wire-level conversation with the destination system, opening an HTTP request, writing a file, sending mail, enqueueing on a broker. In one-way mode the send port's work is done the moment the adapter completes dispatch.
A two-way send port runs the entire one-way flow above to dispatch the message, and then captures whatever the adapter produces afterwards as a response. The response runs through the inbound stages (variable assignments, an inbound pipeline, and an inbound map) and is then published back to the bus, where the integration can pick it up and continue.
Two-way on a send port is not always about receiving a meaningful payload from the wire. Some adapters simply have nothing useful to return, an Email sender, for example. The point of two-way is to keep the integration thread alive after the dispatch so a downstream subscriber can react. The response message can have an empty body; what matters is that it reaches the bus with a resolved Message Type, from inbound pipeline classification, or, if classification doesn’t happen, from the port’s Publish Message Type Fallback, so downstream subscribers can match on it reliably.
Note the order on the way back: pipeline first, then map, the inverse of the outbound order. The pipeline handles transport-level pre-processing such as decompression or signature verification before the map reshapes the response into the canonical form used inside the application.
Once the wire-level send completes, the adapter produces a response. For some adapters that response is the actual reply payload from the destination, an HTTP response body, for instance. For others it is just an acknowledgement that the dispatch finished, with no meaningful payload, an Email sender, for example. Either way, the adapter hands the response off to the inbound flow of the send port.
Optional variable assignments run immediately after the adapter. Capture transport-level metadata from the response (status codes, response headers, identifiers issued by the destination) for use further down the inbound flow or by downstream subscribers on the bus.
The inbound pipeline pre-processes the raw response from the wire, typical examples are decompression, character-set normalization, signature verification, or splitting a multi-record response into individual messages.
The inbound map transforms the response from its wire shape into the canonical shape used inside the application. The Map step uses the same Map Assignment modes described above (None, Typed, or Universal). The source Message Type comes from pipeline classification at the previous stage; if classification didn’t happen, the port’s Publish Message Type Fallback takes effect. Without either, the response cannot publish and the port raises an error.
A final optional variable-assignment stage runs immediately before the response is published to the bus. Useful for capturing values from the transformed response that downstream subscribers, routing rules, or activity 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 send port
Subscribe to the bus, transform on the way out, dispatch through any adapter. One-way fire-and-forget, or two-way with the response back on the bus for downstream subscribers. Next: Loopback port.