Close
Hyperon as a

Business Rules Management System

Looking for BRMS

for your company?
Try Hyperon!
Get free proof of concept
Try Hyperon for free
Hyperon Studio
Web UI that lets users to manage their business rules
Hyperon Runtime
Engine embeddable as a lightweight jar
Hyperon REST API
Evaluate parameters or functions via HTTP
Time versioning
Create multiple versions of the business logic and schedule them in a timeline
Contact us
Hyperon as a
Business Rules Management System

1. Definitions

To understand how Hyperon can be used as a Business Rules Management System we need to lay out some definitions first.

1.1. What are Business Rules?

As it comes to application development, business rules define how an application should behave in a given context. In other words, they define the logic an application has to follow. Most often business rules are expressed in the form of when-then statements. Examples of such rules are:

when a customer’s cart value exceeds 100$ then apply 5% discount or when some item is chosen then some other item becomes unavailable.

When the system we create gets large and complex, maintaining all the rules becomes a challenge. And this is where dedicated management system comes into play.

1.2. What is a Business Rules Management System?

A Business Rule Management System is a software system designed to define and maintain the business logic often in the form of business rules or decision tables. Instead of embedding this logic in application code, the BRMS enables the logic to be externalized and managed away from the source code. Having business rules externalized and accessible to business experts, the BRMS deliver a boost to business agility and productivity offering cost savings and faster logic changes.

Separate business rules from the hard code
Quickly react to business requirements changes
Manage and maintain configurations in 1 place

1.3. What is a Business Rules Engine?

A business rules engine is a software component (often delivered in the form of a library) that can evaluate proper business rules and produce desired actions or outcomes. It is desirable that such an engine is performant and allows rules modification at runtime.

2. Hyperon as a BRMS

Hyperon is a Business Rules Management System (BRMS) focused on performance. It is designed to easily handle large decision tables. The rules engine uses in-memory structures and carefully designed matching algorithm to search large decision tables (1M rows and more) in few microseconds. At the same time, developers and business experts may modify business logic without touching application’s code. Changes are immediately reflected in any application that uses Hyperon engine.

Hyperon business rules have the following structure:

when a condition is met
then a result value is returned

Business rules are grouped in decision tables called Parameters. Hyperon uses parameters as its most primal structures. Developers can design their applications as configurable on the fly by making application’s code dependent on parameters.

The following is an example of parameter “tariff” used as a decision table:

Conditions
product code

client age
Value
tariff
PRD_A
0 - 30
0.95
PRD_A
31 - 60
1.10
PRD_A
*
1.30
WB_2
*
1.50
*
*
1.80

These business rules grouped as parameter “tariff” can be interpreted as follows:

when product is PRD_A and age is in [0, 30] then tariff factor is 0.95
when product is PRD_A and age is in [31, 60] then tariff factor is 1.10
when product is PRD_A and age is outside of [0, 60] then tariff is 1.30 (else semantics)
when product is WB_2 and age has any value then tariff is 1.50
for any other product and any client’s age, tariff is 1.80

All above rules form a decision table with a clear structure and meaning. This table can be used as parameter “tariff” in application code:

clientFee = baseFee * tariff + ... + additionalFee + ...

This shows how client’s fee calculation might be parameterized with tariff parameter. The terms parameter and decision table are used interchangeably in Hyperon.

All Hyperon rules are presented in a user-friendly manner – they are in the form of tables easily exportable to Excel or CSV files.

Hyperon as a Business Rules Management System is useful in the same kind of applications as other BRMS solutions are. These applications have one of the following characteristics:

01
they have a very complex business logic
02
they have a logic that needs to be changed very often
03
they need to have a business logic externalized and accessible to business experts

3. Business rules as decision tables

Hyperon parameters consist of 4 elements:

definition of conditions (input columns)
definition of outcomes (output columns)
matrix built from input and output cells
meta configuration (rule matching mode, caching, sorting, etc.)

Each input column (condition) has to be bound to some source. It can point to some valid data in the domain model – for example policy.insurer.age is a valid path to the number which is the age of the insurer found on insurance policy. It can be also bound to the outcome of some script or another parameter.

Each condition has defined matcher which is used to check if bound value matches to a pattern in input column. Common matchers are: equals, between, in, not-in, regex, like, contains/all, contains/any, etc.

Each output column holds potential parameter’s value. This potential value will become the outcome if all conditions in the same row evaluate to true.

Hyperon parameters can return a single value, several values (a vector) or even a matrix or table of values. In combination with different matchers, different matching modes and bound sources it is a quite powerful tool in developer’s hands.

The following screenshot presents a real-life example of a parameter defined in Hyperon Studio.

Screenshot: Sample parameter (business rules as a decision table)

On this screenshot you can see a parameter that has 6 conditions (IN columns) and 4 outcomes (OUT columns). Conditions include age and value of the vehicle (between matcher), name of previous insurer (in matcher) or insurer’s profile code (default matcher). Hyperon rules engine will find the best matching row and return its 4 values.

Typically, all Hyperon parameters are fetched from a database and converted into in-memory index when used for the first time. The in-memory index allows to find matching rows in few microseconds. The index structure guarantees O(1) lookups if all conditions use default matchers.

It is not uncommon to see a project with more that 500 parameters (decision tables) with many having more that 100k rows and some larger that 1 million rows.

