The core of the USoft low-code platform is the rules engine. This ensures optimal data consistency and thus safeguards the quality of all data entering the system and possibly being redistributed to other systems. The rules engine also simplifies system programming and enables us to work in low-code. But what exactly is a rules engine? How exactly does it guarantee quality and when is it wise to use a rules engine? In this article I will explain it.

To explain the rules engine it is good to start with an analogy. Rules engines start from well-defined definitions:

• There are persons.
• Pieter is a person.
• Abby is a person.
• A person can love another person.
• If a person loves another person, they should send him or her flowers.
• Abby loves Pieter.

It is a simplistic model, but in this we can recognize: the data model, data and rules. If we implement this set of rules and data in USoft then Pieter will automatically be sent flowers by Abby.

Business rules based on human logic

The USoft rules engine behaves as a data inference engine. If no persons or relations are entered, nothing happens. If we only add persons, nothing happens yet. Only after persons are entered with the condition that one loves the other, something happens. The engine will recognize that there is a person who loves another person, so flowers must be sent. This is how this is defined in the definitions.

The rules engine will “realize” at every data change, that data is being touched. Both the moment a person is entered, and the moment that for Abby is told she loves Pieter. All actions are seen, hence the name "data inference engine". The rules engine builds a network of all the conditions in the rules and checks them at every interaction with data. Only when all the conditions of the rules are met do the flowers go out the door.

In USoft Studio, the creator of such a flower-sending rule has made that rule understandable in beautiful English or Dutch and has defined the context around it: persons, love... USoft Studio is our solution for describing business rules in natural language. Eventually, someone also specified the data model in the USoft Definer and worked out the rules in it. To make that rule understandable to the rules engine, he specified it in the form of conditions and actions. For example, like:

     "For Persons make sure that Flowers_Sent = done where Persons.loves = Persons.id"

This is a business rule that specifies how the software should react to the described event. In this case the event "loves" is entered at Abby with value Pieter. This event is within the USoft context the sum of all data changes. So, in the above, the moment when Pieter as a person is designated as the one Abby loves. In the timeline, all moments of data touching can have any order and any values. Only when it is entered that Abby loves Pieter are flowers sent. So here the rules engine deviates from predetermined "what if" rules.

Automate the 'rules' instead of the processes

The nice and convenient thing about the rules engine is that the order of individual data changes doesn't matter. The creator of rules writes those rules based on what is the condition under which flowers should be sent. And if that rule is met at a given time, the flowers are automatically sent. The business rule is a self-contained piece of code. You can turn it off if you no longer want flowers to be sent automatically.

An important element in the above example is that with the rules engine we do not describe HOW something should be done, but WHAT. This is a difference with programming in a "normal" programming language. There, the programmer not only describes what should be done, but also how this is done and under what conditions. With a series of "what if" conditions, the choice is finally made that flowers must be sent. This creates much more code than is needed within the USoft platform. Creating the data model, the relationship and entering data within USoft immediately brings this model to life.

The use of a Rules Engine

Another important element is that the rules engine will check all data operations from all possible angles against the rules in place at the time. The rules engine is positioned between the data and the logic. This also means that the logic is separated from the data, which greatly increases readability. On top of that, rules are much easier to read than program code.

It is not always useful to use the rules engine. The rules engine is of great use when the environment is subject to a lot of changes, the logic changes a lot (e.g. is constantly being refined) and there are many "if then" constructions that can be written down as business rules. The rules engine is not necessarily suitable for workflow-like systems or when the logic is fixed and never needs to be modified after coding once.

Of course, the software and rules will still need to link to a flower store so that Pieter will actually receive the flowers from Abby.

The advantages of a rules engine in brief

Declarative programming instead of imperative programming

• The rules engine allows you to say WHAT is to be accomplished, not HOW.
• It is easier to express solutions to difficult problems in business rules than in program code.
• Based on business rules, the most complex problems can be described. The rules engine ensures that the rules are combined in the right way.
• The solution can be verified immediately.
• Rules are much easier to read than code.

Logic and data separation

• Data is in domain objects, logic is in business rules
• Logic can be maintained much more easily if there are changes in the future, since the logic is all contained in unified readable rules

Speed and scalability

• Using the rules engine is a very efficient way to link rule patterns to data

Centralization of knowledge

• The rules themselves are a repository of knowledge
• The rules are the single point of truth

 When to use a rules engine?

• When the logic changes a lot or is constantly being refined.
• Rules engines can be used even when the problem is not fully known.
• If a lot of knowledge lies with the business and little or no programming knowledge is available.
• Logic can be expressed in business rules.
• When there are many 'if then' rules in the code