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.
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. The Map Assignment setting takes three values: 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’s Map Assignment setting 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, set on the Subscription tab at the top of the editor’s Response group, 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.
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 evaluated against every message on the bus. A two-way receive port additionally carries a Response Subscription Expression, evaluated the same way, that identifies which message on the bus is the response to send back to the caller through the same port. The full treatment, with diagrams and the subscription token list, lives once under Options available on every port and Subscriptions and Message Types on the Ports overview.
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.