Adapters
The boundary object between a port and an external system - the same role BizTalk adapters and Logic Apps connectors play. Configured on the port, named by intent (Listener for receive, Caller for send), and direction-aware by design.
An Adapter in Art2link ESB handles the protocol-specific work of moving a message between a port and the system on the other side of the wire. The receive port's stage 1 and the send port's stage 5 are both the Adapter - the only stage that is always present in either direction. Everything else (variable assignments, pipelines, maps) is optional; the adapter is what makes a port reach an actual endpoint.
Adapters are configuration-only: switching the transport on an existing port is a property change on the adapter binding, not a redeploy. Pair an adapter with the right Authentication and the runtime resolves the connection at execution time.
If you have used BizTalk adapters or Logic Apps connectors, the mental model carries over almost unchanged. An adapter is the unit that knows how to talk to a specific kind of system - HTTP, SQL, SFTP, a mail server, a queue - and it is the unit you bind to a port to make that conversation happen.
The differences are in two places only, both covered below: how Art2link ESB names adapters (Listener on the receive side, Caller on the send side) and how it handles scheduling (a separate Scheduler adapter rather than per-adapter polling).
Adapters are configured on either a receive port or a send port, and Art2link ESB's architecture rule is that the adapter's name signals where it belongs:
| Side | Suffix | What the adapter does |
|---|---|---|
| Receive port | Listener | Listens for an external system to initiate - an HTTP request, a schedule firing, a queue message arriving. The adapter brings the message into the bus. |
| Send port | Caller | Reaches out to an external system on the integration's behalf - calls an API, writes to a database, drops a file, sends a mail. The adapter takes a message off the bus and dispatches it. |
That is why the receive-side HTTP adapter is called API Listener rather than just API, and the send-side counterpart, when implemented, is the API Caller. The two are different adapters; one listens, one calls.
Whether an adapter is intended for the receive side, the send side, or both - and whether it can run one-way only or also two-way - is decided adapter by adapter. There is no universal rule.
| Property | How it is decided |
|---|---|
| Side - receive vs. send | Some adapters only make sense on one side (a Scheduler can only sit on a receive port; an O365 Mail Sender can only sit on a send port). Others naturally exist on both sides as separate adapters - an API Listener on the receive port, an API Caller on the send port. |
| Mode - one-way vs. two-way | Two-way mode requires the adapter to hold a synchronous channel open and deliver a response - the API Listener is the textbook example. Adapters that are inherently fire-and-forget - the Scheduler, mail send, file drop, queue enqueue - are one-way only. |
BizTalk historically embedded scheduling into receive-side transport adapters - the SQL adapter on a receive location, for example, carries its own polling interval. Art2link ESB does not repeat that pattern. Scheduling is factored out into a single, purpose-built adapter that every other adapter can be triggered by.
The Scheduler adapter is a one-way receive adapter. You configure the schedule (interval, cron-style timing, the other features that come with a dedicated triggering adapter) once on a receive port, and the firing message it produces is published to the bus. From there, any send port subscribed to that message picks it up and runs its adapter.
An adapter does not carry its own credentials. Whatever it needs to reach its endpoint - a connection string, an API key, a certificate, an SFTP key - lives in a separate Authentication object that the adapter references by name.
The pairing is one-to-one at the type level: every adapter type defines exactly one Authentication shape, and an adapter cannot consume an Authentication that belongs to a different adapter type. A SQL Caller adapter pairs with a SQL Authentication, an API Caller adapter pairs with an API Authentication, and so on. The fields each Authentication exposes are determined by its adapter type.
The catalogue grows with customer demand - new adapters are prioritised by what the deployments in flight need first. The current set:
| Adapter | Side | Status |
|---|---|---|
| Scheduler | Receive | Shipping |
| API Listener | Receive | Shipping |
| SQL Caller | Send | Shipping |
| API Caller | Send | Shipping |
| O365 Mail Sender | Send | Shipping |
| SFTP Caller | Send | Shipping |
| MQ Series | — | Beta |
| Service Bus | — | Beta |
| File Share | — | Beta |
| Azure Blob | — | Beta |
One-way receive adapter that fires on a schedule and publishes a triggering message to the bus. This is the building block that replaces per-adapter polling everywhere else - configure the timing on the Scheduler's receive port, route the firing message to whichever send port should run, and the work happens there. Inherently one-way: the adapter has nothing to wait for.
Hosts an HTTP endpoint that external systems call into. The textbook two-way receive adapter: it can run one-way (accept the request, publish to the bus, return immediately) or two-way (hold the caller's connection open, wait for a matching response message on the bus, deliver it back synchronously). The two-way subscription expression on the receive port is what lets the response find its way back to the original request.
Send-side adapter that runs queries against a SQL database. Pairs with a SQL Authentication holding the connection string. Common pairing: a Scheduler receive port routes a firing message to a SQL Caller send port, which queries the database, and the result re-enters the bus - effectively the Art2link ESB equivalent of BizTalk's polling SQL receive location.
Send-side counterpart to the API Listener. Reaches outbound to an HTTP endpoint, dispatches the message, and (in two-way mode) handles the response and republishes it back to the bus.
Sends email through Microsoft 365 / Exchange Online. One-way by nature - once a mail is dispatched there is no synchronous response to wait on.
Sends files to an SFTP server. Pairs with an SFTP Authentication carrying host, credentials, and key material.
IBM MQ integration. In active development - receive vs. send role and supported modes will be confirmed when the adapter ships.
Azure Service Bus integration. Receive vs. send role and supported modes TBD.
SMB / network file share integration. Receive vs. send role and supported modes TBD.
Azure Blob Storage integration. Receive vs. send role and supported modes TBD.
The shape of an adapter
One transport concern per adapter, named by the side it belongs on (Listener for receive, Caller for send), paired with the matching Authentication, and triggered - when scheduling is involved - by routing through the Scheduler rather than baking timing into the transport itself.