Method for constructing a visual business rule engine based on a scripting language

Abstract

The present invention proposes a method for constructing a visual business rule engine based on a scripting language. Based on the scripting language and metadata modeling, in cooperation with a specific business scenario rule execution scheme algorithm and scripting extension capabilities, a unified rule scheme execution interface is exposed for the business side to call, realizing the visual registration, orchestration, and configuration of specific business scenario rules. The business rules of a specific business scenario are separated from the process processing execution logic, and visual configuration is achieved. Only by page configuration can the addition, modification, and removal of business rules be realized, achieving the centralized management of business rules, reducing the development threshold of business rules, and effectively solving the problems of system maintainability, R & D efficiency, and R & D costs caused by the changeability of rules in the business system. On this basis, a visual work order scheduling engine can be provided.

Description

Technical Field

[0001] The present invention belongs to the technical fields of computer programming, scripting languages, and visual business rule engines, and particularly relates to a method for constructing a visual business rule engine based on a scripting language. Background Art

[0002] During the research and development process of enterprise application systems or Internet application systems, the involved business scenarios are becoming increasingly complex, the requirements for business rules are numerous, the iteration and change speed is fast, and the system object system is huge. For the business system to adapt to such changes, the traditional approach is to add a lot of judgment logic code and changes to the business process code, resulting in the business rule logic of the system being scattered in various corners of the system, making it difficult to manage and troubleshoot problems, greatly increasing the maintenance and R & D costs of the system.

[0003] Introducing a rule engine to separate the business process execution logic and decision-making judgment logic can alleviate some problems, but finding a suitable rule engine still faces many challenges. First, the open-source rule engines on the market have limited functions, such as lacking the ability to execute scripting languages and SQL simultaneously. Second, it is difficult to expand the capabilities of the rule engine to meet the needs of complex business rule scenarios and it is difficult to achieve visual configuration management. Third, there is a certain threshold for the open-source rule engine itself, and the resulting R & D efficiency benefits are limited. Summary of the Invention

[0004] Considering the defects and deficiencies of the existing technology, the purpose of the present invention is to provide a method for constructing a visual business rule engine based on a scripting language to solve the problems of system maintainability, R & D efficiency, and R & D costs caused by the changing rules of the business system.

[0005] Based on the scripting language and metadata modeling, combined with the specific business scenario rule execution scheme algorithm and scripting extension ability, expose a unified rule scheme execution interface for the business side to call, and realize the visual registration, orchestration, and configuration of specific business scenario rules. Separate the business rules of specific business scenarios from the process processing execution logic, and realize visual configuration. Only through page configuration can the addition, change, and removal of business rules be realized, achieving centralized management of business rules, reducing the development threshold of business rules, and effectively solving the problems of system maintainability, R & D efficiency, and R & D costs caused by the changing rules of the business system. On this basis, a visual work order scheduling engine can be provided.

[0006] The present invention specifically adopts the following technical solutions:

[0007] A method for constructing a visual business rule engine based on a scripting language, characterized by including the following steps:

[0008] Step S1.1: Conduct metadata modeling for the business system, and define entity tables and attribute tables to register system metadata;

[0009] Step S1.2: Develop and implement a rule script execution engine. The script executor supports at least the parsing and execution of groovy and SQL script languages;

[0010] Step S1.3: Develop and implement an algorithm for the rule execution plan in specific business scenarios. The rule execution plan algorithm includes the arrangement of the rule execution order and the basic logic for input and output processing of the plan, rules, and scripts;

[0011] Step S1.4: Visual registration of rules in specific business scenarios, including configuring the basic information of the rules, rule scripts, and rule parameters. One rule allows to be reused by multiple execution plans;

[0012] Step S1.5: Visual registration of the rule execution plan in specific business scenarios, including the arrangement of rules and the registration of plan elements. One execution plan allows to be reused by multiple refined business scenarios;

[0013] Step S1.6: Business arrangement configuration of the rule execution plan in specific business scenarios, that is, binding the association relationship between refined business scenarios and rule execution plans in specific business scenarios;

[0014] Step S1.7: Expose the execution interface of the rule plan for the business system to call, and expose the plan parameter query interface for business developers to query the rule parameters required to execute a certain rule plan.

