Ports
Ports are the entry and exit boundaries of an integration. Every message in Art2link ESB enters, exits, or is rerouted through a port, and four port types together cover every direction a message can take.
A port binds a configurable processing flow — variable assignments, pipelines, and maps — to either a transport adapter (for receive and send ports), an in-system fold-back (loopback), or a terminal sink (null). The four types share the same stage model; what differs is what sits at the boundary and which directions of the flow are active.
The bus referenced throughout this page is Art2link ESB's internal message fabric, not Azure Service Bus. Messages flow into the bus from receive ports, are picked up off the bus by send, loopback, and null ports through subscription expressions, and — for two-way and loopback flows — are published back to the bus when a response is produced.
Ports are scoped to an Application. Each Application has its own private bus, and a port can only reference resources defined in the same Application — Authentications, Pipelines, Maps, Message types, Schemas, and Variables.
The list view follows the platform's Selected Application behavior — with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to. Creating a new port works the same way: an Application selection preempts the picker.
A port exists in one of two states: Draft or Published. Configuring a port can run long — adapter settings, pipelines, maps, subscription expressions — and not all of it has to be finished in one sitting. Saving as a Draft lets you capture a half-configured port and come back to finish it later.
Creating a port. The editor offers two actions. Save as Draft stores the port in whatever state it is in, as long as it has a name and belongs to an Application — nothing else is mandatory. Save finalizes the port as Published and applies the full validation a port has always required.
What a Draft is. A Draft is inert. It is held separately and takes no part in routing — it does not listen, dispatch, or subscribe, and the runtime ignores it entirely until it is Published. A name and an Application are the only requirements to keep one on file; every other field may be left incomplete. Fields that do carry a value are still validated, though — a Draft will not store an illegal value, only an absent one.
Publishing a Draft. Open a Draft and the editor shows a Publish button. It runs the same full validation as a normal save: if anything is missing or invalid, it surfaces the same errors you would see saving a port the conventional way, and the port stays a Draft with nothing lost. Once validation passes, the port becomes Published.
Publishing is one-way. A Published port cannot return to Draft. Port names follow the usual rule throughout: a name must be unique within its Application across both Drafts and Published ports — the two share a single namespace, so a Draft cannot reuse a name already taken by a Published port, or the reverse.
Two configuration 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. On error, the in-flight message's Message Type is swapped to the exception Message Type and republished to the bus — the payload itself is untouched. Subscribe to that Message Type from another port to handle the failure centrally (a send port that emails an alert, writes to a log, files a ticket). Error traffic flows on its own Message Type rather than mixed in with the original.
Tracking. Per-port setting with three levels. Set the level uniformly across every port of a flow to see its full end-to-end execution on the Tracking screen.
A separate, minimal internal tracking is always on for the runtime dashboard (running and suspended transactions) — it does not depend on this setting. Mind the cost tradeoff: every tracked step writes to the tracking database and is subject to retention and reindexing jobs.
Send, loopback, and null ports each carry a subscription expression — a Boolean filter the bus evaluates against every published message. Two-way receive ports use one as well, the Response Subscription Expression, to identify which message on the bus is the response to send back to the caller through that same port.
Pub/sub. When a message hits the bus, every send, loopback, and null port has its expression evaluated. Every match gets its own copy and runs its outbound flow independently. The same message can be picked up by any number of ports — or by none.
Message Type. Every message on the bus carries a Message Type — a string identifier, similar in concept to BizTalk's. Subscription expressions most commonly match on it, but can evaluate any of six sources:
For the complete binding-token reference — every family above plus Constants, and where each is used — see Expressions & bindings.
That is the full set of ports
Receive brings messages in. Send takes them out. Loopback transforms and republishes without leaving. Null consumes and discards. Together they cover every direction a message can take through Art2link ESB. Explore each in detail: Receive port, Send port, Loopback port, Null port.