Exchanging data between multiple 1Gateway instances
Exchanging data between multiple 1Gateway instances is a common architectural pattern for high availability, geographic distribution, or cross-domain security. Based on the official 1Gateway technical documentation, here are the factual methods to achieve this.
1. Shared Infrastructure: Common RabbitMQ
The most direct "backend" method involves configuring multiple 1Gateway instances to connect to the same RabbitMQ cluster.
In the application properties or environment variables, both instances are pointed to the same SPRING_RABBITMQ_HOST.
The result is both instances will listen to the same exchange/queues.
While this is often used for High Availability (HA) or Load Balancing, it can be used for data exchange if different virtual hosts or specific routing keys are used to steer messages between instances.
2. Push mechanism: REST Mapping to Webhook
This is the most common "loose-coupling" method. It treats the second 1Gateway instance like any other external endpoint.
- Instance A (Sender): Uses a REST Mapping within a Message Mapper. The mapper is configured to perform a
POSTorPUTrequest to the URL of Instance B. The URL to connect to instance B depends on the name of the Webhook plugin. - Instance B (Receiver): Configures an Internal Webhook Plugin (Listener). This plugin will get the incoming JSON from Instance A.
3. Pull mechanism: Outgoing Queue & Polling
This method provides a "store-and-forward" capability, useful when Instance B must control when it receives data, or when Instance A cannot directly "see" Instance B.
- Instance A (Producer): Uses the Queue Outgoing Plugin. Messages are routed to this plugin, which pushes them into a specific RabbitMQ queue.
- Instance B (Consumer): Uses a Timer Plugin that generates a "trigger" message at a defined interval. Include the URL from Instance A in the generated message. A Message Mapper receives the trigger and uses a REST Mapping to execute an HTTP GET request to fetch the pending messages
4. Scripted Logic: Groovy Plugin
For complex data exchange logic that requires conditional routing or pre-processing before sending, the Groovy Plugin can be used. To get started with Groovy go here.
5. File-Based Exchange
Though less real-time, 1Gateway supports file-based plugins which can act as a bridge.
- Mechanism: Instance A uses a File Sender to write messages to a shared network drive (NFS/SMB). Instance B uses a File Listener to monitor that directory.
- Use Case: Highly secured environments where direct network connectivity between instances is prohibited, but a shared "drop zone" is allowed.
Comparison of Options
| Method | Latency | Complexity | Best For |
|---|---|---|---|
| Shared RabbitMQ | Near Zero | Low | HA & Scalability |
| REST/Webhook | Low | Low | Real-time cross-server sync |
| Outgoing Queue | Medium | Medium | Reliable delivery / Buffering |
| Groovy Plugin | Variable | High | Complex logic / Transformations |
| File Exchange | High | Low | Air-gapped or restricted networks |