[0015] Furthermore, in Step S1.2, the development and implementation of the extended ability of the rule script in specific business scenarios is to develop extended capabilities for the rule script to call when the native script basic capabilities cannot meet the business requirements.

[0016] Furthermore, the specific business scenario refers to work order scheduling. The rule execution plan for work order scheduling, abbreviated as the work order scheduling plan, consists of mandatory rules, preferred rules, and scoring rules.

[0017] Furthermore, in Step S1.3, the execution plan algorithm includes the following steps:

[0018] Step S3.1: Execute mandatory rules. Each mandatory rule filters out several target scheduling objects (including but not limited to personnel, departments, teams). The results of multiple mandatory rules are taken as the union. If the results of all mandatory rules are empty, return failure and end the scheduling;

[0019] Step S3.2: Execute preferred rules one by one in the order of priority. Each preferred rule further filters and screens scheduling objects based on the current scheduling results. Once the scheduling results are empty, return failure and end the scheduling;

[0020] Step S3.3: First, initialize the score of each scheduling object in the current scheduling result to 0, and then execute the scoring rules. Each scoring rule adds a set score to each scheduling object in the current scheduling result.

[0021] Step S3.4: Select the scheduling object with the highest score from the current scheduling result as the scheduling scheme result and return it, indicating successful scheduling.

[0022] Furthermore, the specific business scenario refers to business decision-making. In step S1.3, the execution scheme algorithm is a binary decision tree, where the root node and internal nodes are conditional expressions, and the leaf nodes are decision selection targets. Register the expressions of the root node or internal nodes as decision rules, with the output type being a boolean value. Register the entire binary decision tree as a rule scheme, with the output type being a decision selection target, thereby forming a visual business decision-making engine.

[0023] Furthermore, the business orchestration in step S1.6 is configured as follows: directly match the rule execution scheme of the specific business scenario according to the specific business attributes, or use the decision-making engine to match the target rule execution scheme.

[0024] Compared with the prior art, the present invention and its preferred solutions separate the business rules of specific business scenarios from the process processing execution logic, and achieve visual configuration. It is only necessary to configure through the page to achieve the addition, change, and removal of business rules, realize the centralized management of business rules, reduce the development threshold of business rules, and effectively solve the system maintainability problems, R & D efficiency problems, and R & D cost problems caused by the changeable rules in the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The following further describes the present invention in detail with reference to the drawings and specific embodiments:

[0026] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art.

[0027] Figure 1 It is the engine structure diagram of a method for constructing a visual business rule engine based on a scripting language provided by the first embodiment of the present invention;

[0028] Figure 2 It is the flowchart of the scheduling algorithm execution of a method for constructing a visual business rule engine based on a scripting language provided by the second embodiment of the present invention;

[0029] Figure 3 It is the conversion example diagram of the binary decision tree and the decision scheme of a method for constructing a visual decision-making engine provided by the third embodiment of the present invention;

[0030] Figure 4 It is a schematic diagram of the execution of the rule solution after the optimization scheme matching step provided by the fourth embodiment of the present invention. Detailed implementation manners

[0031] To make the features and advantages of this patent more obvious and understandable, the following specific embodiments are given and described in detail as follows:

[0032] It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs.

[0033] It should be noted that the terms used herein are only for describing specific implementation manners and are not intended to limit the exemplary embodiments according to the present application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0034] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0035] The inventive concept of the present invention is: based on script language and metadata modeling, combined with a specific business scenario rule execution scheme algorithm and script extension ability, expose a unified rule solution execution interface for the business side to call, realize the visual registration, orchestration and configuration of specific business scenario rules, and also realize the separation of business rules and business processes and the centralized management of rules.

[0036] Please refer to Figure 1 As shown, a method for constructing a visual business rule engine based on a script language provided by the first implementation case of the present invention includes the following steps:

[0037] Step S1.1: Business system metadata modeling, define entity tables and attribute tables to register system metadata, and two tables can meet the following requirements. Example data is shown in Table 1 as entity example data and Table 2 as entity attribute data:

[0038] Entity ID Entity Java Class Name Entity Name 10001 StaffEntity Employee Entity 10002 WorkSheetEntity Work Order Entity

[0039] Table 1 Example data of metadata entities

[0040]

[0041] Table 2 Example Data of Metadata Entity Attributes

[0042] Step S1.2: Development and implementation of the rule script execution engine. The script execution engine consists of several script executors and an optional script extension capability module, and supports the parsing and execution of script languages including but not limited to groovy and SQL;

