We’re really doing a very good experience in handling rules engines . Through this project we had to face both the implementation of the rules and the implementation of a system that would allow to generate product configurators easier to use.

A rules engine is ” technically ” a nice toy . Seeing it run on thousands of conditions in a flash knock impresses IT addicted . And playing writing esoteric rules is a funny game .
In addition , it allows to approach old problems in entirely new ways and , indeed , very effective .

Let’s say , however, that like all the ” libraries ” , deploy this approach at  production level , make it accessible to an audience of humans not so enamored of development requires some features that the rules engine in itself does not provide .

And if the audience of users of the ” result ” of the rules engine covers extends , well, then we are part of a real production system.

WHAT TO DO TO PUT IN PRODUCTION SYSTEM AS DROOLS ?

The rules engine used ( Drools ) is a library that can connect to the system of rules defined with Guvnor , generate a Working Memory, take in a series of objects and “shoot ” all the rules according to objects inserted .

The result is the creation or removal or modification of objects.

Objects must then be re-read and interpreted out from the working memory .

The main problems that we have identified and tried to overcome are the following

PROBLEM 1 : MANAGEMENT OF THE COMPLEXITY OF MANY “MODELS “

In a production environment, the complexity of the models can change over time and in particular the number of models can grow as you solve problems.

So in a production environment it is very important to be able to define “dependencies” between the models. Be able to  reuse existing models in more complex models without going crazy with cataloging rules and definitions of abstruse priority.

The context that we experienced for our customer is so that models are defined to select the best product for the customer scanning through many different models and then to configure individual products .

PROBLEM 2: HARD TO LET  THIRD PART SYSTEMS USE DROOLS “AS IS”.

Talking with Drools,  respecting the constraints of the system is not so trivial. Un hypothetical third system needs to call the model must be able to do it easily.

I’d say a nice REST layer is the answer.

PROBLEM 3: COMPLEX AND LIMITED DEBUG

Well, debugging provided by Guvnor is not the most immediate of the earth. It is based on creating TEST where you write by hand all object instances, you run the “Test Scenario” and you see the rules fired.

If the combinations of objects inserted are many, work is very huge.

PROBLEM 4: LACK OF SESSIONS PERSISTENCE

If a “remote” user  gets an error during the  use of a Drools session , you must replicate all the entry conditions. Unless there is some clever system that has saved the session and can recall it easily

PROBLEM 5: DIFFERENT RESULTS ON BOUNDARY CONDITIONS CHANGE

In a production environment, the rules are not black boxes detached from the rest of the systems. On the contrary they should change over time, perhaps based on external conditions such as data in a database. And this must be done without having to rewrite the rules.

WHAT HAVE WE DONE TO OVERCOME THE LIMITS?

We have developed an entire system software that can “embed” Drools and filter the use to simplify it.

FIRST PART: A COMPLETE SYSTEM FOR CONFIGURATION MODELS

A central system to manage a repository of models. Every repository contains a reference to a package in Guvnor and defines testing environments or production.

SECOND COMPONENT: JAVA LIBRARY FOR FOR INTRA-MODEL COMMUNICATIONS

A library instantiable in Guvnor that drives the engine so that you can write rules that call other packages. A model that chooses between products can then generate autonomously a session on another model (configuration of the single product) and receive the output.

THIRD COMPONENT: LAYER REST

The core of the system communicates with the outside by means of calls supported by RESTX rest. Any third system can generate sessions, recall, push objects in drools and read the results, run reports etc.

FOURTH PART: ADVANCED DEBUG SYSTEM

A full web suite of debugging suite tools showing the execution of each session which rules fired and which errors had.
This feature is particularly necessary when the hierarchy of the models become complex.

The pictures belows show what we read in the debug at every entry of variables in the system (users’s choice of options in the web application)

Another component, the coolest is the EXECUTIONS TREE.

Topic of the post is how to manage Rule engine Humanly, or how to make usable a system like drools in a context where there is a human being who must interact. This has been our guiding star that make us decide that a rules system so made had to think about the concept of question and answer: I ask you something, you answer me, based on your response I reckon questions.

This allows you to represent the interaction Man <-> Engine but also a relationship of like  any type of computer system  <-> rules engine. (See here)

This metaphor is crucial and it ALLOWS TO REPRESENT THE BEHAVIOR OF THE SYSTEM ON  A READABLE GRAPH. A Graph that can be calculated by the system and displayed to the user to verify that ALL options combinations are correct.

To calculate the graph the system must go through all the possible combinations of questions – answers and then normalize everything.

An everage product configurator can be up to tens of thousands of nodes to go in testing: a inhumane debugging time which can instead be done by the system. The computation times are still very long but …

… A good battery of machines in the cloud with Amazon and solve the problem. But that’s another story we will tell in the near … Blog

Meanwhile: