Creating an Adapter
Creating an adapter declares a new connection to the platform. The wizard walks six steps, Basics, Pattern, Artifacts, Connectors, Routes, and Review, capturing what the platform needs to stand the connection up. New adapters are created in the off state, so nothing you enter reaches the external system until you enable the adapter after saving.
Before you start
Two dependencies must already be in place when you open the wizard. Neither can be resolved from inside the wizard itself.
| Dependency | Why it must exist first | How to check |
|---|---|---|
| The plugin that provides your connection type is installed | The Connectors step only offers connection types that installed plugins expose. A missing plugin means the type is not in the list. | Open Plugin Management in the Portal. Confirm the plugin for your protocol is listed. |
| Any reference files the connection needs are uploaded as artifacts | The Artifacts step selects from files already uploaded; it does not upload. A missing file means the selection list is empty. | Open Artifacts in the Portal. Confirm the files appear by name. |
If the plugin is not installed, contact your administrator; plugin installation is a platform-level operation. For artifact upload, see Artifacts.
Step 1: Open the wizard
Go to Adapters and click New Adapter. The wizard opens on the Basics step. The adapter is created in the off state, so no decision you make is visible to the external system until you enable it at the end.
Step 2: Basics
The Basics step (titled Adapter Identity) captures how the platform labels this adapter.
| Field | What to fill in | Why it matters |
|---|---|---|
| Adapter Name | A unique, human-readable name of at least three characters, for example Chicago-FIX-Router-01. Include the counterparty and direction. | Identifies the adapter in the Portal and in logs. A clear name shortens every future investigation. |
| Logical ID | Read-only. The Portal derives it from the name. | The stable identifier used by Infrastructure-as-Code and bundle export. It is fixed once the adapter is created, so get the name right here. |
The Basics step does not set redundancy. How the adapter is deployed (standalone versus a scale-out cluster) is decided in the next step.
Step 3: Pattern
The Pattern step (titled Configuration Strategy) offers two cards: whether this adapter gets its own configuration or reuses one that already exists.
| Card | What it does |
|---|---|
| Custom Topology (tagged Advanced) | Builds a fresh configuration from scratch: you define the connectors, pipelines, and settings yourself. This is the right choice for a first adapter, despite the "Advanced" tag. |
| Use Existing (tagged Standard) | Starts from a configuration already in the library. After you select one, choose how this adapter relates to it: Clone (Copy) makes a standalone duplicate you can edit independently, or Link (Shared) joins it as a scale-out cluster where several pods serve it concurrently. |
This choice sets the adapter's deployment shape (standalone versus scale-out). For what that means for failover and redundancy, and how to pick, see Adapters Overview and Deployment Topologies.
Link (Shared) runs more than one copy of the adapter at once (scale-out), which needs enough capacity for the extra pods. Confirm capacity with your administrator before choosing it.
Step 4: Artifacts (optional)
The Artifacts step selects the reference files this adapter depends on, for example a data dictionary or a schema. Search the library by filename and select what this connection needs. The files must already be uploaded on the Artifacts page; the wizard selects from what exists, it does not upload. Skip this step if your connection needs no reference files.
Step 5: Connectors
The Connectors step configures the two ends of the connection: the Source Endpoint and the Target Endpoint. For each endpoint you choose the connection type ("Choose the protocol or system adapter"), give it a Display Name, and fill the fields that the chosen plugin provides.
The values for these fields come from the external system's connectivity team or your Connamara representative. Enter the values they provide. Do not invent defaults for connection identifiers, endpoint addresses, or session parameters; a guessed value produces an adapter that reaches Error on first enable.
For protocol-specific field guides, see the Official Plugins documentation.
Step 6: Routes
The Routes step (titled Data Pipelines) defines what happens to each message between the source and the target. At least one route with a Send Processor is required for the adapter to deliver anything. An adapter with no route, or a route with no Send Processor, consumes each message, acknowledges it, and sends nothing, so it is silently dropped even while the adapter shows Running. What is optional is the filtering and reshaping: a minimal delivering route is a Send Processor from the source to the target, with no conditions or transforms. Open the Pipeline Designer on a route to add the Send Processor (from the Actions & Sinks group) and to filter, reshape, or enrich messages.
Add pipeline logic when any of these apply:
- Messages the destination does not need should be dropped before delivery.
- The destination expects different field names, formats, or a different shape than the source produces.
- Something should happen on the side (enrichment, logging, routing) without changing the message itself.
See Pipeline Designer for the stages and how to choose between them.
Step 7: Review and provision
The Review step validates the configuration and summarizes every decision from the previous steps. Read it end-to-end. Small typos in connection settings are a common reason an adapter fails to reach Running on first enable; catching them here is faster than catching them in the event log afterward.
Click Provision Adapter. This saves the configuration; the adapter is created disabled, so nothing connects to the external system until you enable it in the next step.
Step 8: Turn it on
On success the wizard shows a confirmation with an Open control page button. Click it to go straight to the new adapter (or find the adapter in the Adapters list and click its name), then click Enable.
Status moves from Inactive through Provisioning to Running as the platform places the adapter on an available server and establishes the session. When Status shows Running, the adapter is live and processing.
| First-enable outcome | Meaning | Next step |
|---|---|---|
| Status reaches Running | The session is established and the pipeline is running. | No action. The adapter is live. |
| Status remains Provisioning | The platform is still trying to place the adapter and establish the session. | Open the adapter and read its most recent event log entries. |
| Status shows Error | The adapter started but reported an unhealthy state. | Read the event log entry preceding the Error; it names the cause. See Troubleshooting. |
Editing an adapter
To change the configuration after creation, open the adapter from the Adapters list and edit its configuration. Saving applies the change on the adapter's next heartbeat, not instantly, and the platform then restarts the adapter to apply it: the pod drains in-flight messages, closes the session cleanly, and reconnects.
If the adapter runs with a standby (two or more pods), the change is a handoff to the standby; with a single pod it is an in-place restart with a brief reconnect gap. Either way the external system sees a proper disconnect and reconnect, not a dropped link. Edit connection-critical fields during a maintenance window if even a brief interruption matters.
See also
- Adapters Overview: adapter status, and standalone versus scale-out deployment.
- Artifacts: uploading reference files an adapter will consume.
- Pipeline Designer: when and why to add pipeline logic to a route.