Plugin
Groovy plugins allow you to extend 1Gateway with custom script-based logic using Groovy scripts. They are typically used when standard plugins and mappers are not sufficient, for example when using a SOAP API, applying complex logic, or implementing non-standard integrations.
Groovy plugins can be configured either as:
- Groovy Pollers, which run on a schedule and generate messages
- Groovy Senders, which process and deliver messages to external systems
Both Groovy pollers and Groovy senders contain a Groovy script to be executed by the plugin.
Groovy Poller
Purpose
A Groovy poller executes a Groovy script at a configured interval, it does not receive messages from the 1Gateway system. Groovy pollers act as entry points into the message flow. They are typically used to:
- Poll external systems (APIs, databases, FTP servers)
- Monitor external data sources
- Generate messages on a schedule
- Inject data into the message flow
Behavior
- The script runs according to the configured schedule.
- The script is responsible for creating and publishing messages using the API object
- Each execution is independent.
Groovy Poller Configuration
Additional configuration fields specific to Groovy pollers include
| Field | Description |
|---|---|
| Run interval in seconds | Defines how often the script runs |
| Name of the next component (hop) in the workflow | Defines where to send the messages to. If defined, no queue is created and messages are sent to the next component directly |
The poller script must explicitly publish messages using the API object
Groovy Sender
Purpose
A Groovy sender processes messages that are routed to it and performs custom outbound logic. Groovy senders act as custom delivery endpoints. They are typically used to:
- Send messages to custom or unsupported endpoints
- Apply destination-specific formatting where JSON is not sufficient (XML, form data, etc.)
- Perform custom authentication or protocol handling
- Implement complex outbound logic
Behavior
- The sender receives messages after routing and transformation.
- The script decides how the message is handled (for example: send via HTTP, write to file, call an API).
- Errors can be handled using standard sender retry and error handling mechanisms.
Groovy senders support filters, configured using Groovy expressions. Filters control whether a message should be processed by the sender. For more information on Groovy filters, see: Groovy Filters
Groovy Sender Configuration
Additional configuration fields specific to Senders can be found here:
Groovy SDK Object Availability
Groovy scripts in 1Gateway run within a controlled execution context and have access to a predefined set of objects provided by the Groovy SDK.
Not all objects are available in every context. The table below describes each object, its purpose, and where it can be used.
Available Groovy SDK Objects
| Object name | Purpose | Available in |
|---|---|---|
| message | Represents the message currently being processed, including payload, headers, and metadata | Mapper, Groovy sender |
| parser | Utility for converting between JSON, maps, lists, and strings | All |
| api | Provides access to the 1Gateway API, including message publishing and platform interactions | All |
| option | Helper to safely access optional bindings and configuration values. Options used include http, rest, ftp, idmap, sql, etc | All |
| memory | Global in-memory datastore shared across executions | All |
| db | Global database-backed datastore for persistent storage | All |
| mappingContext | Provides mapping-related metadata and context information | Mapper |
| log | Logger for writing to the logfile | All |
| substitution | Helper to resolve endpoint variables and substitutions | All |
Notes on Object Usage
- Pollers do not have access to messages, as they do not receive messages. Poller scripts are responsible for creating and publishing messages explicitly using the api object.
- Mappers and sender plugins receive a message object, which represents the message being transformed or sent.
- All contexts have access to shared utilities such as logging, parsing, API access, and datastores.
- Objects like memory and db can be used to maintain state across executions or messages.
For detailed documentation of each object, see the Groovy SDK reference: Groovy SDK Reference
How This Fits Into Plugin Behavior
Groovy Pollers typically rely on:
- api: to publish messages
- substitution: to resolve endpoint configuratio
- parser: to parse data content
- memory or db: to track state such as last poll time
- log
Groovy Senders commonly use:
- message: to read payload and metadata
- substitution: to resolve endpoint configuration
- api: optional, for advanced routing or publishing
- log