Skip to main content

Building Event-Based Workflows in RCOM Gateway

Event-based workflows are the foundation of automation in the RCOM Gateway. Whenever a device sends data, such as a tag read, barcode scan, sensor update, or room entry, the Gateway converts that incoming event into an automated processing sequence. Workflows allow you to interpret these signals, apply your business logic, update internal records, and forward information to external systems.

This article explains how event-driven automation works inside the Gateway and guides you through creating an event-based workflow from end to end.

What Is an Event-Based Workflow?

An event-based workflow is a set of automated actions that run immediately when new data arrives from the physical world.

Examples:

  • A pallet enters a storage zone → validate authorization
  • A product is scanned → update stock movement
  • A patient leaves a room → update location in the hospital system
  • A temperature sensor reports high values → trigger alert

The Gateway’s strength lies in its ability to take device-generated data and react in real time using workflows you design.

Key Components

Before creating your first workflow, you must understand the four core building blocks of the event system:

Event

A piece of incoming data triggered by a real-world action. Events can arrive through REST APIs, MQTT topics, EPCIS uploads, or internal triggers.

Example event payload:

{
"PalletID": "PLT123",
"ReaderID": "Dock-4",
"Timestamp": "2025-05-15T10:23:00Z"
}

Object Groups

Objects represent digital records- your system’s digital twins. They allow workflows to store, update, and query information.

Examples of objects:

  • Products
  • Pallets
  • Patients
  • Equipment
  • Rooms
  • Vehicles

Objects help maintain state between events.

Workflow

A visual automation sequence that processes incoming events.
Workflows can:

  • extract data
  • check conditions
  • update objects
  • send alerts
  • call external systems
  • publish MQTT messages
  • generate files

Workflows are the logic engine of the Gateway.

Event Processor

A routing component that:

  • Listens to one or more ingestion channels
  • Filters incoming events
  • Determines which workflow to trigger
  • Maps event data into workflow parameters

It is the bridge between raw event data and workflow execution.

How a General Event Flows Through the Gateway

Every event follows the same processing path:

Step 1 — Event Arrives: Via REST API, MQTT topic, EPCIS, or scheduled trigger.

Step 2 — Event Processor Matches the Event: It filters, extracts fields, and chooses the appropriate workflow.

Step 3 — Workflow Executes: Logic runs step-by-step, making decisions and performing actions.

Step 4 — Objects Are Updated (Optional): Digital twins reflect the latest state.

Step 5 — External Systems Receive Output (Optional): REST calls, MQTT messages, file creation, notifications, etc.

This unified flow ensures consistent behavior across all data sources.

Creating an Event-Based Workflow (Step-by-Step)

Step 1: Identify the Event

Clearly describe the real-world trigger you want to automate.

Ask yourself:

  • What action generates the event?
    Example: “An item is scanned at Packing Station A.”
  • What data will the event contain?
    Examples:
    • Product ID, timestamp, scanner location
    • Patient ID, previous location, current location
    • Pallet ID, reader position, temperature
  • What format will the data arrive in?
    JSON, XML, EPSIC, plain text, etc.

Example (Warehouse):
A handheld scanner sends JSON with BatchID, SKU, quantity, timestamp, and initial temperature.

Example (Healthcare):
A nurse call system sends a payload containing PatientID, room number, alert type, and timestamp.

Step 2: Define Object Structure

If your workflow needs to store, retrieve, or manipulate data persistently (i.e., in a database), you'll need to define an Object Structure. An Object in the RCOM Gateway represents a database entry that holds the event data or related information.

Think of Objects as digital twins or records:

For a product, an Object could store its ID, description, current location, quantity, and last-seen timestamp.

In a hospital, an Object might represent:

  • A patient (with their ID, current room, assigned doctor, and medical alerts), or
  • A piece of medical equipment (with its ID, status, location, and maintenance schedule).

Example:

{
"object_type": "product",
"product_id": "PRD001",
"location": "Aisle-3",
"scanned_at": "2025-05-15T10:23:00Z"
}

Step 3: Create a Workflow

This is where you define the automated logic executed when the event arrives.

Plan the flow

  • What should happen first?
  • Do you need to extract fields from the input?
  • Do you need to look up an Object?
  • Should you perform conditional checks?
  • Should the workflow notify systems or users?

Configure actions

Common actions include:

  • Extracting values from JSON
  • Calling external APIs
  • Updating or creating objects
  • Performing conditional logic
  • Sending notifications
  • Publishing data to MQTT

You configure these by dragging actions into the workflow editor and connecting them in sequence.

Step 4: Configure a Data Ingestion Channel

Choose how the event will enter the Gateway:

REST API Endpoint:

  • For HTTP-based data submissions.
  • Best for integration with enterprise systems or middleware
  • Ideal for synchronous request/response use cases

MQTT:

  • Best for IoT and Auto-ID devices
  • Optimized for high-frequency events

Creating the ingestion channel assigns the Gateway a “listening point” for incoming events.

Step 5: Set Up an Event Processor

The Event Processor is the crucial link that ties your Data Ingestion Channel to your Workflow.

It:

  • Listens to the selected REST/MQTT route
  • Extracts and filters incoming event data
  • Determines which workflow to trigger
  • Maps event fields to workflow input parameters

Once active, the Event Processor ensures your workflow automatically runs whenever the event occurs.


Example: Tracking Pallet Movement Into a Restricted Zone

Define the Event

An RFID reader at the cold-storage entrance sends a JSON payload whenever a pallet approaches:

{
"PalletID": "PLT-90821",
"ReaderID": "ColdStorage-Gate-2",
"ProductType": "Pharma",
"CurrentTemperature": 6.3,
"Timestamp": "2025-05-15T10:23:00Z"
}

This event tells the Gateway: A pallet is attempting to enter a controlled zone.

Define the Object Structure

Create a Pallet Object Group with attributes used for validation:

  • PalletID
  • ProductType
  • RequiredTemperatureRange (e.g., 2–8°C)
  • IsAuthorizedForColdStorage (Boolean)
  • LastKnownZone
  • LastTemperatureReading

This object stores compliance rules and the pallet’s last known state.

Create Workflow Logic

When the event arrives, the workflow:

Step 1 — Extract event data

  • (PalletID, ProductType, CurrentTemperature, ReaderID)

Step 2 — Look up pallet object

  • Retrieve stored authorization and temperature requirements.

Step 3 — Validate the attempt

  • If temperature is outside the allowed range → block entry, alert Quality Control, log incident.
  • If pallet is not authorized → block entry, alert security, log attempt.
  • If all checks pass → allow entry, update LastKnownZone and LastTemperatureReading.

Step 4 — Notify systems

  • Send updates to WMS, dashboards, or operators.

This workflow ensures safety and compliance without manual checks.

Set Up Data Ingestion

Configure the RFID reader to publish events to an MQTT topic:
gateway/coldstorage/gate2/entry

The Gateway will listen on this topic for incoming pallet events.

Configure the Event Processor

The Event Processor:

  • Subscribes to the MQTT topic
  • Reads and validates incoming messages
  • Maps event fields to the workflow inputs
  • Triggers the “Cold Storage Entry Validation” workflow

As soon as the reader publishes data, the workflow executes.

Result

Each time a pallet approaches the cold-storage entrance:

If authorized AND temperature is safe

  • Entry is allowed
  • Object updated
  • WMS and dashboards notified

If unauthorized or temperature unsafe

  • Entry blocked
  • Alerts sent immediately
  • Event logged for compliance