Setting Up an Event Rule in R-COM Gateway
An Event Rule in R-COM Gateway acts as the bridge between a data ingestion channel (such as an Endpoint, MQTT, or Scheduler) and a workflow. It listens for matching event data and starts the selected workflow when the configured conditions are met.
Prerequisites
Before creating an Event Rule, make sure the following are ready:
-
✅ One or more Data Ingestion Channels are configured and active (e.g., an
Endpoint,MQTTtopic, or scheduled trigger). -
✅ One or more Workflows have been created to handle the incoming event data.
Need help with setup? Refer to:
Create a New Event Rule
From the R-COM Gateway Dashboard:
- Automation > Event Rules
This page lists all existing Event Rules. The table shows Rule Name, Source Name, Trigger Type, Version, Target Workflow, Event Source, Access Group, Status, and Actions. Use the row actions to:
- View event rule details.
- Edit event rule settings.
- Duplicate event rule when creating a rule based on an existing configuration.
- Compile event rule parameters.
- Delete an entry.
Use the saved views and New view to save a useful set of list filters.
To create one, select Create Event Rule.
Bulk Update Workflow Versions
Use Edit workflow version to move several Event Rules to a different version of the same target workflow. This is useful when a new workflow version has been validated and the related Event Rules must begin using it together.
- Select the Event Rules in the list. Select only rules that use the same Target workflow.
- Select Edit workflow version. The button shows the number of selected rules.
- Review the selected rules and the displayed Target workflow.
- Select the required Workflow Version.
- Select Update.
The update changes the workflow version for every selected Event Rule. It does not change the target workflow, event source, trigger type, variable mappings, or other rule settings.
Configure Event Rules Fields
Configure Event Rules
| Field | Description |
|---|---|
| Rule name | Display name for the Event Rule in the Gateway UI. |
| Access Group | Access Group that scopes visibility and access. |
| Description | Optional explanation of the rule's purpose. |
| Auto Retry | Controls whether the scheduler retries failed events. When disabled, failed events are not retried by the scheduler. |
| Retry attempts for unprocessed events | Number of scheduler retry attempts for a failed event when Auto Retry is enabled. |
| Rule enabled | Activates or deactivates the rule. |
| Event Source | Type of data ingestion channel: MQTT, Endpoint, Scheduler, or Agent. |
| Source Name | The endpoint name (Endpoint), topic name (MQTT), or schedule ID (Scheduler). |
| Trigger Type | The type of event to route, such as UHF Tag Read, Object Change, or Custom Trigger. |
| Target workflow | The workflow to trigger when the event is received. |
| Workflow Version | Specific version of the workflow to execute |
| Additional routing conditions | Optional conditions that further restrict when the rule routes an event. |
Complete Rule details, then select the Event Source, Source Name, and Trigger Type in Event trigger. When the Event trigger section shows Valid, configure the workflow in Workflow to run by selecting the Target workflow and Workflow Version.
The value required for Source Name when Event Source is Agent requires product confirmation.
Event Processor Checker
Use the View Routing Summary checker to validate an Event Rule before relying on it to route events. The checker reviews the configured Event Source and Source Name, then previews the active workflow mappings that may create jobs when a matching event is received.
Open the Event Rule and select View Routing Summary in the page header. Review the result before saving a new rule or changing an existing rule.
| Checker area | What it shows |
|---|---|
| Source | Whether the configured source was found and the number of active workflow mappings associated with it. |
| Preview result | The workflow and workflow version that the current Event Rule would route to. |
| Workflows Triggered | The Event Rules that can create jobs for the source. Expand a rule to review its event type, source, target workflow, workflow version, and active status. |
| Variable Mappings | The workflow parameters supplied by the Event Rule. Select View Variable Mappings to load the variable name, type, binding, and configured value. |
Use the checker when a rule has been copied, its Event Source or Source Name has changed, or its workflow mapping has been updated. If the source is not found or the preview shows an unexpected workflow or version, correct the Event Rule configuration before updating it.
View Routing Summary showing source validation, the routing preview, the triggered workflow, and the control for loading variable mappings.
Available Trigger Types
The Trigger Type list uses display names. Select the display name in the form; the Trigger Configuration header can continue to use the internal name, such as UHFTagRead.
- Agent Status Update
- All Data
- Barcode Read
- Custom Trigger
- Custom UI
- Epcis Aggregation Event, Epcis Association Event, Epcis Message, Epcis Object Event, Epcis Transaction Event, and Epcis Transformation Event
- Ghost Data
- Object Change
- On Timer
- UHF Tag Read
The product behavior and configuration requirements for Agent Status Update, Barcode Read, and Custom UI require subject-matter confirmation. This documentation does not prescribe a payload or routing configuration for those trigger types.
Variable mapping
The Event Rule serves as the link between your Data Ingestion Channel (Endpoint, MQTT, Scheduler, or Agent) and a Workflow.
Variable Mapping lets you map incoming event data (or static values) directly into the input parameters your workflow expects.
This ensures that each run of the workflow receives exactly the data it needs.
To map variable:
-
Click on Variable Mapping.
This tab appears only after a workflow is selected. -
The Parameter column lists every input parameter you defined in the workflow.
- If no parameters appear, return to your workflow editor and add them under Parameters.
-
Under Static/Dynamic, choose the type of data.
-
Dynamic:
- Select Dynamic in the Type column.
- In the Value field, pick from the dropdown of all parsed fields received from your ingestion channel
(JSON data, MQTT topic fields, etc.).
-
Static:
- Select Static in the Type column.
- Enter a literal string in the Value field.
-
Variable mapping for selected workflow
- Once every parameter has a mapping, click Save.
- Your Event Rule will now inject those values each time it fires the workflow.
Save and Activate
Once all fields are configured:
- Click Save
- If Rule enabled is active, the Event Rule will immediately begin monitoring the specified ingestion channel.
- When matching data arrives, the linked workflow will be triggered automatically
Example Use Case
Scenario: You want to track when tagged pallets enter a cold storage zone.
Configuration:
- Event Source:
MQTT - Source Name:
entry - Trigger Type: UHF Tag Read
- Target workflow:
ColdZoneEntryAlert - Workflow Version:
v3 - Access Group:
WarehouseOps
Result:
When a tagged pallet passes the reader, a message is published to the MQTT topic entry. The Event Rule picks it up and triggers the ColdZoneEntryAlert workflow automatically.