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 is in one of two states: Running or Stopped. There is no separate publish or deploy step, everything you configure on a port is saved and applied immediately. The state only controls whether the port is live: a running port listens, dispatches, or subscribes; a stopped port is inert and takes no part in routing. The actions that move it between them are Start, Stop, and Restart; Restart is a convenience that stops and starts the port in one step, for example to reset a Scheduler receive port’s timer, an action, not a third state. A Paused state for subscriber (send) ports is coming soon: a paused port's subscriptions keep matching and the matched messages are held, not consumed, until the port is started again, the same hold BizTalk operators got by stopping a send port without unenlisting it, useful during deployments and cutovers.
Building a port. Save Draft stores a port with nothing more than a name; a draft is invisible to the runtime, as if the port did not exist, so you can open one, go gather the details you are missing, and pick it up later. Once the required fields are filled in, Save stores the port properly, and a saved port can never return to draft. Because a stopped port does nothing on the bus, you keep configuring it, adapter settings, pipelines, maps, subscription expressions, while it is stopped, taking as long as you need, with each change stored as you make it. When it is ready, start it.
What a stopped port is. Values you have entered are still validated as you save them (a port will not store an illegal value), but a stopped port may sit with its configuration incomplete.
Starting a port. Starting runs the full validation a live port requires: if anything is missing or invalid the same errors surface and the port stays stopped, with nothing lost. Once validation passes the port is live immediately, there is nothing further to deploy. Starting and stopping are reversible: stop a running port and it goes inert again, then start it again when you are ready. To bring a whole integration online, start the send ports first and the receive ports last, so a receive port never publishes to the bus before its subscribers are live; to take it offline, stop the receive ports first.
Port names follow the usual rule: a name must be unique within its Application whether the port is running or stopped, the two states share one namespace.
A port is edited in a single dialog. The sidebar starts with General and then groups every processing stage under two headings, Solicit and Response. Each carries a direction sublabel that follows the port type, Caller → Bus / Bus → Caller on a receive port, Bus → Adapter / Adapter → Bus on a send port: Solicit is always the initiating leg, Response the return. The names are grouping labels, nothing more; they were chosen over “request” because not every adapter requests anything, a Scheduler receive port solicits a tick rather than receiving a request. BizTalk veterans will recognise the term.
The General tab holds the port’s identity and switches: Name, Application, Type, the Adapter with a button beside it that opens the adapter’s own configuration dialog, Tracking, the Exception Message Type (covered below), Way (One or Two), and the Status toggle (Running or Stopped). The footer carries the Save Draft and Save buttons described in the lifecycle section above.
On a receive port the Solicit stages appear, and run, in this order: Open Variables → Pipeline → Publish → Map → Close Variables. On a send port the group opens with Subscription, the home of the subscription expression, and continues Open Variables → Map → Pipeline → Close Variables; there is no Publish step on the way out, the matched message already carries its Message Type, and the adapter dispatch follows Close Variables. The Pipeline is where a component may classify the message; the Publish step holds the Message Type Fallback that applies when it did not. One distinction is worth keeping sharp: the Publish step is configuration, while publishing is the verb for the moment a message lands on the bus, which on a receive port happens after Close Variables, as the final act of the flow. The Map step’s configuration and each stage’s behaviour are covered per port type in Receive port and Send port.
On a two-way receive port the Response group opens with the Subscription tab, the home of the Response Subscription Expression, followed by Open Variables → Map → Pipeline → Close Variables, the inbound flow mirrored.
Loopback and null ports reuse the send-port editor with the Adapter picker empty. Way is pinned, Two for a loopback, One for a null port, and the null port drops both the Response group and the Exception Message Type field.
Two configuration options are independent of port type and direction and apply equally to receive, send, and loopback ports; a null port carries Tracking only, its editor has no Exception Message Type field.
Exceptions. Exceptions are configured by setting the port’s 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. Explore each in detail: Receive port, Send port, Loopback port, Null port.