Connecting systems
Adapters
An adapter is the plug between a port and the outside world. Adapters are named by what they do: a Listener brings messages in, a Caller sends them out. Same protocol, two different roles: an API Listener and an API Caller are separate things.
Adapters are pure configuration. Moving an integration from file drop to API is a property change, not a rewrite.
The catalog
| Adapter | Direction | Connects to |
|---|---|---|
| API | Listener and Caller | REST/HTTP endpoints |
| Azure Blob | Listener and Caller | Azure Blob Storage |
| CloudSuite | Listener and Caller | Infor CloudSuite |
| File Share | Listener and Caller | Network file shares |
| MQ Series | Listener and Caller | IBM MQ queues |
| O365 Mail | Caller only | Microsoft 365 mailboxes |
| Salesforce | Listener and Caller | Salesforce |
| SAP | Listener and Caller | SAP |
| Scheduler | Listener only | The clock |
| Service Bus | Listener and Caller | Azure Service Bus |
| SFTP | Caller only | SFTP servers |
| SQL | Caller only | SQL Server / Azure SQL |
The odd one out
The Scheduler is the only adapter that listens to nothing external. It listens to the clock: at the scheduled moment it publishes a trigger message to the bus, and the rest of the flow takes over. It is never a Caller. A classic pairing: the Scheduler fires, and a send port with a SQL Caller runs the extract.
Authentications
Credentials live in one place. An Authentication is a named credential set that adapters reference. Ports themselves hold no credentials; the adapter is what talks to the outside world. Rotate an Authentication once, and every adapter that uses it follows.
Check yourself
Three quick questions on this module, in the same style as the exam. Not graded, not recorded, just practice with instant explanations.