Official Plugins
Conncentric's engine is protocol-agnostic. The platform itself handles pipeline execution, lease-based failover, monitoring, and the Portal UI. Every protocol detail (how to speak FIX, how to consume from Kafka, how to map fields) is delivered through plugins.
A plugin is the bridge between the platform engine and an external protocol. Install a plugin and the Portal gains new connector types, new pipeline components, and any protocol-specific dashboards the plugin ships. Remove a plugin and those capabilities disappear. The engine itself does not change either way.
Officially supported plugins cover the most common financial-market connectivity patterns. For anything the official catalog does not include, the Plugin SDK exposes the same extension points the official plugins use.
Operator workflow versus developer workflow
| Question | Where to work | How |
|---|---|---|
| Which connection types, pipeline components, and protocol fields are already available in the Portal today? | Official Plugins (this section). | Portal configuration forms and JSON adapter definitions. No Java code. |
| I need a protocol, processor, or transformer the official plugins do not provide. | Plugin SDK. | Java interfaces (Connector, Processor, Transformer) plus a component manifest schema. Build, test, and package a JAR with the SDK builder image. |
Official plugins ship pre-compiled with the platform. Essentials is enabled by default; FIX and Kafka are each enabled per deployment through their installer flag. Custom plugins produced by the SDK ship as JARs alongside them. Both load through the same plugin loader and appear together in the Portal; a reader of the Pipeline Designer cannot tell which components came from the official catalog and which came from a custom plugin.
Plugin types
A plugin can extend the control plane, the data plane, or both.
| Type | Runs on | What it provides |
|---|---|---|
| Orchestrator plugin | Orchestrator (control plane) | Configuration schemas and Portal fields for the protocol, artifact validation (for example, verifying a FIX data dictionary is valid XML), scheduled maintenance tasks (for example, partition management), and control-plane API extensions (for example, session-state views). |
| Integration-adapter plugin | Adapter pods (data plane) | Connectors (the runtime that maintains live sessions), transformers, processors, and any protocol-specific backpressure or monitoring logic. |
Not every plugin ships both types. The table below shows which types each official plugin provides.
What ships
| Plugin | Orchestrator | Integration-adapter | Purpose |
|---|---|---|---|
| FIX | Yes | Yes | FIX protocol session management, message logging, partition management. |
| Kafka | No | Yes | Consumer and producer connectivity to Apache Kafka, Redpanda, and Confluent Platform. |
| Essentials | No | Yes | Common pipeline components, synthetic traffic generation, and debug utilities. |
Essentials is enabled by default. FIX and Kafka are off by default and each enabled per deployment through its installer flag.
Common integration patterns
FIX and Kafka are most commonly used together. Typical patterns:
| Pattern | Description |
|---|---|
| Venue to internal | Receive messages from a FIX venue, deliver to a Kafka topic. |
| Internal to venue | Read from a Kafka topic, send to a FIX venue. |
| Inbound acceptor | Accept FIX connections from counterparties, route to Kafka. |
| Protocol bridge | Connect two systems with Kafka as an intermediary. |
| Fan-out | Receive a single feed and route to multiple destinations by message type. |
See the global Use Cases section for end-to-end setup of these patterns.
Custom protocols
A protocol not covered by the official catalog is added with the Plugin SDK. A custom plugin can provide an orchestrator plugin, an integration-adapter plugin, or both, depending on what the protocol requires. Custom plugins integrate with the same pipeline engine, Portal UI, and manifest schema as the official plugins.
See the Plugin SDK for the interfaces and the build, test, and deploy workflow.