, ,

Enterprises dealing with Finance often have complex calculations to perform. Consider income tax calculations for example. There are innumerable rules and sub-rules that we think it is better that experts handle it. What about sales tax, exemptions and the fact that these rules vary from place to place, country to country ?

We had a similar problem at hand. Though not in the taxation domain. But the problem to be solved is much similar. There are these various rules, their processing, their maintenance, the results, its correctness and of course performance.

So whenever people mention tax rules to me and me not being a domain expert at anything, using Rules Engine was a natural choice to me. I could neatly phrase the rules as
WHEN this condition occurs
DO this
Little did I noticed that I would be trapped.

Rules Engine are good at matching the correct set of rules and executing them. But performance goes down if the “facts” (data on which the rules are being applied) change during the course of executing any particular rule.
As a “Rule”, Rule engine fires all rules when a “fact” is updated. This leads to an infinite loop if adequate precautions are not taken care.

Moral No. 1 : To use Rule Engine effectively, do not update “facts”. Use other data structures to record the changes.

One of the typical applications of calculation engine would be model and execute rules of the following type.

if X > Y then
X = Transform(X)

If X + Z > 50*P then —–> Here X refers to the Transformed value !!!
…do something else …

This leads to a pattern like

Apply Rule 1 with virgin “facts”

Apply Rule 2 with modified “facts”

If I follow Moral 1, then I would not be able to achieve the patterns above. If I do not follow Moral 1, it leads to unmaintainable Rule code (lot of defensive code to prevent infinite loops) and poorly performing code.

Moral No. 2 : Rule Engine has its limitations. Rule Engine is DIFFERENT from a Calculation Engine.

Ok, now I am exploring this to see how to realize a Calculation Engine.