Receive port
Receive ports are how messages enter Art2link ESB. Bound to a transport adapter, they accept incoming traffic and publish it to the bus through optional variable, pipeline, and map stages.
A receive port is the entry point for messages into Art2link ESB. It binds an adapter to a sequence of optional transformations and publishes the result to the bus. From the bus, the message continues its journey: a send port, a loopback, or the response side of a two-way receive port picks it up.
Every receive port is configured as either one-way or two-way. One-way is fire-and-forget, the adapter accepts the message and disconnects. Two-way keeps the caller's connection open and waits for a matching response message to come back through.
Every message published to the bus must carry a Message Type. On the inbound side of a receive port the Message Type is resolved in two places, a pipeline component can classify the message at runtime, and if no classification happens the port’s optional Publish Message Type Fallback takes effect. If neither resolves a Message Type, the port raises an error. Pipeline classification to a Message Type that does not exist in the application also errors.
Once the Message Type is known, the inbound map step runs, or doesn’t. There are three map configurations: None (no transformation), Typed (a table of maps keyed on source Message Type; the row whose source matches the resolved Message Type is applied, a miss is a no-op), and Universal (a single map applied to every message regardless of source). Typed table rows are unique by source Message Type, the UI enforces that.
The receive port's job ends the moment the message reaches the bus. There is no response back to the caller, the adapter acknowledges receipt and disconnects. This is the model used by triggers (e.g. the scheduler adapter), file pickups, queue dequeues, and any flow where the upstream system does not expect a synchronous reply.
The adapter is the only stage that is always present. It handles the wire-level conversation with the caller, accepting an HTTP request, opening a file, polling a schedule, dequeueing from a broker. Once the adapter has the message in hand, it hands control to the rest of the receive port.
An optional set of variable assignments runs before the pipeline. Capture values from the incoming message or its context (headers, query parameters, file name, sender identity) and store them as variables that downstream stages, routing rules, send ports, and tracking can reference later.
A sequence of pipeline components that pre-process the message, typical examples are decompression, character-set normalization, signature verification, or splitting a multi-record file into individual messages.
Transforms the message from the source shape into the canonical shape used by the rest of the application. The map step has three modes, None (skipped), Typed (a table of maps keyed on source Message Type; the row that matches the resolved Message Type is applied), or Universal (one map applied to every message regardless of source). When a map runs, its target Message Type carries forward as what gets published. See the Publish Message Type Fallback and map configuration section above. Maps are configuration-only and take effect on save.
A second optional variable-assignment stage runs after the map. This is the place to capture values from the transformed message, values that are often used by routing logic, by send ports later in the flow, or by activity tracking.
A two-way receive port runs the entire one-way flow above to publish the request to the bus, and then keeps the caller's connection open while it waits for a response message to appear on the bus. The matching is driven by the port's Response Subscription Expression, a Boolean expression evaluated against every message published to the bus. The first message that satisfies it is picked up as the response and delivered back to the caller through the mirror image of the inbound flow on this same port.
Note the order on the way out: map first, then pipeline, the inverse of the inbound order. The response is reshaped into the caller's expected format before the pipeline applies any transport-level post-processing such as signing, compression, or framing.
Map configuration on the response side mirrors the request side, None, Typed, or Universal. The response message comes off the bus already typed, so there is no Publish Message Type Fallback on this side: the resolved Message Type is whatever the bus message carries when the Response Subscription Expression picks it up.
Once the port's Response Subscription Expression matches a message on the bus, that message is picked up as the response. Optional variable assignments run immediately, before the outbound map. Inject correlation values, derived headers, or any context-specific fields the response shape will need.
Transforms the response message from the canonical shape on the bus into the shape the original caller is expecting. Map configuration mirrors the request side, None, Typed (dispatched by source Message Type), or Universal (one map for any source). The response comes off the bus already typed, so there is no Publish Message Type Fallback on this side.
Applies post-processing on the way out, typical examples are compression, encryption, signing, or framing.
A final optional variable-assignment stage runs immediately before the response is handed back to the adapter. Useful for setting outbound headers, status codes, or tracking values.
The adapter sends the response back to the caller on the still-open connection. The two-way conversation closes.
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 receive port
Bind a transport adapter, layer on optional variable, pipeline, and map stages, and you have an entry point into Art2link ESB, one-way fire-and-forget, or two-way with a synchronous response held open for the caller. Next: Send port.