The background,

Blogger is a large domestic insurance company’s helpless pain development, daily work, need to contact a lot of customer risk control related rules, face a lot of differential logic, such as institutional differences, salesman, customer individual differences, different sales platform differences are quite large, even the logic complexity will only be more complicated than we imagine, even worse, These business rules are often subject to change. To meet this demand, our IT business systems should be able to be updated quickly and cheaply. To accommodate such requirements, it is common to separate the configuration of business rules and keep them decoupled from the business system. At present, the implementation of such functions of the program, has been developed as a rule engine.

Ii. Solutions

Rule engine is a kind of inference engine. It matches rules from rule knowledge base according to existing facts, deals with the rules with conflicts, and performs the final filtering rules. Therefore, rule engine is a part of the research field of artificial intelligence (AI), which has certain selective judgment, artificial intelligence and rich knowledge. Currently, the popular rule engines are iLog, a commercial rule engine, and Drools, an open source rule engine. This article will introduce the open source rule flow engine Drools in detail and give you a deeper understanding of the open source rule flow engine by analyzing a practical application case in the insurance industry.

For these situations, we provide a mature solution for handling business rules as follows:

1. Separate service logic from service rules, and manage service rules in a centralized manner. Simplify the system architecture and facilitate later maintenance.

2. Write rule files to implement service rules and store all rule files in rack packages. The logical structure of rule files is clear and easy to understand. The syntax of rule files is simple and easy to learn, just like writing SQL scripts. Each rule is logically independent and the coupling degree is reduced, so problems can be located quickly and accurately. The rule package can be controlled by version, and the modification record is clear. It is easy to unit test rules in an editing environment.

3. Obtain the inference conclusion of business rules by invoking the rule execution subsystem. Rule inference adopts fast matching algorithm, whose matching speed has nothing to do with the number of rules. It is very suitable for scenarios with a large number of service rules. Support to update rules without shutdown, fast response to production events. Easy to test the rule package as a whole.

4. Manage rules through the rule management subsystem. You can view the rule file in the rule package. Modify dynamic parameters used in the execution of service rules and provide permission control to ensure data security. You can quickly query the result of each rule execution to facilitate troubleshooting.

Three, code,

Take a very simple example to verify the claim information of a customer. The claim identification of the customer has been obtained by the business system in advance, and the verification is performed by calling the Drools-related rule system together with all other information:

package com.xxx.lcloud.rules.bean.vo;

import com.xxx.lcloud.frs.api.base.Translate;
import com.xxx.lcloud.rules.bean.vo.addition.InsurantAddition;
import com.xxx.lcloud.rules.bean.vo.base.Insurant;
import java.io.Serializable;

@Translate("Insured Persons")
public class InsurantVO implements Serializable {
    private static final long serialVersionUID = 1L;
    private Insurant insurant = new Insurant();
    private InsurantAddition insurantAddition = new InsurantAddition();

    public String toString() {
        return "InsurantVO [insurant=" + this.insurant + ", insurantAddition=" + this.insurantAddition + "]";
    }

    public InsurantVO() {
    }

    public Insurant getInsurant() {
        return this.insurant;
    }

    public void setInsurant(Insurant insurant) {
        this.insurant = insurant;
    }

    public InsurantAddition getInsurantAddition() {
        return this.insurantAddition;
    }

    public void setInsurantAddition(InsurantAddition insurantAddition) { this.insurantAddition = insurantAddition; }}Copy the code
package com.xxx.lcloud.rules.bean.vo.addition; xxx import com.xxx.lcloud.frs.api.base.Translate; import java.io.Serializable; import java.math.BigDecimal; @Translate("Insured Additional Information")
public class InsurantAddition implements Serializable {
    private static final long serialVersionUID = 1L;
  
    @Translate("Special Claim Record Mark")
    private Boolean specialClaimFlag;


    public Boolean getSpecialClaimFlag() {
        return this.specialClaimFlag;
    }

    public void setSpecialClaimFlag(Boolean specialClaimFlag) { this.specialClaimFlag = specialClaimFlag; }}Copy the code

Rule file:

package rules

import com.xxx.lcloud.rules.bean.vo.*;
import com.xxx.lcloud.rules.bean.vo.base.*;
import com.xxx.lcloud.rules.bean.vo.addition.*;
import com.xxx.lcloud.rules.bean.results.*
import com.xxx.lcloud.rcs.util.ClientType;
rule "insured"
    dialect "mvel"when InsurantVO( insurant ! = null, insurantAddition ! = null, insurant.mainInsurantFlag ==true,
        insurantAddition.specialClaimFlag == true.$insurant :insurant
    )    
    executionResult : ExecutionResult()
then
    RuleFailureResult ruleFailureResult = new RuleFailureResult();
    ruleFailureResult.setClientNo($insurant.getClientNo());
    ruleFailureResult.setReasonType(".");
    ruleFailureResult.setReasonDesc("The customer has a claim report record");
    ruleFailureResult.setReasonFileCode(drools.getRule().getName());
    executionResult.addRuleFailureResult(ruleFailureResult);
    executionResult.setPassed(false);
end

Copy the code

The semantics of the above code: if the customer is the main insured and there is a historical claim record, the corresponding business rules need to be returned to the business system for unified follow-up business flow;

Of course, Drools can help us solve problems in more complex and bizarre scenarios. For example, in multi-conditional judgment, we can use a decision table, which can be interpreted as a small database table.

Decision table, also known as judgment table, is a tabular graphical tool, which is suitable for describing the situation where there are many judgment conditions, which are combined with each other, and there are multiple decision schemes. A precise and concise way of describing complex logic by matching multiple conditions to actions to be performed when those conditions are met. But different from the control statement in the traditional programming language, the decision table can directly relate multiple independent conditions and multiple actions to express clearly.

Objective: To unify the rules with the same logic and different data into decision table

Implementation principle: Decision table management decision table header, a table header can have multiple sets of decision table data. Decision table data can be associated with multiple business subrules (usually one)

The decision table manages XLS in the user-generated rule package. The decision table is N data generating N DRL rules, and the logic is generated by the table header.