Replace code with rules engine

    The basic principle of the business rule management system is to replace the business logic "solidified" in the application system with program code with one or more rule engines. A complete VRS can manage the entire life cycle of business rules.

How is business rule management implemented?

Business Rules

A business rule consists of a set of conditions and actions to be performed under the conditions, which represent a piece of business logic for the application of the business rule. Business rules should usually be developed and modified by business analysts and policy managers, but some complex business rules can also be customized by technical staff using object-oriented technical languages ​​or scripts. The theoretical basis of business rules is: set one or more conditions, when these conditions are met, one or more actions will be triggered.

Rules Engine

VisualRules is a business rules engine written in Java language. VisualRules allow business logic to be expressed declaratively. Rules can be written in a unique local language for easy learning and understanding. And, you can also embed Java code directly into the rules file, which makes learning VisualRules even more attractive. VisualRules also has other advantages:
very sound technical support
Easy to use
Fast execution speed
Rules are compiled into Java code, cross-platform More
than 10 years of dedicated R&D investment The requirements of     VisualRules from the initial design of the product, it is very concerned about how to make the user easy to use and reduce the user's workload.






On the user interface, VisualRules provides some specific functions for different operators. For example, it provides developers with the java language familiar to developers, so that developers can use their familiar language to understand business logic more deeply; provides business language and flow chart for business personnel and managers, which can be used by business personnel themselves. language to understand business logic. In addition, VisualRules also provides the function of rule tree, that is, it can define the mutual relationship of related rules in the form of tree, including common condition relationship, cycle relationship, and sequence relationship. Allowing users to clearly guide the flow of rule execution during the editing rule stage.

    VisualRules is basically based on the characteristics of the database system for domestic projects, integrates the database layer, and realizes the change of the database layer at any time. A large number of wizard functions have also been added to help users operate the database in the rules very conveniently. In addition, users can execute rules directly in the editing interface, and the data executed by these rules can be test data. At the same time, it provides the function of data review, and you can see the original data and the result data after the rule execution directly in the editing interface. These functions make it very convenient for users to customize the rules.

    When VisualRules changes to the rules, it may lead to changes in the interface of the rule package. The interface is stored in map mode, so that the interface of all rule packages can be modified at any time. At the same time, combined with the code generation technology, other related program codes, including jsp codes and other java class codes, can be generated for technicians. This allows technicians to generate a completed application of the calling rules just through the configuration page.
VisualRules provides different versions for different users. The following describes the advantages of VisualRules in specific versions. For technical personnel, VisualRules provides a developer version of the rule editor. The developer version has the following advantages:

a single file centrally manages all rules and business objects related to the rule package.
    Developers can process the rules related to this rule service in the same rule package. All parameters, data sources, technical and business vocabulary, business rules.
However, products such as JRules need to define XOM, BOM, RULESET, RULE, etc. in different places. It is difficult for you to fully grasp all the business rules and business objects required by the rule service in a unified place. Centralized and unified management can greatly provide convenience for users and reduce development work.
         
The version control for the rule package
    and the centralized and unified management also provide the possibility for the overall version control of the rule package. For many actual business requirements, the same rule service will call different versions in different time periods or under different conditions (that is, some of the specific rules will be different), and these versions may be all at the same time. to be effective. Therefore, unified version control is required for the rule package.
At present, products such as JRules can only provide version control at the rule level, and cannot achieve version control at the level of the entire rule package.
Supporting rule branching and looping rules
    In actual business rule practice, there are always some rules that are triggered only when a certain common condition is met, and some rules are also triggered in a certain loop. VisualRules can set common conditions or loop conditions in the rule set, so that all the rules below the rule set must meet the common conditions to be executed, or it is executed in a loop.
    The rule set of products such as JRules cannot set working conditions and loop conditions, so JRules cannot effectively control the execution of rules. In many cases, it needs to be solved by setting a large number of conditions for each rule or through temporary variables and other flexible methods. Such solutions are very far-fetched and cannot reflect the characteristics of business logic in business language.

Java code comparison generation in the editing phase
    Since technicians use the rule editor, they pay more attention to whether the technical mapping corresponding to the actual business logic is correct, so the technicians pay more attention to the java program code generated corresponding to the business logic, and if the technician already has the foundation of the java language, then Viewing the generated java code will be more intuitive and easier to understand than fancy cultural business logic. The reason is also obvious, because the business logic described in Chinese, the same sentence may be implemented by different technologies in different environments. So if you want to focus on specific implementation details, you need to look at the actual code. VisualRules can automatically generate corresponding java code in real time, which will be of great help in testing and troubleshooting.
    And products such as JRules can only see the TRL language, which requires technicians to learn a new language, which is not easy to understand.

Support the overall test of the rule package
    VisualRules can directly test the overall rule package in the editing environment. When testing, you only need to enter the values ​​of the required parameters, you can view the output results, and you can see the entire rule execution path and the corresponding data changes. In this way, it is very convenient to test and check the rule package, or to check a certain rule or rule set below.

    However, products such as JRules must independently write corresponding java programs under development tools such as eclipse to drive the execution of the rule package and conduct debugging tests, which makes testing and other work very difficult (compared to the original use of coding methods to implement business logic for debugging. equally difficult).
Unit testing of rule sets and rules
VisualRules can perform unit tests on rule sets, rules, decision tables, etc. in the editing environment. This makes it very easy to block errors.
Products such as JRules do not support operations such as unit testing at all, unless a rule package that only contains the rules that need to be tested is added for testing, which becomes very difficult.

