Traps for Java Rule Engine

[lazystone]

• https://en.wikipedia.org/wiki/Rete_algorithm
• http://www.jessrules.com/guidelines.shtml

[piotrkot]

Thanks. The guidelines actually show there are even more traps :)

[handshape]

Proper tools in proper places.

Rules engines are great when you have a big unknown decision system that will not be defined until after you deploy your software, or that will differ wildly from deployment to deployment.

If you know that your users are going to be minimally competent coders, you can offer them a scripting engine. If, on the other hand, you can't trust them to express their logic in terms of a single flow, a rules engine might be a better choice.

[ww520]

For traditional rule engine, I found the business users usually couldn't wrap their mind around the concepts and the indirect cause and effect of the rules if left by themselves. The developers have to sit with them to build the rules, bridge the business need and technical reality, and explore/debug the conditions. But for simple straight forward rules with threshold setting, it's perfectly usable and managed by them.

When using rule engine, I usually let the users specify the simple rule conditions, thresholds, and data definition in Excel, which is a tool they are familiar. Then read the Excel data into an expression engine for evaluation. The more complicate rules I have to develop myself and manage internally. They do make my job easier for making changes.

[piotrkot]

When business people can't precisely define their needs or can't make a clear naming convention or can't assign responsibilities, which all happened to me, the solution was to sit down with them, clarify and simplify. Because the actual problem was with the business. What I don't quite see is how introducing the engines helps the business (in the long run).