What you should look for when selecting your Business Rule Engine (BRE)
Encapsulating a business domain in applications brings a lot of benefits. So in developing a complex application you may either find yourself developing a rule engine, or you buy a commercial one.
Whether you buy or develop that component, it must have some features to make application development easier.
In this article, I briefly examine those characteristics. In future posts, I will describe each in detail.
What we mean by ‘communication’ is the way your application and rule communicate with each other. This communication ideally should be two-way (i.e., application to rules and vice versa).
A very important factor to consider if you are choosing your tool or buying one, is whether there is any limitation in passing some information (object) to a rule? Does this involve implementing a specific interface or have some particular attributes?
Ideally, there should not be any restrictions. So you should have the absolute flexibility to implement a rule that accepts any object and works out what to do with it.
Building up expressions:
Rules definition must allow you to build up expressions. For example:
This capability allows you to express the rules and logic without the need to hardcode high-level logic in the application.
Method calls capability inside a rule is also very important. For instance, the capability to build your expressions and combine them with method calls:
- car.GetHireLength(DateTime.Now) + customer.Allowance
This capability allows you to express the rules and logic without the need to hardcode the logic in the application.
The expression should support both complex and combined operations. This enables the implementation of complex rules and logic (e.g., formula, property access, array or list item read, etc.)
If the rule engine does not provide this functionality, you end up writing it in the application source code. Well, this defeats the purpose.
During the execution of a rule, there are situations where rules need to change values or the value of a property of an object. For example, an invoice rule should set the tax component of the invoice. Or for another example, based on the customer loyalty level, the rule should set the delivery component or discount on the invoice object.
This capability allows you to write more isolated rules and keep the entire logic outside of application’s source code.
Another important factor is the way your tool enables the reuse or sharing of logic between many decisions. Or even at a higher level allows the combination of many decisions for different scenarios.
Reusability at different levels increases productivity and also standardizes the logic and business rule implementation. Eventually it reduces maintenance efforts and decreases ambiguity.
The ability to extend your tool’s capabilities without changing its actual code (if you are writing your own, or choosing an open source) is very important. You cannot compromise this! The reason being that if your tool does not support all of your niche requirements out-of-the-box, you must be able to extend it in your own way. For example, in a warehouse management system, “if a level of stock goes below a certain threshold, send a notice.”
What if you want that notice to be sent via an SMS? Should your tool support the sending of SMS out-of-the-box? Not really. But does it allow you to code this capability (e.g., sending SMS) and use it as part of your decision-making process, as well as reuse it in the future? Absolutely yes!
Extensibility has different aspects that you need to consider:
- Language (the way you express a rule, flow, decision, etc.)
- Type of logic (Boolean logic, procedural, inference, etc.)
- Commands (new commands e.g. sending sms, etc.)
- Storage (Cloud, Database, file system, etc.)
- Security (Runtime execution permission, load, etc.)
Debugging capabilities are a must have. You need some way of understanding what is happening inside the rule during execution at any point in time. But again, the way the tool provides this capability and the way you like doing it again depends on you and your team. Do you like a visual debugging mechanism or pushing rule execution trace to a file?
Consider your team skills and non-technical stakeholder involvement in the project to decide whether you need visual debugging capabilities or not.
Visual authoring tool:
If the tool provides a way of modeling the decision and rules in a visual way, that is an absolute benefit. Visualizing simplifies any complexity and facilitates communication between stakeholders.
Depending on the team using your tool (rule engine), sometimes this can be a bonus point. Or you may want to write a visualization tool on top of the engine instead of using the existing UI tool. It’s all about communication between stakeholders and seeing what works best for you.
This is just a listing of important factors to consider and a simple description of each item, plus the reasoning behind these. In next article, I will give you more details about every item mentioned here.