Support rule execution trajectory tracking
    When the rule package is called, sometimes the user needs to know which rules are activated by this call, their execution order, and the modification of the business object when the rule is called (before entering the rule, what state of the business object, after the After the rule is executed, what state the business object becomes). VisualRules can record all the execution traces of these rules in the current run for users to check, or store them in the database for later reference. This is very useful when the user is checking the rules, and can immediately locate the error that occurred when the rule was run.
And JRules, etc. do not provide this function. He can only do it by debugging.

Support rule exception handling
    VisualRules can define a variety of exception handling methods for rules by setting rule properties. This allows exceptions to be handled inside the rule.
    JRules, etc. can only handle exceptions at the rule package level.

Support dynamic rule package call interface
    VisualRules supports external calls to directly pass parameters into the rule package in various ways such as numerical value, string, class object, etc., which makes the parameters of the interface dynamic. Especially when the rule service method is adopted, if the interface is changed, there is no need to modify each program that originally called it.
However, JRules, etc. must pass parameters in the form of class attributes, so that the transmission of parameters cannot be dynamic, and the rule service interface cannot be easily changed.

Integrated dynamic OR mapping
    VisualRules fully considers the characteristics of database-based projects from the very beginning, and a large number of rule judgment basis (such as parameters and original data, or result data) need to come from the database, so VisualRules in the business rules processing business objects , the operations of the database layer are seamlessly integrated. Making rules to manipulate data in the database is as convenient as dealing with a common business object, and making database objects like rules can be changed at any time.
However, products such as JRules access the database through class objects, so that the database objects cannot be easily changed, and it also makes it very difficult to operate and access the database.

Automatic generation of JSP-based business system operation interface
    VisualRules can configure and generate JSP pages that call this rule package in the rule editing interface, so that the operation interface can be easily generated. This is somewhat similar to the form designer in workflow. It's just that the form designer in the workflow has relatively fixed relative parameters and a unified format. The page configurator of VisualRules, however, can generate pages for different project characteristics according to different template designs. The generation of JSP pages makes it easier to test the rules, and even a complete database-based management system can be easily developed with this function.
Tools such as JRules do not provide such functionality.

VisualRules provides the editor version of the rule configurator specially for business personnel. The editor version has the following characteristics:

    complete rule editing function with user authentication. The
editor version is used by business personnel and must be authenticated by user name and password. This identity authentication can be combined with the business system. And through the permission assignment of rules, users can only view and modify the rules that they have permission to. This ensures the security of rule modification.
However, tools such as JRules cannot directly provide a complete rule editor with strict authentication for business personnel. It can only operate through its own rules management system. This makes the operation interface of technical personnel and business personnel inconsistent, which increases the difficulty of communication.

It supports business personnel to directly test the rule package and
    the overall test of the rule package, or the unit test of the rule and rule set, which is also provided in the edit version. In this way, the business personnel can directly test the correctness of the rule setting in the process of modifying the rule.
    Products such as JRules need to check the correctness of the rules through debugging and other means, so that only technicians can test the rules and verify their correctness.

In the editing phase, the source data can be viewed.
    The editing version cannot operate the database layer in the object library, that is to say, it cannot directly operate the database. However, it can provide a function for users to directly view the source data, so that when business personnel edit rules, if they need to query data, they do not need to query through the reporting system, and can directly view the source data in the corresponding database in the editing interface. Greatly eases the development effort.
Products such as JRules do not provide such functions.

Supporting decision tables of various styles
    VisualRules has designed a variety of decision tables for the special situation of domestic decision tables, including table decision tables, multidimensional decision tables, and association decision tables. Of course, it can also be expanded according to the actual needs of the business system. These different types of decision tables allow business personnel to express business logic more simply and conveniently.
    JRules only provides an implementation of a decision table, and this decision table cannot be well described when describing domestic business needs.

The flowchart that supports the rule package shows that
    VisualRules can directly generate a flowchart including all business logic and flow direction in the editing phase. This flowchart can be exported to html and sent to relevant personnel for review or approval. This allows business personnel to see all relevant information in one picture, which is very in line with Chinese thinking and easy for Chinese people to understand. When the specific process is displayed, some rules that only technicians care about can also be hidden, so that the flowchart only displays the logic related to the business.
    However, JRules can only provide a partial flow diagram, and cannot include specific specifications in it, nor can it describe the entire flow diagram in one picture.

Support user to modify track record
    In the rule editing phase of VisualRules, the information of the modified user is recorded in the modified rule file. In this way, it is possible to track a rule, when it was modified by whom.
    However, products such as JRules do not record the information of editing users.
    In general, VisualRules adds a lot of functions in terms of ease of use according to the characteristics of domestic users and the characteristics of database-based projects. These functions greatly simplify the user's work, and the actual writing of business rules can be set and reviewed by business personnel. In addition, VisualRules can improve various functions required by the national tax system according to the situation of the national tax system, in order to meet the needs of the national tax system to the greatest extent.

The internal

     mechanism of the rule engine to implement the rule engine is to retrieve the data objects submitted to the engine, find the qualified rules from the rule set loaded into the engine according to the current attribute values ​​of these objects and the relationship between them, and create Instances of execution of these rules. These instances will be executed in a certain priority order when the engine is instructed to execute. Generally, the rule engine consists of the following parts: working memory, used to store the set of data objects referenced by the engine; rule execution queue, used to store activated rule execution instances; static rule area, used to store all loaded These rules will be organized according to a certain data structure. When the data in the workspace changes, the engine needs to quickly adjust the rule execution instances in the rule execution queue according to the current status of the objects in the workspace.