[0043] Step S1.3: Development and implementation of the algorithm for the rule execution plan in specific business scenarios. The algorithm for the rule execution plan should include basic logics such as the arrangement of the rule execution order, input and output processing of the plan, rules, and scripts. Figure 1 The work order scheduling algorithm and the scheme execution decision algorithm are listed;

[0044] Step S1.4: Visual registration of rules in specific business scenarios, including configuring the basic information of the rules, rule scripts, and rule parameters. A rule can be reused by multiple execution plans. The data included in a rule includes the basic information shown in Table 3, the rule scripts shown in Table 4, and the rule parameters shown in Table 5, etc.:

[0045] Rule Basic Information Attribute Sample Data Rule ID 30001 Rule Name Filter Employees by Region Code Rule Solution Type Work Order Scheduling Solution Rule Output Type Employee List Rule Description Find Employees by Region of Affiliation

[0046] Table 3 Example Data of Rule Basic Information

[0047]

[0048]

[0049] Table 4 Example Data of Rule Scripts

[0050] Explanation of the example data of rule scripts: Script 2001 is an SQL script, and its function is to find employees in a specific area from the employee table; Script 20002 is a groovy script, and its function is to process the SQL query result of Script 20001. If the result is empty, the error message will be put into the errorMsg attribute of resultMap, otherwise the result will be stored in the result array of resultMap; The information in resultMap will be processed in the rule scheme algorithm logic.

[0051] Script ID Solution ID Parameter Name 60001 30001 areaCode

[0052] Table 5 Example Data of Rule Parameters

[0053] Explanation of the example data of rule parameters: Since rule script 20001 references a region code parameter (areaCode), this parameter needs to be registered in the rule parameters.

[0054] The rule can be understood as a programming language function. The rule script is the function body code, the rule parameters are the formal parameters of the function, and the function return results are all placed in the resultMap.

[0055] Step S1.5: Visual registration of the execution plan for specific business scenario rules, including the orchestration of rules and the registration of plan elements. An execution plan can be reused by multiple refined business scenarios. The data included in a rule plan are the basic information as shown in Table 6, the plan rules as shown in Table 7, the plan elements as shown in Table 8, etc.:

[0056] Solution Basic Information Attribute Sample Data Solution ID 60001 Solution Name Dispatch by Region Package Solution Type Work Order Scheduling Solution Solution Output Type Employee Solution Description Assign Work Orders to Employees Based on Region of Work Order

[0057] Example data of the basic information of the plan in Table 6

[0058] Relationship ID Solution ID Rule ID 70001 60001 30001 70002 60001 30002 70003 60001 30003 70004 60001 30004

[0059] Example data of the plan rules in Table 7

[0060] Element ID Solution ID Rule Parameter ID Attribute ID 80001 60001 30001 20005 80002 60001 30002 20006 80003 60001 30003 20007 80004 60001 30004 20008

[0061] Example data of the plan elements in Table 8

[0062] Step S1.6: Business orchestration configuration of the execution plan for specific business scenario rules, that is, the binding of the relationship between the refined business scenario and the execution plan for rules under a specific business scenario. The example data is shown in Table 9:

[0063] Configuration ID Region Code Business Type Solution ID 90001 591 B0001 60001 90002 592 B0001 60002 90003 593 B0001 60003 90004 594 B0001 60004

[0064] Example data of the business orchestration configuration of the plan in Table 9

[0065] Step S1.7: Expose the execution interface of the rule plan for the business system to call, and expose the plan parameter query interface for business developers to query the rule parameters required to execute a certain rule plan.

[0066] Rule plan parameter query interface: The rule parameters required for a certain rule plan are composed of the matching attributes in the business orchestration configuration table and the attributes referenced by the plan elements. For example, according to the relationship of the example data in Table 9, Table 8 and Table 2 above, the parameters required for its execution can be queried based on the plan ID. For example, the parameters required for plan 60001 and its parameter structure are:

[0067]

[0068]

[0069] The matching attributes areaCode of the region and bizType of the business type are fixed, and the attributes referenced by the plan elements are dynamic. All are placed in a two-dimensional Map named rulePramas with the entity name and attribute name as the key names.

