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.
Adapter Message Type, required; the Message Type stamped on the message the instant the adapter hands it to the next step inside the port. See Message types
Variable assignments, optional; can run before and after the pipeline and map stages, in both directions. See Variables
Inbound pipeline & map, optional; pre-processes and transforms the message on the way to the bus. See Pipelines and Maps
Outbound map & pipeline, optional, used only in two-way; reshapes and post-processes the response on the way back to the caller
Response Subscription Expression, required in two-way; identifies which message on the bus is the response to hand back to the caller
In the port editor the port’s Adapter Message Type is set on the General tab, in the same General Information panel as Name, Application, Port Type (set to Receive here), and Adapter. On a receive port the Solicit group is the inbound leg, sublabelled Caller → Bus, and lists the stages in their running order: Open Variables, Pipeline (an Inbound Pipeline selector), Map, Close Variables; the receive port’s Response group (Bus → Caller) is the outbound leg, holding the two-way return flow, and opens with Subscription. The two names point the other way round on a send port, so read them with the port type in hand; the four positions are set out in Components classify the Message Type.
Every message published to the bus carries a Message Type, and on a receive port the message has one from the first instruction onwards. The port’s Adapter Message Type is required, and the runtime stamps it the instant the adapter hands the message to the next step inside the port, ahead of Open Variables, the pipeline, and the map. There is no untyped window at the entry and nothing to fall back to, because the message is already typed before the first stage inside the port runs. The underlying property is Port.receivedMessageTypeId.
From there the type is restated, never assumed. Every message a pipeline component emits carries a Message Type set explicitly on the outgoing message, whether that is the same type the component was handed or a different one, and a component that splits an interchange into two hundred messages types all two hundred. A map replaces the type with the map’s target type. Emitting a message with no Message Type is not blocked by the platform, it simply leaves the downstream result undefined, so the rule is yours to keep. Naming a Message Type that is not defined in the Application is an error. The rule is identical wherever a pipeline is attached: see Components classify the Message Type for the definition of direction and of the typing rule.
The inbound map step then 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 Message Type the message is carrying at that point 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. The pane itself is a single selector, Inbound Pipeline, defaulting to None. The message arrives here 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 two hundred messages means two hundred types set. See Components classify the Message Type.
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 Message Type the message is carrying 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 Adapter Message Type 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. This is an outbound position, the response is leaving the bus rather than entering it, so there is no Adapter Message Type here: the message comes off the bus with the type it was published under, and that type drives the Typed-table lookup. It still matters on the way out, because it governs how the response is treated as it is framed for the caller, and any component in the outbound pipeline sets a Message Type on everything it emits just as it would anywhere else. See Components classify the Message Type.
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). This is an outbound position, so there is no Adapter Message Type here: the message came off the bus with the type it was published under, and that is what the Typed table matches on.
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, and write a subscription expression evaluated against every message on the bus. 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. 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.