Plugins
Plugins are how the platform acquires new capabilities without changing the platform itself. Every connection type the wizard offers and every component the Pipeline Designer exposes came from a plugin installed on the environment. Remove the plugin and the capability disappears from the Portal; add one and new options show up.
Plugin lifecycle (install, uninstall, upgrade) is an administrative operation. The Portal's Plugin Management page provides the controls for it, and in most deployments your administrator owns plugin changes. Other Portal users simply consume the capabilities that installed plugins provide.
What a plugin contributes
A plugin extends the platform in two directions. The direction decides where in the Portal the capability appears.
| Contribution surface | What the plugin adds | Where it shows up |
|---|---|---|
| Configuration (what you see in the Portal) | Schemas and option sets that describe what a connection or pipeline component accepts. | The fields and dropdowns rendered inside the adapter wizard and the Pipeline Designer. Installing the plugin makes new form fields and list entries appear. |
| Runtime (what runs when the adapter is enabled) | The logic that executes when an adapter runs: opening sessions, reading messages, applying filters and transforms, writing to targets. | Not visible as its own UI, but observable as message traffic once an adapter configured to use the plugin is enabled. |
Most plugins contribute to both surfaces. A connectivity plugin exposes the connection type to the wizard (configuration surface) and the session runtime that speaks the protocol (runtime surface). A pipeline plugin exposes the component to the Pipeline Designer (configuration surface) and the per-message logic (runtime surface).
The consequence for operators: a capability that is not visible in the Portal is a capability whose plugin is not installed. If the wizard does not list the connection type you need or the Pipeline Designer does not show the component you expect, the first diagnostic is to check what is installed.
Plugin categories
Installed plugins typically fall into the categories below.
| Category | What they add | Where it lives in the Portal |
|---|---|---|
| Connectivity plugins | Connection types (sources and targets): new protocols, new messaging systems, new inbound or outbound endpoints. | Connection type dropdown in the adapter wizard. |
| Pipeline plugins | Processing components: filters, transforms, processors (for example, field mappers, loggers, enrichers). | Component list inside each pipeline stage in the Pipeline Designer. |
A single plugin can contribute both. The officially supported connectivity plugins ship both a connector and pipeline components tailored to the same protocol.
Viewing installed plugins
Open Plugin Management in the Portal. The page lists every plugin installed on the environment in a table with these columns:
| Column | What it shows |
|---|---|
| Plugin | The plugin's package name. |
| System ID | The plugin's unique system identifier. |
| Version | The installed version. |
| Status | Whether the plugin is active or newly added. |
| Installed | When the plugin was added to the environment. |
| Actions | Download the plugin package, or uninstall it. |
The page also has an Upload control for adding a plugin package and a Repair DB control that rebuilds the plugin registry from the packages already on the environment. An upload is rejected up front if the package was built against an SDK the environment cannot host (a different major, or a newer minor than the runtime), with the error naming both versions; rebuild the plugin against the environment's SDK version or upgrade the platform first.
The table does not break each plugin down into the individual connection types and components it contributes. To see those, open the adapter wizard for the connection types and the Pipeline Designer for the pipeline components.
Treat this list as the authoritative answer to "what can I configure on this platform?" If a capability is not backed by an installed plugin, it is not available to the adapter wizard or the Pipeline Designer.
What ships with the platform
Every Conncentric installation ships with the Essentials plugin enabled: a common set of pipeline components, a load generator, and performance telemetry components. The officially supported connectivity plugins (FIX, Kafka) are available from the catalog and enabled per deployment, so which of them appear depends on how the environment was installed. See Official Plugins for the detail on each connectivity plugin and its capabilities.
The installation also includes pre-built adapters and sample artifacts so you can verify the environment end-to-end without building a configuration first. See What's Included for the full list.
Additional plugins may be installed depending on your platform configuration. Protocols or processing logic beyond the official catalog are developed as custom plugins using the Plugin SDK and installed by your administrator.
Adding a plugin that is not installed
Adding a plugin means getting its package onto the environment. The package comes from one of two places: the official catalog, for supported connectivity and pipeline plugins, or a custom build from the Plugin SDK. Once you have the package you can upload it on the Plugin Management page, though in most deployments plugin changes are coordinated with the administrator who owns the environment.
| You want | Do this |
|---|---|
| A protocol or component from the official catalog | Obtain the package from the Official Plugins catalog, then upload it on the Plugin Management page or ask your administrator to install it. |
| A protocol or component not in the catalog | Coordinate with your development team to build a custom plugin via the Plugin SDK, then install the resulting package. |
| To confirm what is installed right now | Open Plugin Management in the Portal. The list is the authoritative record. |
See also
- Official Plugins: the catalog of supported connectivity and pipeline plugins.
- Plugin SDK: building a custom plugin when the catalog does not cover your needs.
- Creating an Adapter: where connection types contributed by plugins appear in the workflow.