Klover Triggers - Part 1: An Introduction

August 1, 2017

This is the first in a multi-part series where I will introduce Klover Triggers, Expressions and Actions. Future articles will include examples to foster deeper understanding of how to work with them to create extensible, smart solutions using Klover.

Concepts in the article include:

- Types of Triggers  (Event and Scheduled)
- Expressions           (Single and Group)
- Actions                   (Making something happen when a Trigger fires!)

Triggers

Triggers provide extensibility within the Klover Platform by allowing non-technical, business users to define business rules that execute on events published in Klover (Figure 1). Events can be predefined by Klover applications or they can be user-defined events with their own data structures. Entity Event Triggers handle all events for a particular type of entity such as all Incidents or all Users. In contrast, Instance Event Triggers handle events for a specific instance of an entity. Let me provide a few examples to show you what I mean.

Klover Triggers UI

Figure 1: Klover Triggers UI


The difference the between the Event Trigger types is shown in the following examples. Here is an example of an Entity Event Trigger on Things:

When any radar reports an average speed is below 30 miles per hour, inform the public that a slowdown has occurred.

In contrast, an Instance Event Trigger is defined to fire only for a specific instance of a radar. Let's say we a dynamic message sign (DMS) that is installed 1/2 mile upstream from a side-fire-radar on a high-volume roadway.  When that exact radar is reporting low speeds, you want to inform drivers to slow down.  This is easily done in Klover with Triggers.  You just configure the Trigger to point to the exact radar, and then have Klover automatically set a message onto the DMS when the condition is met.  Here is an example of an Instance Event Trigger.  Notice how it is different from the Entity Event Trigger.

When radar(ID=100) reports the average speed is below 30 miles per hour, post the message “Heavy Congestion Ahead, Slower Speeds Advised” on DMS(ID=5).

Expressions and Actions

Trigger Expressions are easily configured in Klover using the Trigger Expression Designer.  With the designer, you can navigate data fields in your events and apply conditions to them using an intuitive graphical user interface.  There is no programming involved!
 

Expression sample



Expressions are conditional statements that evaluate whether a Trigger should fire an Action or not. In the Trigger above, the Expression is: “When radar(ID=100) reports the average speed is below 30 miles per hour”.  Expressions can be single or grouped using logical AND/OR operands to bring multiple conditions that form complex expressions. 

Actions fire when an Expression evaluates to true. In the Trigger above, this part is the Action: “post the message “Heavy Congestion Ahead, Slower Speeds Advised” on DMS(ID=5)”.

A Trigger can fire multiple Actions if there are numerous things you want to have happen because of the event.  You should define Actions that are easy to understand, reusable across other triggers, and managed independently.  Actions can be bound, for instance, to pre-defined process flows so the same process flow can be reused from multiple Triggers.

Scheduled Triggers

Scheduled Triggers process events that are raised on a timed-basis. Typically, Scheduled Triggers have a start date, an optional end date, and they are repeating. However, they can be scheduled to run one time only as well. Using an intuitive UI, you can schedule a job to run and include parameters to be passed with the event when it is fired. For instance, you could create a Scheduled Trigger that runs once every two minutes. When it runs, an Action publishes the latest road & weather conditions to Twitter.

Klover empowers users to create their own Scheduled Triggers and fire any Action they require as per their business use case.

How do other platforms extend their business logic?

Other platforms provide ways to extend base features of their applications as well. Let’s take a look at two approaches to adding/editing business logic and then review how others accomplish extending their platforms:

Development & Release Cycle
Cloud-native/Real-time

Many platforms require development and release cycles to get a basic rule changed or to perform different business logic. While this encourages quality control, it hinders agility and ultimately your ability to adapt to changing requirements quickly. IBM’s Streams, for example, relies on a client-installed development environment (Eclipse) to create, test, and deploy applications to your cloud.  A team of business analysts, developers, testers, and operations people work to deploy this new functionality each time a business requirement changes. Doesn't that sound costly and time-consuming?

Klover takes a much more Cloud-native approach towards changing business requirements.  It empowers business users to create business rules and extensions to the platform in real-time.  To do this, we provide Web-based, intuitive user-interfaces and graphical modeling tools that enable immediate validation and deployment of your changes.  While doing so, your Expressions reference your real-time data, not dummy data in some test environment. This provides a seamless process where business users decide the rules for an event and configure Triggers to handle the rules without requiring hand-offs between business, development and testing teams.

Some platforms allow you to define code or serverless scripts that fire when triggered. AWS IoT and theThings.io come to mind. While scripting is definitely a more Cloud-native approach than IBM’s IDE methodology, these platforms fall short of Klover by requiring programming experience whereas Klover’s business-friendly UIs empower your business users. Similar to these platforms, Klover users can use JavaScript to handle very complex scenarios, so you can deploy custom logic, if you have the development staff on hand.  However, we recommend using our intuitive Trigger Expression Designer for most cases. At least, with Klover you get best of both worlds, a business-friendly interface or the power of JavaScript if you need it.

Conclusion

I hope you gained a background on Klover Triggers, Expressions, and Actions today. While Klover allows power users to employ scripting languages like JavaScript for Expressions and Actions, what ultimately makes it stand out from the competition is how it empowers non-technical users to create rich business logic by configuring rather than coding Triggers, Expressions and Actions. Klover's Cloud-native, real-time approach provides an immediate business impact as opposed to waiting on developers, testers, and a full development lifecycle to deploy new functionality.

Upcoming articles in this series on Triggers will cover Scheduled Triggers and Event Triggers in more depth by using more real-world examples. We will present a Smart Parking 'Surge Pricing' solution using Scheduled Triggers and a Trouble Ticketing solution using Event Triggers.  See you soon.

Interested in Klover?

We'd love to show you how Klover can be an integral part of your smart transportation solutions. Request a demo or call us at 720-770-8009

Subscribe for updates