The background of the rules engine
In the application process of business system, there are often “complex and changeable” parts to deal with, which are often “business rules” or “data processing logic”. Therefore, dynamic rules in this part often need to be configurable and have certain requirements on system performance and hot deployment. From a development and business perspective, the following issues are highlighted:
1.1 From a developer’s perspective
1) Complex logic, use lots of if-else implementations, or use design patterns. However, the overly complex rule logic and the use of design pattern often have a large number of classes with complex relationships, resulting in difficult to maintain the code and unfriendly to new students.
2) When making changes, you need to comb through the logic from scratch and do if… else… Code logic adjustment, spend a lot of time combing.
3) The development cycle is long, and when the demand changes, the R&D personnel need to arrange the development cycle to go online. For the current rapidly changing business, the traditional development work method is not enough.
1.2 From the perspective of business personnel
1) Business personnel expect friendly management interface, which can complete the management and release of rules without professional development skills.
2) It is expected to achieve hot deployment, which is ready to use after being configured by business personnel.
3) Reduce the dependence of business rules on developers.
4) Reduce the time cost of requirement changes and quickly validate releases.
Second, rule engine introduction
2.1 What is a rules engine
A rule engine, developed from an inference engine, is a component embedded in an application that enables business decisions to be separated from application code and written using predefined semantic modules. Accept data input, interpret business rules, and make business decisions based on business rules.
Think of a rules engine as a system that takes data and rules as inputs. It applies these rules to the data and provides us with output based on the rule definitions.
2.2 Core concepts of rules Engine
- Rule: An inference statement consisting of conditions and actions, usually expressed as IF THEN, and Rule expresses logic. The IF part of a rule is called LHS and the THEN part is called RHS.
- Condition :(Left Hand Side) LHS, i.e. conditional branching logic
2.Action :(Right Hand Side) RHS
Fact: The Fact object entered by the user as a decision factor
RulesEngine: An engine executor, usually an inference engine. Rules uses LHS to match patterns with facts. When a match is found, Rules performs RHS or execution logic, while Actions often change the state of facts to deduce the desired result.
Output: Result object, the result of rule processing.
Application scenarios of rule engine
When a business grows from small to large, rules undoubtedly need to change frequently, and often need to be quickly online to adapt to market changes. This requires programmers to constantly put in more effort to meet the needs of the business as quickly as possible. In more complex business scenarios, programmers’ understanding of requirements is often inconsistent with the requirements of the product. The introduction of a rules engine is more appropriate when:
- Requirements are uncertain and change frequency is high
- Responses and decisions need to be made quickly
- Rule changes are expected to be independent of developers and independent of coding
- Process branches are very complex, rule variables are huge, and it is difficult to achieve if-else coding. Rules engine is used to separate changeable rules from other business logic.
- There are many services and high access costs
- Achieve hot deployment and reduce the cost of changing requirements
Four, EasyRules engine application
4.1 Business Scenarios encountered by the Project
In actual projects, the message scheduling system needs to select message policies according to the message scenario, content, channel, and event. It is very important to use different policies and channels to reach users in different message scenarios. Imagine when key messages don’t ultimately reach the user/merchant, both parties lose a lot of money. On the contrary, once part of the message frequently disturbs the user, it also tends to get half the result with twice the effort, leading to a large number of users lose patience with the App, resulting in user loss. It is of great significance for the scheduling system that the scheduling policy needs to reach different channels and policies for users according to the situation, user behavior and event.
However, in order to meet the decision logic of a large number of complex factors in business rules, and to support the continuous adjustment and expansion of rules, it is necessary to use hard coding to write into the system. At this time in the department of old Jia’s proposal, the rules of the engine into everyone’s vision. The ability to pull business rules out of the system and use engines to make decisions is exactly what we need. Compared with Drools, URule and other perfect rule management systems, EasyRules, as a lightweight Rule engine based on Java, has lower learning cost and stronger applicability, so I choose to use EasyRules practice rule engine.
4.2 Use service modeling to solve complex scheduling policy problems
1) The system usually only needs the decision results for business processing, and does not need to deduce the intermediate results of the decision process.
2) Business decisions are influenced by multiple factual factors
3) The factual factors of business decision and influence are known, that is to say, on the premise of confirming the factual factors, only the only decision can be deduced =rules(FACT1, FACT2, FACt3)
4.3 Let’s take a look at the first version of the rules engine
1) Since it is a rules engine, let’s look at a simple rule based on annotation declaration
Annotated declaration of Rule
2) Compound rules must be realized by multiple simple rules. For channel rules, single-channel delivery and multi-channel delivery also depend on different scenarios. Each single channel can be viewed as a rule, which is implemented by nesting multiple rules into a compound rule. Composite rules may follow different implementations to determine the final result. EasyRules implements the rules of ActivationRuleGroup, ConditionalRuleGroup and UnitRuleGroup3, which are priority ActivationRuleGroup, condition rule group and unit rule group respectively. We implement ChannelRule inheriting the compound rule group of ActivationRuleGroup, ChannelPushRule, ChannelLetterRule, etc. (other channel rules are omitted) as simple rules.
3) Once the rule definition is complete, half the development is completed. After all, everything is rules in the rule engine.
If it gets to this point, it’s just code level optimization. Still unable to show why the rules engine is so popular, let’s take a look at what the following version will surprise us
4.4 Implement the second version of the rules engine based on the expression language
MVFLEX Expression Language (MVFLEX) is the Java platform’s dynamic/static hybrid runtime embeddable Expression Language. It has many features that enable it to expose some logic to end users and programmers, including attribute expression, value detection, set expression, flow control, projection, intersection, function definition and so on. Let’s look at how business rule uncoupling can be done through MVEL string expressions.
2) In the above code, we can see that both condition and action use MVEL string expressions to define a complete Rule, so the definition of the Rule can be extracted separately according to the MVEL expression syntax. Now that the Rule can be separated from the system, let’s see how to load the decouple Rule code. Easy-rules already supports quick and easy loading of Rule description files from YML, JSON files. The following broken code supports loading rules from rule description files and reasoning rules and facts through the engine.
V. Summary and prospect
Rule engine has such application value in various application systems, and can bring greater power to business change and development. Introducing a rules engine to the project instead of the traditional hard-coding approach provides a better solution. This decoupling of rules from business logic makes it easier to manage rules as a whole, and hot loading enables projects to iterate quickly in shorter cycles. At present, there are still some problems, such as rules can not be completely separated from developers, need to shield the technical barriers to business personnel; Rules have no version control and need to be modified to the original logic if they fail in the validation phase. Need to have a better interface can be dragged to achieve the layout of rules; Engine precompilation for performance optimization and so on.
We have preliminarily confirmed the application orientation of the rule engine in the following projects, and we are committed to bringing greater efficiency improvement through this lightweight rule engine in more projects. We plan to improve the rule engine from the following aspects in the future:
1) Decouple the coupling of knowledge and business logic, and independently maintain the knowledge base for knowledge and version management
2) Better expression language or dynamic compilation language to improve the performance of the rules engine.
3) Optimize the performance of the management engine by using precompilation, caching, and thread pooling techniques.
4) Support gray version management, online verification, fast release. Reduce the cycle time of demand changes.
5) Shielding language barriers, enabling operations and products to support online rule configuration and release is an important goal to be achieved. Do not need research and development access, real-time release.
6) Develop rule sets, rule tables, rule trees, score cards and rule flows to improve rule management