[0070] Rule scheme execution interface: After obtaining the parameters required for scheme execution through the parameter query interface, the parameter input for the execution interface organized by the business system is as follows:

[0071]

[0072] When the scheme is executed, first match scheme 60001 according to the region code 591 and business type B0001, and then pass rulePramas to the script execution engine to execute the algorithms and rules of scheme 60001, and return the result to the business system.

[0073] As a further optimization of the above scheme, step S1.2 includes the following steps:

[0074] Step S2.1: Development and implementation of the extended ability of the specific business scenario rule script. When the basic ability of the native script cannot meet the business requirements, the extended ability can be developed for the rule script to call. That is, add a script extension ability module to the script execution engine. The script extension ability is an interface method implemented in business system programming languages such as Java (for Groovy scripts to call), or a database stored procedure (for SQL scripts to call);

[0075] For example, if the rule needs to obtain the current longitude and latitude of an employee, which requires interaction with other system modules and is difficult to implement in the script language, an extended ability to obtain the current longitude and latitude of the employee needs to be developed for the Groovy script to call.

[0076] Java interface: public Map<String,Double>getStaffLocation(Long staffId);

[0077] After registering the above interface service with the Groovy script executor, the rule script can call this extended ability. The sample script code for the call is as follows:

[0078] var location=getStaffLocation(staffId);

[0079] Please refer to Figure 2 , a method for constructing a visual business rule engine based on a script language provided by the second embodiment of the present invention. Based on the above first embodiment, the "specific business scenario" described in steps S1.3 to S1.6 and step S2.1 refers to work order scheduling. The work order scheduling rule execution scheme, abbreviated as the work order scheduling scheme, consists of mandatory rules, preferred rules, and scoring rules; the execution scheme algorithm described in step S1.3 includes the following steps:

[0080] Step S3.1: Execute the mandatory rules. Each mandatory rule filters out several target scheduling objects (including but not limited to personnel, departments, teams). The results of multiple mandatory rules are combined using the union operation. If the results of all mandatory rules are empty, return failure and end the scheduling.

[0081] Step S3.2: Execute the preferred rules one by one in the order of priority. Each preferred rule further filters and screens the scheduling objects based on the current scheduling results. Once the scheduling results are empty, return failure and end the scheduling.

[0082] Step S3.3: First, initialize the score of each scheduling object in the current scheduling results to 0, and then execute the scoring rules. Each scoring rule adds a certain score to each scheduling object in the current scheduling results.

[0083] Step S3.4: Select the scheduling object with the highest score from the current scheduling results as the scheduling scheme result and return it, indicating successful scheduling.

[0084] Please refer to Figure 3 , a method for constructing a visual business decision-making engine provided in the third embodiment of the present invention, based on the above first embodiment, where the "specific business scenario" described in steps S1.3 to S1.6 and step S2.1 refers to business decision-making. The execution scheme algorithm described in step S1.3 is a binary decision tree, where the root node and internal nodes are conditional expressions, and the leaf nodes are decision selection targets. The expressions of the root node or internal nodes can be registered as decision rules, with the output type being a boolean value. The entire binary decision tree is registered as a rule scheme, with the output type being a decision selection target.

[0085] Assume that in a specific work order scheduling scenario, it is necessary to select a work order scheduling scheme based on three conditions: whether the product type is a broadband service, whether the place of attribution is provincial, and whether the customer level is greater than 3. Figure 3 Shows the conversion method from a binary decision tree to a decision-making scheme;

[0086] It is possible to Figure 3 The expressions of the root node or internal nodes in the binary decision tree in

[0087] Rule ID Rule Name Solution Type Output Type Description 30005 Decision Rule 1 Decision Solution Boolean Value Is it a Broadband Service 30006 Decision Rule 2 Decision Solution Boolean Value Is the Place of Attribution Provincial 30007 Decision Rule 3 Decision Solution Boolean Value Is the Customer Level Greater than 3

[0088] Table 10 Example data of decision rules

[0089] A decision rule can be reused by multiple decision-making schemes.

[0090] When registering a decision-making scheme, the process of arranging decision rules is the process of assembling a binary decision selection tree. Assume that Figure 3 the ID of decision-making scheme 1 in

[0091]

[0092] Table 11 Example Data of the Relationship between Decision-making Schemes and Decision-making Rules