4. Functions – script-based business rules

Although Hyperon decision tables are very powerful means to express business logic, sometimes this may not be enough. For such situations Hyperon offers a scripting language. In other words, developers or business users may write functions which behave exactly the same as decision table do – they consume some inputs and produce some outcome.

Users can write functions in Groovy or JavaScript (whichever they prefer) with help of Hyperon standard library. Functions let them implement any business logic they want.

The following is an example of groovy-based function:

def age = ctx.getNumber( 'client.age' );                // read client's age from model

def factor = 1.8;
if (age > 65) {
 factor = math.log(10, age);
}

def tariff = hyperon.getNumber('tariff', ctx);          // get value from tariff parameter
def baseFee = hyperon.getNumber('base.fee', ctx);       // get value from base.fee parameter

def fee = baseFee * tariff * factor;

return math.round(fee, 2);                              // return fee rounded to 2 digits

Hyperon functions can read domain model, evaluate parameters or call other functions. They can perform any logic dependent on domain model data. Hyperon functions come with standard library in form of predefined objects that enable developers to:

read data from domain model (context),
read parameters,
call other functions,
operate on dates and strings,
perform common math operations,
perform smart type conversions,
write statements to log files,
read hierarchical business configurations.

The following screenshot presents a real-life function edited in Hyperon Studio.

Screenshot: Sample function (script-based business rules)

Functions and parameters together form a coherent ecosystem:

functions can depend on values evaluated from parameters,
parameters can bind functions to condition columns,
parameters can define outcome as a call to a function.

Let’s see how this can be leveraged:

IN
insured.age

$f client.status
OUT
pricing factor
0 - 30
GOLD
3.0
31 - 50
GOLD
$f factor
*
GOLD
$f factor (50)
*
*
4.5

The above parameter:

defines first condition as bound to insured.age from domain model,
defines second condition as bound to value returned by client.status function,
the output column often use literals like: 3.0 or 4.5,
but sometimes it delegates evaluation to function call like: $f factor(50).

Many projects developed for insurance or finance industries have proven that Hyperon parameters and functions together can handle any business logic.

5. More business rules examples

It is difficult to see at a glance all the possibilities Hyperon offers as a BRMS. As it was mentioned earlier in the text users can express their business rules with different matchers and different matching modes. They can bind different sources to condition columns or use function calls directly in decision table cells. The following examples will demonstrate some of these aspects.

5.1. Cascading decision tables

Suppose we have a simple decision table with many rows but a single condition that maps an investment fund code to a management fee:

IN
fund.code
OUT
fee
FAR
0.30
FAR2
0.55
FBD
0.60
FBE
0.60
H01
0.90
HPP
1.00
HAPF
1.10
PAPR
1.15
HZA1
2.00
HZA2
2.30
HZA3
2.60
YME
3.00
...
...
VQF
2.55

Unfortunately, after some time an exception to this simple decision table has appeared – from now on the H01 fund fee should depend on the policy year and the policy premium amount. Moreover, the YME fund should have fee calculated with some math formula.

We can adapt easily by creating a H01-specific parameter and YME-specific function as follows:

Parameter “fund.fee.h01”:

IN
policy.year

policy.premium
OUT
fee
1
0 - 100
2.0
1
100 - 500
1.8
1
*
1.6
2
0 - 300
2.1
...
...
...

Function “fund.fee.yme”:

def year = ctx.getNumber( ‚policy.year’ )
def fee = 1.2 + math.log10(year * 8)

return math.round(fee, 2);                              

Now the “fund.fee” parameter can be modified to handle these exceptions:

IN
fund.code
OUT
fee
FAR
0.30
FAR2
0.55
FBD
0.60
FBE
0.60
H01
$p fund.fee.h01
HPP
1.00
HAPF
1.10
PAPR
1.15
HZA1
2.00
HZA2
2.30
HZA3
2.60
YME
$f fund.fee.yme
...
...
VQF
2.55

6. Try Hyperon for free

6.1. When to use Hyperon as a BRMS

Hyperon enables developers to externalize complex business logic. This logic (for example pricing or scoring rules) can be modified by developers or business experts in the Hyperon Studio UI. Each modification is immediately reflected in any application that uses Hyperon Runtime library, so we can say users may modify logic on the fly.

This is why Hyperon fits best to rules-heavy projects found often in finance or insurance industries.

6.2. Hyperon key features

Web UI that lets users to manage their business rules
Engine embeddable as a lightweight jar
Evaluate parameters or functions via HTTP
Create multiple versions of the business logic and schedule them in a timeline
Design any domain you want to configure with business logic
Groovy-based scripting language that lets users to extend decision tables
Optional fast persister of domain model data
Monitor the usage of decision tables and DSL scripts or functions
You can import / export configuration from / to Excel

6.3. What's next?

If you’re a programmer
Download Hyperon for free and test run one of our demos available on github and docker
If you’re more into business
Let us prepare for you free proof of concept for your business case using Hyperon
This article was written by Przemek Hertel
Przemek is creator and Chief Architect of Hyperon since 2013. Prior to Hyperon, Przemek designed and implemented SmartParam - open source library allowing lightning-fast querying for parameterized value.
If you like the article, feel free to share it on Facebook, LinkedIn or Twitter.