Custom Protocol Integration
Use this pattern when your firm needs to connect to a system whose protocol or message format the platform does not ship as a built-in component. Proprietary binary feeds, internal APIs, legacy message queues, and custom TCP protocols all fall into this category. Developers build a focused piece of protocol logic using the Plugin SDK, and the platform handles everything around it.
The custom plugin participates in the pipeline on equal footing with the built-in components. It inherits the platform's lifecycle management, failover behavior, metrics, and logging without additional work.
Building a custom protocol is a developer build-and-redeploy cycle, not a Portal configuration change: you compile the plugin into a JAR with the Plugin SDK and redeploy it before it becomes available to configure.
Conceptual flow
A custom plugin can be:
| Plugin role | Responsibility |
|---|---|
| Connector | Owns the I/O with the external system: establishing connections, reading bytes, handing messages into the pipeline, or writing messages out. |
| Transformer | Converts an in-pipeline message from one shape to another (for example, decoding a proprietary binary format into a structured payload). |
| Processor | Applies side effects such as publishing to a destination, making a side-channel call, or emitting a derived event. |
| Condition | Evaluates a message and returns true or false to control route selection. |
What you build versus what the platform provides
| You build | The platform provides |
|---|---|
| The protocol logic itself (framing, decoding, session handling specific to the external system) | Plugin loading and versioning |
| A manifest describing the plugin's configuration surface | Configuration form generation in the Portal, driven by the manifest |
| Unit tests for the plugin's behavior | Lifecycle management (start, stop, failover) |
| Optional custom types used by the plugin's configuration | Metrics collection and log aggregation |
When to use
| Scenario | Pattern |
|---|---|
| The external system speaks a protocol that no built-in plugin supports. | Build a custom Connector. |
| The external system speaks a supported protocol but uses a proprietary message shape. | Build a custom Transformer and reuse the existing Connector. |
| A business rule needs to inspect message contents before routing, beyond the built-in conditions. | Build a custom Condition. |
See also
- Plugin SDK Getting Started for building custom plugins.
- Manifest Schema for the configuration contract between a plugin and the Portal.