[0093] Please refer to Figure 4 , as an optimization of the first or second embodiment above, in the fourth embodiment of the present invention, the service orchestration configuration in step S1.6 may be a rule execution scheme that directly matches a specific service scenario according to specific service attributes, and a visual service decision engine described in the third embodiment is used to match the target rule scheme.

[0094] The service orchestration configuration data of the scheme needs to expand Table 9 into Table 12 shown below

[0095]

[0096]

[0097] Table 12 Example Data of the Relationship between Decision-making Schemes and Decision-making Rules

[0098] Matters not covered by the present invention are well-known technologies.

[0099] The above embodiments are only used to illustrate the technical concept and features of the present invention, and their purpose is to enable those familiar with this technology to understand the content of the present invention and implement it accordingly, and cannot be used to limit the protection scope of the present invention. Any equivalent changes or modifications made according to the spirit and essence of the present invention should be covered within the protection scope of the present invention.

[0100] This patent is not limited to the above best implementation mode. Anyone can obtain other various forms of construction methods of visual service rule engines based on scripting languages under the inspiration of this patent. Any equivalent changes and modifications made according to the scope of the patent application of the present invention should fall within the scope covered by this patent.

Claims

1. A method for constructing a visual business rule engine based on a scripting language, characterized in that, It includes the following steps: Step S1.1: Conduct metadata modeling for the business system, and define entity tables and attribute tables to register system metadata; Step S1.2: Develop and implement a rule script execution engine, and the script executor supports parsing and execution of at least groovy and SQL script languages; Step S1.3: Develop and implement an algorithm for the rule execution solution in a specific business scenario. The rule execution sequence arrangement, and the basic logic of input and output processing of the solution, rules, and scripts are included in the rule execution solution algorithm: The execution solution algorithm includes the following steps: Step S3.1: Execute mandatory rules. Each mandatory rule filters out several target scheduling objects, and the results of multiple mandatory rules are taken as the union. If the results of all mandatory rules are empty, return failure and end the scheduling; Step S3.2: Execute preferred rules one by one in the order of priority. Each preferred rule further filters and screens scheduling objects based on the current scheduling result. Once the scheduling result is empty, return failure and end the scheduling; Step S3.3: First, initialize the score of each scheduling object in the current scheduling result to 0, and then execute the scoring rules. Each scoring rule adds a set score to each scheduling object in the current scheduling result; Step S3.4: Select the scheduling object with the highest score from the current scheduling result as the scheduling solution result and return it, and the scheduling is successful; Step S1.4: Visual registration of rules in a specific business scenario, including configuring basic information of the rules, rule scripts, and rule parameters. One rule allows to be reused by multiple execution solutions; Step S1.5: Visual registration of the rule execution solution in a specific business scenario, including the arrangement of rules and the registration of solution elements. One execution solution allows to be reused by multiple refined business scenarios; Step S1.6: Business arrangement configuration of the rule execution solution in a specific business scenario, that is, binding the association relationship between the refined business scenario and the rule execution solution in a specific business scenario; Step S1.7: Expose the execution interface of the rule solution for the business system to call, and expose the solution parameter query interface for business developers to query the rule parameters required to execute a certain rule solution.

2. The method for constructing a visual business rule engine based on a scripting language according to claim 1, characterized in that: In step S1.2, the development and implementation of the rule script extension ability in a specific business scenario is to develop an extension ability for the rule script to call when the basic native script ability cannot meet the business requirements.

3. The method for constructing a visual business rule engine based on a scripting language according to claim 1, characterized in that: The specific business scenario refers to a work order scheduling solution, which consists of mandatory rules, preferred rules, and scoring rules.

4. The method for constructing a visual business rule engine based on a scripting language according to claim 1, characterized in that: The specific business scenario refers to business decision-making; in step S1.3, the execution solution algorithm is a binary decision tree, where the root node and internal nodes are conditional expressions, and the leaf nodes are decision selection targets. Register the expressions of the root node or internal nodes as decision rules, with the output type being a boolean value, and register the entire binary decision tree as a rule solution, with the output type being a decision selection target, thereby forming a visual business decision-making engine.

5. The method for constructing a visual business rule engine based on a scripting language according to claim 4, characterized in that: The business arrangement configuration in step S1.6 is: directly match the rule execution solution of a specific business scenario according to specific business attributes, or use the decision-making engine to match the target rule execution solution.

Images