Skip to main content

Rule Engine

What is Rule Engine ?​

Rule Engine is a component that listens to various events and evaluates rules to determine if the given actions can be executed based on various conditions. It provides a flexible and configurable way to automate actions based on Triggers (or incoming events) such as Platform Events (device connection & device disconnection) and incoming HTTP requests.

Keywords and Architecture of Rule Engine​

The Rule Engine consists of the following components:

  1. Rules: Rules define conditions and criteria for triggering actions based on the events. Each rule consists of:

  2. Input Parameters: Inputs provided to the rule when it is executed.

  3. Feched Contexts: Additional Data fetched which can be used in the rule execution.

    Types of fetched contexts:

    1. Device Shadows: This fetched context expects a Shadow Definition and a Device ID which allows you to access the values of the properties in that shadow. As soon as the shadow definition is selected, you can see the structure of the shadow in the right sidebar (Available Data Sidebar).

    2. Device Data Points

  4. Actions: Defines the action to be executed when the rule is triggered.

  5. Trigger Types: This represents the source of events that triggers the rules engine. The trigger types include:

    • MQTT: Represents a Platform Event

      • Device Connection
      • Device Disconnection

    • HTTP: Represents an incoming HTTP request.

    info

    Rules created with this trigger type can be executed by making an HTTP request to the following endpoint:

    • /core/api/v1/<project-id>/wke/<rule-name> for platform users

    • /consumers/api/v1/<project-id>/wke/<rule-name> for platform users

      More Info at: coming soon!

  6. Query Builder: more info coming soon!

  7. Variables: Any value can either be a constant value or a Variable, expressed by enclosing the variable name in two curly braces. For e.g.: {{variable-name}}

Overview of Rule Engine​

Examples:​

Check out this Rule which selects the number of rides of a user, evaluates a condition, and returns the responses based on the result:

Example Rule

Explanation​

  1. Inputs:

    • user_id: The user ID is provided when the rule is triggered. (using an HTTP request)

  2. Fetched Contexts:

    • rides: This

To use the Rules Engine, follow these steps:

  1. Define the event sources you want to monitor (e.g., PGNotification, CronJobTrigger, or HTTP incoming request).
  2. Create rules that define the conditions and criteria for executing actions based on the events. Each rule should specify the evaluation logic and the associated action to be executed.
  3. Configure the Rules Engine to listen to the specified event sources and associate the rules with each event source.
  4. Start the Rules Engine, which will begin listening for incoming events.
  5. As events are triggered from the specified sources, the Rules Engine will evaluate the rules and execute the corresponding actions.
  6. Monitor the execution of rules and actions to ensure they are performing as expected.
  7. Modify and update rules or add new rules as needed to accommodate changes in requirements or desired outcomes.

By following these steps, you can leverage the Rules Engine to automate actions based on incoming events and efficiently manage event-driven workflows.

Sample Request to Rule Engine​

Let's take an example of a device posting data on shadow r, we will define a rule, which will post to a server once the value of r exceeds 90.

Request Payload​

{
  "rule_name": "laugh3",
  "rule_description": "do sneeze on laugh2",
  "rule_type": "UserDefined",
  "trigger_type": "PGNotification",
  "rule_definition": {
    "filter": "data.r >= 90",
    "data_output_map": {
      "data.Temp": "output"
    }
  },
  "dispatch_type": "HTTP",
  "dispatch_definition": {
    "method": "POST",
    "url": "http://localhost:3000/",
    "query_params": [
      {
        "key": "output",
        "value": "gg"
      }
    ],
    "headers": [
      {
        "key": "wp",
        "value": "nice"
      }
    ],
    "data": {
      "my_custom_data": "{data.r}"
    }
  },
  "device_id": "863b63d3-6c97-4086-806d-4d90e76669d1",
  "fleet_id": "08657676-4348-44cd-a677-d25584f91335",
  "project_id": "d309de7d-f45e-4364-b873-ee14457498fc",
  "org_id": "702ede56-391e-495c-976b-0a680514a874",
  "enabled": true
}

Flow​

  1. The device continuously posts data to the shadow, including the value of r.
  2. The Rules Engine Event Listener is configured to listen to updates on the shadow.
  3. The Rules Engine receives the update event containing the new value of r.
  4. The Rules Engine evaluates the defined rule associated with the event.
  5. The rule specifies the condition that the value of r must exceed 90 for the action to be triggered.
  6. The Rules Engine compares the current value of r with the threshold value of 90.
  7. If the value of r exceeds 90, the rule evaluates as true.
  8. The Rules Engine triggers the associated action.
  9. The action initiates a POST request to the specified server, sending the relevant data or payload.
  10. The server receives the POST request and performs the necessary processing or stores the data.
  11. The Rules Engine continues to listen for future updates on the shadow.
  12. If the value of r no longer exceeds 90, the rule evaluates as false, and no action is triggered.
  13. The process repeats for subsequent updates on the shadow, allowing for continuous monitoring and execution of the rule.

Result​

We can see that the server recieved the following packet from RuleEngine

result