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
Adapter Message Type, required, two-way only; the Message Type stamped on the response the instant the adapter hands it to the next step inside the port. See Message types
In the port editor the Port Type dropdown on the General tab is set to Send, and on a send port the Solicit group is the outbound leg, sublabelled Bus → Adapter, listing these stages in their running order: Subscription, Open Variables, Map, Pipeline (an Outbound Pipeline selector), Close Variables; the send port’s Response group (Adapter → Bus) is the inbound leg, holding the two-way return flow. That is the mirror image of a receive port, where Solicit is inbound and Response outbound, so read the group name with the port type in hand; the four positions are set out in Components classify the Message Type.
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, in the sense set out in Components classify the Message Type: direction belongs to the position, not to the pipeline or the map. The request side is an outbound position, it moves a message off the bus to the partner. The response side is an inbound position, it brings the partner’s reply onto the bus. That difference decides where the Adapter Message Type sits.
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, and that type drives the Typed-table lookup. No Adapter Message Type on this side, the message is leaving the bus rather than entering it, so nothing needs stamping at a handoff. The type still matters on the way out, it governs how the message is treated as it is framed for the wire, and any component in the outbound pipeline sets a Message Type on every message it emits. 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.
A send port’s Response side, inbound to the bus. The response is whatever the partner returned through the adapter, and this is one of the two positions where a message enters the bus, so the port carries a required Adapter Message Type. The runtime stamps it the instant the adapter hands the response to the next step inside the port, ahead of Open Variables, the pipeline, and the map. The underlying property is Port.receivedMessageTypeId. From there each component in the inbound pipeline sets a Message Type explicitly on every message it emits, and 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 map step then proceeds in whichever mode is configured, matching on whatever type the message is carrying by that point.
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 the one the message was published under, which is what it is carrying when the subscription expression picks it off the bus. This is an outbound position, so there is no Adapter Message Type 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 typed, and it does, because the port’s required Adapter Message Type stamps it at the adapter handoff and every component after that re-states a type on what it emits. 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 response from the wire, typical examples are decompression, character-set normalization, signature verification, or splitting a multi-record response into individual messages. The response reaches this stage already carrying the port’s Adapter Message Type, and every message a component emits carries a Message Type of its own, set explicitly, so a split into many messages means many types set. See Components classify the Message Type.
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 is whatever the message is carrying when it reaches this stage: the port’s Adapter Message Type if no pipeline ran, otherwise the type the last component set on it.
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, 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 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.