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
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 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 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 has three modes — None, Typed (a table of maps keyed on source Message Type), or Universal (one map applied regardless of source). 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 has three modes — None, Typed (a table of maps keyed on source Message Type), or Universal (one map applied regardless of source). 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.
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.MessageType.Name}} | A promoted property defined on the Message Type (see Message types) |
{{Variable.Name}} | The current value of an application Variable |
{{Config.PortName}} | The Name of the port the current message originated from |
{{Message.Body}}.XPath() | A value read from the message body — XPath (XML) or JPath (JSON) |
| Custom functions | Runtime-evaluated logic |
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.