Routing Rule Overview¶
The Routing Rule function provides flexible access and processing methods such as aggregation calculations for both EnOS and non-EnOS standard device data. It enables users to create customized routing rules that can filter and transform incoming messages from IoT devices and related asset data, and trigger various operations such as sending notifications and data communication with external systems.
Some common use cases that can be configured through Routing Rule include the below.
- Verifying/modifying incoming telemetry or attributes before saving to database.
- Copying telemetry data or attributes from device to related assets for data aggregation. For example, aggregating data from multiple devices in related assets.
- Triggering actions based on device lifecycle events. For example, creating an alert when the device is online/offline.
- Triggering REST API calls to external systems.
- Sending emails when an event occurs, and referencing the attributes of other entities in the email template.
- Integrating with external services such as Kafka, Spark, Azure, etc.
Key Concepts¶
Rule¶
A rule is a routing rule that you can design and build using rule nodes to process the incoming messages. Each rule must start with either the Rule Entry node or Scheduler node.
There is a default rule, EnOS_default provided by the system which can only be viewed and cannot be edited or deleted. The default rule can be used by the following ways:
- All incoming device data will use this routing rule by default.
- Customized rules can be routed to the default rule via Checkpoint.
Rule Node¶
A rule node is the basic component and main logical unit of a rule. It processes a single incoming message and generates one or more outgoing messages.
Rule nodes can filter, enrich, transform incoming messages, perform operations, or communicate with external systems. For more information, see Rule Nodes Overview.
Rule Message¶
The rule message is a serializable and immutable data structure that represents various messages in the system. Examples of rule messages include the below.
- Instructions for telemetry, attribute updates, events, or device.
- Device status such as connected, disconnected, activated, etc.
- Other system events such as pre-defined messages.
A rule message contain the following information.
- Message ID: A unique, time-based identifier.
- Message originator: The identifier of a device, asset, or entity.
- Information type: For example, report measurement point, restart event, etc.
- Message payload: A JSON body with the actual message payload.
- Metadata: Additional message data listed in key-value pairs.
Rule Node Relation¶
A rule node relation specifies the relationship between two rule nodes. Each relation has a label that specifies the logical meaning of the relationship used to route the message to the next node. A rule node relation can have multiple labels.
Message Processing Results¶
There are two possible results when a message is processed.
- Success: When the last rule node in the rule successfully processes the message.
- Failure: If one of the rule nodes in rule fails to process the message, and there is no rule node to handle the failure.
Limitations¶
It is recommended that you read the following before you create any rules. The limitations listed here are applicable to each OU.
| Item | Limitations |
|---|---|
| Asset Type | Only supports device assets. Logical assets are not supported. |
| Max number of rules that can be created | 100 |
| Max number of nodes for a single flow | 50 |
| Max period of log storage for nodes | 7 days |
| Max number of running instances for an OU | 10 |
| Max computing resource for a single instance | 8 CU (4 Core CPU + 16 GB Memory) |