Klover Triggers - Part 1: An IntroductionAugust 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 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.
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 ActionsTrigger 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!
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 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
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.
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.