Events in R-COM Gateway
Events are the fundamental execution units in R-COM Gateway. Every interaction—whether triggered by an external system, device input, scheduled job, or internal workflow—results in the creation of an event. These events act as immutable records of what happened, when it happened, and how the system processed it.
At runtime, the platform is essentially an event-driven engine. Workflows do not operate in isolation; they are always executed in response to events. This makes events central to observability, debugging, auditing, and system reliability.
Event Lifecycle
An event in R-COM Gateway typically follows this lifecycle:
Event Creation
Triggered by:
- Endpoint API calls
- Device inputs (RFID, scanners, BLE, etc.)
- Scheduler jobs
- Internal workflow triggers
Event metadata and payload are captured at this stage.
Workflow Execution
One or more workflows are assigned to process the event.
Execution may include:
- Data transformation
- Conditional logic
- External integrations
- Object operations
Processing Completion
Event is marked with a final status.
Output and execution details are recorded.
Storage & Traceability
Event is persisted for audit, debugging, and analytics.
Event Structure
Each event contains structured metadata that allows full traceability:
| Field | Description |
|---|---|
| Event ID | Unique identifier for the event |
| Event Data | Payload received or generated |
| Created Time | Timestamp when event was created |
| Processed Time | Timestamp when processing completed |
| Event Status | Current state (Finished, Failed, etc.) |
| Type | Event classification (e.g., AllData) |
| Workflow | Workflow executed for this event |
| Event Source | Origin (Endpoint API, Scheduler, Device, etc.) |
| Processed By | Execution instance or node |
Event Status
Event status reflects the current state and outcome of event processing throughout its lifecycle:
- Undefined – Initial state when event is first created but not yet classified.
- Created – Event has been successfully created and registered in the system.
- Validating – Event is currently being validated against system rules and constraints.
- Consumed – Event has been consumed by one or more workflows and is being processed.
- Aborted – Event processing was stopped before completion due to a user-initiated action or system constraint.
- Failed – Event processing encountered an error and did not complete successfully.
- EndpointViolation – Event failed validation at the endpoint level, typically due to invalid data format or missing required fields.
- Finished – Event processing completed successfully.
These statuses are critical for monitoring system health and identifying operational issues.
Events Page
Purpose
The Events Page provides a centralized interface for viewing, analyzing, and troubleshooting all events processed by the system. It acts as the primary operational console for system visibility.
Events Page providing centralized event monitoring and analysis
Key Features of the Events Page
1. Event Listing
The page displays a tabular view of events with key metadata:
- Event ID
- Status
- Type
- Workflow
- Created Time
- Processed Time
- Event Source
- Processed By
- Actions
This allows quick scanning of system activity.
2. Row Actions
The Actions column provides the tools needed to inspect or repeat an event:
| Action | Description |
|---|---|
| Jobs indicator | Available when an event triggered workflow jobs. Select it to open the related jobs; it also shows the number of failed jobs for the event. |
| View raw event data | Opens the event payload for inspection. |
| Duplicate event | Duplicates the event. |
| Rerun event | Submits the event for processing again. |
When no workflow job was triggered, the jobs indicator reports No jobs. For detailed job monitoring and troubleshooting, see Workflow Jobs.
3. Filtering and Saved Views
The Events page initially filters the list to events created today. Use the filter chips, such as Event Status, Event Types, and Created, to narrow the results. Select +1 more when additional active filters are hidden.
Choose Match All to require every selected filter, or Match Any to return events that satisfy at least one filter. Select New view to save the current filters for future use, and select Default to return to the default view.
Available filters include:
- By Event ID
- By Workflow Name
- By Event Status
- By Workflow Triggered
- By Event Type
- By Event Source
- By Created Date Range
- By Event Data (key or value without quotes)
Filtering is essential when dealing with high-volume environments (tens of thousands of events).
4. Pagination & Navigation
- Supports large datasets (e.g., 40k+ events)
- Configurable items per page
- Jump-to-page functionality
This ensures scalability without performance degradation in the UI.
5. Sorting
Events can be sorted by:
- Created Time
- Event Status
- Type
- Workflow Names
- Processed Time
- Event Source
- Processed By
This helps in analyzing recent activity or historical patterns.
6. Download / Export
The page provides export functionality:
- Select Export events to download event data for offline analysis.
- Useful for:
- Audit logs
- Incident investigation
- External reporting
Operational Use Cases
1. Debugging Workflow Failures
- Filter by Failed events
- Inspect event payload and workflow execution
- Identify:
- Incorrect data
- Integration failures
- Logic errors
2. Monitoring System Activity
Track:
- Number of events processed
- Event sources (API vs Scheduler vs Devices)
- Identify unusual spikes or drops
3. Identifying Problematic Workflows
Look for:
- Repeated failures from the same workflow
- High processing times
Helps prioritize fixes and optimizations.
4. Auditing & Traceability
Full history of:
- What was triggered
- When it happened
- What processed it
Critical for enterprise compliance and debugging production issues.
5. Event Source Analysis
Differentiate between:
- API-triggered events (EndpointAPI)
- Scheduled executions (Scheduler)
Helps understand system behavior patterns.
Design Considerations
High Volume Handling
R-COM Gateway is designed to handle:
- Millions of events per day
- Thousands of concurrent sources
The Events Page reflects this with:
- Efficient pagination
- Lazy loading
- Optimized queries
Immutable Event Records
Events are not modified after creation:
- Ensures audit reliability
- Enables consistent debugging
Decoupled Processing
Events are independent:
- Failure of one event does not impact others
- Enables high resilience and scalability
Best Practices
- Regularly monitor failed events instead of ignoring them
- Use filtering aggressively in high-volume systems
- Correlate events with workflow logs for deeper debugging
- Export event data for complex investigations
- Track recurring failures to identify systemic issues