A business decision processing method and its rule engine system

Abstract

This invention discloses a business decision-making processing method and its rule engine system, belonging to the fields of cloud computing and the Internet of Things. The business decision-making processing method includes event preparation, node parsing, event evaluation, rule traversal, and conflict resolution. The rule engine system comprises six units: visual configuration, user permission management, rule set management, decision scoring card, decision analysis, and version management. This invention addresses the problems of inefficient decision-making caused by non-standard business decision-making processes, inaccurate business decision analysis, and suboptimal final results in current market applications. The rule engine system separates business decisions from application code and uses predefined semantic modules to write business decisions. Once the rules take effect and trigger runtime, user business decisions are processed. Furthermore, the rule engine system can be dynamically managed and modified at runtime, thus providing effective technical support for enterprises to maintain flexibility and competitiveness.

Description

Technical Field

[0001] This invention belongs to the fields of cloud computing and the Internet of Things, and specifically relates to a business decision processing method and its rule engine system. Background Technology

[0002] A rules engine system is a component embedded in an application that separates business decisions from application code and uses predefined semantic modules to write business decisions; it accepts data input, interprets business rules, and makes business decisions based on those rules.

[0003] With the widespread application of modern information technology, enterprises are increasingly demanding higher standards for work quality and efficiency, leading to a greater need for advanced technologies in business data processing and collaborative workflows. However, many enterprises still rely heavily on manual processing in their daily operations, particularly for key business data. This often involves multiple business departments and requires collaborative and standardized processing. Manual processing of business data has many drawbacks, resulting in low efficiency and quality.

[0004] To improve the efficiency and quality of business data processing and collaborative work, the mainstream solution currently on the market is to introduce workflow-based applications. These applications consist of a series of functional modules, with the sequence of business tasks directly hard-coded into the business function code. In this way, the business process is directly embedded within the business function modules. Thus, the business process is implemented through the workflow system; that is, the business process combines with the business function modules through a dedicated data interface. This achieves data interaction between the business process and the business function modules, avoiding duplicate data input and ensuring the consistency of business data.

[0005] While the solutions mentioned above address the shortcomings of manual data processing to some extent, none of them solve the problem of integrating flexible and rapid data processing with business process applications, resulting in limited application flexibility. Therefore, any changes to business processes necessitate secondary development and product redesign. In today's rapidly changing market, where business process adjustments are frequent, this can significantly impact normal business operations.

[0006] Currently, existing technologies typically employ manual, rational decision-making methods when facing business decisions. This approach lacks a complete and standardized decision-making process. The rational decision-making model is merely an idealized approach; it doesn't reflect real-world decision-making situations and cannot produce objectively correct conclusions. According to this model, decision-makers must gather all relevant information before making a decision, but in reality, it's impossible for them to possess all the information. Therefore, completely rational decision-making is unattainable. Secondly, decision-makers' information processing capabilities are also limited. Due to various subjective and objective limitations, they cannot perfectly analyze and process all relevant information, thus making a 100% optimal decision impossible.

[0007] Human rational decision-making is influenced by both specific objective conditions and the decision-maker's subjective conditions. Relying solely on subjective human decision-making cannot cope with complex environments, and under excessive pressure, the decision outcome may deviate from reality.

[0008] As businesses develop, they continuously add new business functional modules, such as production processes and material handling. These new modules need to be integrated with the existing business processes. However, existing interfaces can only function on the original modules; for new modules, interfaces need to be redeveloped or modified. This inevitably affects the company's normal business management. In short, how to conveniently and flexibly integrate business processes and business data processing, and how to improve conversion efficiency when frequently adjusting the correspondence between business processes and functional modules, have become urgent problems that need to be solved. Specifically, these problems manifest in the following ways:

[0009] 1. Different business rules are heavily coupled with the system, making it difficult for relevant personnel to handle business rules and impossible to manage them uniformly;

[0010] 2. When expanding and maintaining business rules, it is necessary to shut down the system for updates and restart the service, resulting in low maintenance and update efficiency;

[0011] 3. Frequent changes to business rules are too costly, too risky, and prone to problems.

[0012] 4. The technical implementation rules are too complex, and business personnel can only be limited to the functions of the business rules and cannot participate in editing and maintaining the code;

[0013] 5. The lack of standardized business decision-making processes leads to low decision-making efficiency.

[0014] 6. Inaccurate business decision analysis leads to a final result that is not the optimal solution. Summary of the Invention

[0015] To address the shortcomings of existing business decision-making methods and rule engine systems, which fail to effectively integrate flexible and rapid business data processing with business process applications, resulting in low efficiency, this invention provides a business decision-making method and its rule engine system. The method employs standardized steps including event preparation, node parsing, event evaluation, rule traversal, and conflict resolution. This solves the problems of inefficient decision-making caused by non-standard business decision processes, inaccurate business decision analysis, and suboptimal final results in current market offerings. The rule engine separates business decisions from application code and uses predefined semantic modules to write these decisions. The application triggers the rule engine by submitting data or objects, which then invokes the corresponding rules and triggers the appropriate operations. Typically, a rule contains a set of rule conditions and the operations to be performed under those conditions. The rule engine will trigger all operations under a rule only if all rule conditions match successfully. Once a rule takes effect and is triggered, user business decisions are processed. Furthermore, the rule engine system can be dynamically managed and modified during runtime, providing effective technical support for enterprises to maintain flexibility and competitiveness. The specific technical solution is as follows:

[0016] A business decision processing method includes the following steps:

[0017] S1, Event Preparation:

[0018] First, the created rule file is parsed. While parsing the rule file, the node relationships are loaded synchronously. The event nodes are transmitted to the broadcast list, the kieSession processing method is called, and the core of the rule engine is entered, triggering all the rules loaded in the session.

[0019] S2, Node Analysis:

[0020] The OTN control node broadcasts all events in the list downstream, following the user-defined message passing rules. All downstream branches of the OTN will be traversed and visited.

[0021] a. When all branches are first-level event nodes, the event is directly propagated to the event terminal node;

[0022] b. When the event flows to the left input adapter node, the event is stored in the memory corresponding to the left input adapter node;

[0023] c. When an event flows to the right side of a secondary node, store the event on the right side of the secondary node.

[0024] d. When a branch reaches a secondary event terminal node, a rule dynamic recognizer is constructed and inserted into the internal agent logic group, indicating that the current rule needs to proceed to the next stage and enter the backup evaluation node. The logic of the backup evaluation secondary node is to insert into the internal agent logic group when all branch entries have stored data.

[0025] S3, Event Assessment:

[0026] First, determine whether the event is a branch of a first-level node. If the event is a branch of a first-level node, no event evaluation is performed; if the event is not a branch of a first-level node, event evaluation is performed.

[0027] After an event enters the evaluation node, it is matched based on the left and right memory, finds all successfully matched data and puts them into a set, and then carries this set into the next node, which is a secondary node or a terminal node.

[0028] When the next node is a second-level node, the matching continues, and the successfully matched set is carried over to the next node;

[0029] When the next node is a terminal node, the data is inserted into the tuple list of the rule executor; the tuple list stores the relevant data representatives, and the data is actually substituted into the rule execution for parsing; similarly, the event terminal automatically saves a copy of the rule data in memory;

[0030] Second-level nodes also have additional processing rules. When performing left and right pairing, they do not simply traverse and search, but, if conditions permit, Drools creates an index when storing this data. The specific index implementation is that Drools implements a HashMap structure to manage the index.

[0031] S4, rule traversal:

[0032] After the event evaluation is completed, the rule traversal phase begins, which executes the rules by traversing the tuple list of the rule executor. The rule file is compiled into bytecode and executed dynamically at the Drools runtime. By default, one rule is enabled during the rule traversal phase. The default rule file internally calls the insertmodify function, and the event is also inserted into the broadcast list. The tuple list is refreshed again internally. The entire rule traversal method is a loop. When the passed-in event matches a rule, the event evaluation and backup will continue to be executed after the rule traversal is completed, until all rules are triggered, to ensure that no conditional rules are missing.

[0033] S5, Conflict Resolution:

[0034] After rule traversal, the regular events have been executed; however, when multiple parallel events are executed simultaneously, event conflicts will occur, which are handled using conflict resolution nodes; when the rules to be executed are known, the order in which these rules are executed is determined.

[0035] The conflict resolution part is implemented using Drools. The rule recognizer is inserted into the internal agent group, and a binary heap queue is used to store elements. The binary heap algorithm ensures that the highest priority rule is popped from the queue each time. The priority is calculated by PhreakConflictResolver. PhreakConflictResolver determines the priority from two aspects: first, whether the rule declares salience, the larger the salience, the higher the priority; second, when it cannot be calculated by salience, the priority is determined by the rule's loadOrder, the earlier the rule is in the file, the higher the loadOrder.

[0036] A business decision processing rule engine system comprises six units: visual configuration, user permission management, rule set management, decision scoring card, decision analysis, and version management. Visual configuration includes two modules: rule flow construction and rule flow publishing. User permission management includes two modules: flow permission management and control permission management. Rule set management includes two modules: wizard-style rule sets and script-based rule sets. Decision scoring card includes two modules: two-dimensional scoring card and complex scoring card. Decision analysis includes two modules: decision table and decision tree. Version management includes two modules: version control and version rollback.

[0037] In the above technical solution, the rule process construction module directly realizes the visual configuration of tree structure rules by dragging and dropping controls and connecting them. It supports complex logic nesting, condition groups and knowledge loop conditions, and supports the selection of data indicators. While reducing the user's threshold for use, it greatly improves the user's work efficiency.

[0038] In the above technical solution, the rule process publishing module is used to publish the rule process after it is built, to monitor the current process and check whether the current process conforms to the logical specifications; if there are problems in the current process, the problematic flow or control will be highlighted and the specific error information will be reported to facilitate user modification; if there are no more errors in the process, the publishing is successful and the process will switch to the running state.

[0039] In the above technical solution, the rule engine system is equipped with a process permission management module for different users; during the process of publishing the rule process, the process permission management module selects the personnel who are authorized to view and use the process, or sets the editable permissions of the rule process for designated personnel.

[0040] In the above technical solution, the control permission management module can not only control the permissions of the entire process, but also refine the permissions to the control granularity, so as to distinguish the permission scope of different business personnel.

[0041] In the above technical solution, the wizard-style rule set module consists of a series of individual ordinary rules and cyclic rules. The designer of the wizard-style rule set module adopts a full wizard mode, which can complete the rule configuration.

[0042] In the above technical solution, the script-based rule set module defines ordinary rules and loop rules by writing YAML scripts, and then converts them into rule flow; the YAML scripts are written in the script-based rule designer.

[0043] In the above technical solution, the two-dimensional scorecard module uses a two-dimensional table to display the various attributes of the target object, sets different conditions for different attributes, and each condition corresponds to a different score, thereby realizing the score calculation of the target object.

[0044] In the above technical solution, the complex scorecard module is a scorecard provided by URulePro that can perform conditional judgment on multiple object attributes, thereby realizing more complex scoring functions.

[0045] In the above technical solution, the decision table module adopts a fully visual and graphical operation mode, which can quickly define a decision table that matches the business, making it convenient for users to directly conduct decision analysis.

[0046] In the above technical solution, the decision tree module uses a horizontal tree structure to represent and construct rules, which can more vividly represent business rules. By comparing the decision tree structure with the decision table, the advantages and disadvantages of the decision results can be analyzed more intuitively, helping users to make final decisions more quickly.

[0047] In the above technical solution, when the rule engine system modifies and republishes a rule process, the version control module records a version for each publication and stores it in the version list. Users can view any historical version in the version list at any time and enter the process details to view the detailed configuration of the process at that time. However, rule processes with errors will not be saved in the historical versions, and rule processes that have not been successfully published will not appear in the historical versions.

[0048] In the above technical solution, when a problem occurs during the release of the latest version, the version rollback module is used to roll back the latest version to the previous stable version or any selected historical version to ensure service operation, allow sufficient time to investigate and fix the problem, and release a new version after successful repair, or set the selected historical version as the current latest version.

[0049] The business decision processing method and rule engine system of the present invention have the following advantages compared with the prior art:

[0050] I. The method of this invention adopts a standardized business decision-making process involving event preparation, node parsing, event evaluation, rule traversal, and conflict resolution. This addresses the problems of inefficient decision-making caused by non-standardized business decision-making processes, inaccurate business decision analysis, and suboptimal final results in current market offerings. It achieves accurate business decision analysis, optimal final results, and high decision-making efficiency.

[0051] Second, this invention employs process permission management tailored to different users. During the rule / process publishing process, this management selects authorized personnel to view and use the process, or sets editable permissions for designated personnel. Furthermore, it utilizes control-based permission management to control permissions across the entire process, refining permissions to the control level to clearly distinguish the permission scope of different business personnel. This solves the problem of severe coupling between different business rules and the system, making it difficult for relevant personnel to handle business rules and hindering unified management. It achieves the effect of all controls being centrally managed by the system administrator, who does not need to understand the implementation details of the controls but only needs to be familiar with their functions to operate them, simplifying the handling of business rules. Simultaneously, it can also divide the visible controls for different business personnel using permission control, fully decoupling different business processes and improving efficiency.

[0052] III. When a rule process is modified and republished, this invention employs version control, recording each publication as a separate version stored in a version list. Users can view any historical version in the list at any time and access the process details to see the detailed configuration of the current version. However, erroneous rule processes are not saved in historical versions, and rule processes that failed to publish will not appear in historical versions. This solves the problem of low maintenance efficiency caused by the need for system shutdown and service restarts when expanding and maintaining business rules. It allows for direct publishing after update completion, creating a new version number upon publication, eliminating the need for system shutdown and achieving high maintenance efficiency.

[0053] IV. When problems arise during the release of the latest version, this invention employs version rollback to revert the latest version to the previous stable version or any selected historical version. This ensures service operation, allows sufficient time for troubleshooting and fixing the problem, and allows for the release of a new version only after successful repair. Alternatively, the selected historical version can be prioritized as the current latest version. This resolves the issues of high costs, excessive risks, and potential errors caused by frequent changes to business rules, and reduces losses resulting from version release problems.

[0054] V. This invention employs a rule-based workflow construction method, enabling direct drag-and-drop control configuration for a visually configurable tree-structured rule system. It supports complex logic nesting, condition groups, and knowledge loop conditions, and allows selection of data metrics. This significantly improves user efficiency while lowering the barrier to entry. Furthermore, the rule-based workflow publishing function is used to publish the completed workflow, monitoring its compliance with logical standards. If issues are found, problematic flows or controls are highlighted with specific error messages for easy modification. Once errors are resolved, the workflow is successfully published and enters a running state. In summary, visual configuration solves the problem of overly complex technical implementation rules limiting business personnel to the functionality of business rules, preventing them from participating in code editing and maintenance. It allows anyone familiar with the business to easily learn and use the system, participating in code editing and maintenance.

[0055] VI. The conflict resolution steps and improved conflict resolution mechanism of the method of the present invention, combined with the multi-dimensional scoring card system in the rule engine system, are used for comprehensive analysis, which successfully solves the problem of inaccurate business decision analysis and the final result not being the optimal solution.

[0056] In summary, the method of this invention addresses the problems of low decision-making efficiency caused by non-standard business decision-making processes, inaccurate business decision analysis, and suboptimal final results in current market applications. The rule engine separates business decisions from application code and uses predefined semantic modules to write these decisions. The application triggers the rule engine by submitting data or objects, which then invokes the corresponding rules and triggers the appropriate operations. Typically, a rule contains a set of rule conditions and the operations to be performed under those conditions. The rule engine will trigger all operations under this rule only if all rule conditions match successfully. Once the rule takes effect and is triggered, user business decisions are processed. Furthermore, the rule engine system can be dynamically managed and modified during runtime, providing effective technical support for enterprises to maintain flexibility and competitiveness. Attached Figure Description

[0057] Figure 1 This is a system architecture diagram of a business decision processing rule engine according to an embodiment of the present invention. Detailed Implementation

[0058] The following are specific implementation cases and appendices. Figure 1 The present invention will be further described, but the present invention is not limited to these embodiments.

[0059] The business decision processing method and rule engine system in this embodiment are applied to the business decision processing of a certain enterprise.

[0060] Example 1

[0061] A business decision processing method includes the following steps:

[0062] S1, Event Preparation:

[0063] First, the created rule file is parsed. While parsing the rule file, the node relationships are loaded synchronously. The event nodes are transmitted to the broadcast list, the kieSession processing method is called, and the core of the rule engine is entered, triggering all the rules loaded in the session.

[0064] S2, Node Analysis:

[0065] The OTN control node broadcasts all events in the list downstream, following the user-defined message passing rules. All downstream branches of the OTN will be traversed and visited.

[0066] a. When all branches are first-level event nodes, the event is directly propagated to the event terminal node;

[0067] b. When the event flows to the left input adapter node, the event is stored in the memory corresponding to the left input adapter node;

[0068] c. When an event flows to the right side of a secondary node, store the event on the right side of the secondary node.

[0069] d. When a branch reaches a secondary event terminal node, a rule dynamic recognizer is constructed and inserted into the internal agent logic group, indicating that the current rule needs to proceed to the next stage and enter the backup evaluation node. The logic of the backup evaluation secondary node is to insert into the internal agent logic group when all branch entries have stored data.

[0070] S3, Event Assessment:

[0071] First, determine whether the event is a branch of a first-level node. If the event is a branch of a first-level node, no event evaluation is performed; if the event is not a branch of a first-level node, event evaluation is performed.

[0072] After an event enters the evaluation node, it is matched based on the left and right memory, finds all successfully matched data and puts them into a set, and then carries this set into the next node, which is a secondary node or a terminal node.

[0073] When the next node is a second-level node, the matching continues, and the successfully matched set is carried over to the next node;

[0074] When the next node is a terminal node, the data is inserted into the tuple list of the rule executor; the tuple list stores the relevant data representatives, and the data is actually substituted into the rule execution for parsing; similarly, the event terminal automatically saves a copy of the rule data in memory;

[0075] Second-level nodes also have additional processing rules. When performing left and right pairing, they do not simply traverse and search, but, if conditions permit, Drools creates an index when storing this data. The specific index implementation is that Drools implements a HashMap structure to manage the index.

[0076] S4, rule traversal:

[0077] After the event evaluation is completed, the rule traversal phase begins, which executes the rules by traversing the tuple list of the rule executor. The rule file is compiled into bytecode and executed dynamically at the Drools runtime. By default, one rule is enabled during the rule traversal phase. The default rule file internally calls the insertmodify function, and the event is also inserted into the broadcast list. The tuple list is refreshed again internally. The entire rule traversal method is a loop. When the passed-in event matches a rule, the event evaluation and backup will continue to be executed after the rule traversal is completed, until all rules are triggered, to ensure that no conditional rules are missing.

[0078] S5, Conflict Resolution:

[0079] After rule traversal, the regular events have been executed; however, when multiple parallel events are executed simultaneously, event conflicts will occur, which are handled using conflict resolution nodes; when the rules to be executed are known, the order in which these rules are executed is determined.

[0080] The conflict resolution part is implemented using Drools. The rule recognizer is inserted into the internal agent group, and a binary heap queue is used to store elements. The binary heap algorithm ensures that the highest priority rule is popped from the queue each time. The priority is calculated by PhreakConflictResolver. PhreakConflictResolver determines the priority from two aspects: first, whether the rule declares salience, the larger the salience, the higher the priority; second, when it cannot be calculated by salience, the priority is determined by the rule's loadOrder, the earlier the rule is in the file, the higher the loadOrder.

[0081] A business decision processing rule engine system, comprising six units: visual configuration, user permission management, rule set management, decision scoring card, decision analysis, and version management;

[0082] 1. Visual configuration includes two modules: rule and process construction and rule and process publication.

[0083] 1.1 The rule and process construction module enables direct visualization configuration of tree-structured rules by dragging and dropping controls and connecting them. It supports complex logic nesting, condition groups and knowledge loop conditions, and allows selection of data indicators. This reduces the user's learning curve and greatly improves their work efficiency.

[0084] 1.2 The rule and process publishing module is used to publish the rule and process after it has been built. It monitors the current process to ensure it conforms to the logical specifications. If there are problems with the current process, the problematic flow or control will be highlighted and the specific error information will be reported to facilitate user modification. If there are no more errors in the process, the publishing is successful and the process will switch to the running state.

[0085] 2. User permission management includes two modules: process permission management and control permission management.

[0086] 2.1 The rule engine system is equipped with a process permission management module for different users; during the process of publishing rules and processes, the process permission management module selects the personnel who are authorized to view and use the process, or sets the editable permissions of the rules and processes for designated personnel.

[0087] 2.2 The control permission management module can not only control the permissions of the entire process, but also refine the permissions to the control granularity, so as to distinguish the permission scope of different business personnel.

[0088] 3. Rule set management includes two modules: wizard-style rule sets and script-based rule sets.

[0089] 3.1 The wizard-style rule set module consists of a series of individual ordinary rules and cyclic rules. The designer of the wizard-style rule set module adopts a full wizard mode and can complete the rule configuration.

[0090] 3.2 The script-based rule set module uses YAML scripts to define ordinary rules and loop rules, which are then converted into rule flows. The YAML scripts are written in the script-based rule designer. The script-based rule designer provides comprehensive code hints and syntax checking, making rule script writing more convenient.

[0091] 4. The decision scoring card includes two modules: a two-dimensional scoring card and a complex scoring card. A decision scoring card is a numerical representation of an individual's or organization's relevant information after analysis. It indicates the likelihood of loss due to non-payment behavior in credit activities. Scoring is typically used for risk management and assessment of individuals or organizations. The scoring card in the rule engine system is used to calculate the score. Different conditions are set for different attributes, and each condition corresponds to a different score. At runtime, the engine automatically calculates the score of the target object based on the defined condition segments.

[0092] 4.1 The two-dimensional scorecard module uses a two-dimensional table to display the various attributes of the target object. Different conditions are set for different attributes, and each condition corresponds to a different score, so as to realize the score calculation of the target object.

[0093] 4.2 The Complex Scoring Card module is a scoring card provided in URulePro that can perform conditional judgments on multiple object attributes, enabling more complex scoring functions.

[0094] 5. The decision analysis module is typically used for decision-making. It combines the final score obtained from the scorecard with specific methods to identify and evaluate factors, risks, and possible outcomes in order to achieve the best decision. The graphical representation of the decision is usually formally presented to decision-makers and stakeholders along with the prescribed action plan. Decision analysis includes two modules: decision table and decision tree.

[0095] 5.1 The decision table module adopts a fully visual and graphical operation method, which can quickly define decision tables that match the business, making it convenient for users to directly conduct decision analysis.

[0096] 5.2 The decision tree module uses a horizontal tree structure to represent and build rules, which can more vividly represent business rules. By comparing the decision tree structure with the decision table, the advantages and disadvantages of the decision results can be analyzed more intuitively, helping users to make final decisions more quickly.

[0097] 6. Version management includes two modules: version control and version rollback. This module solves the problem of low efficiency caused by the need for system downtime and service restarts when expanding and maintaining business rules. After the rule process is published, it is created in the cloud, separate from the local process. When business updates occur, the local process can be modified directly. After the update is complete, it can be published directly, and a new version number will be created after publication, without the need for system downtime and service restarts.

[0098] 6.1 When a rule process is modified and republished, the version control module records a version for each publication and stores it in the version list. Users can view any historical version in the version list at any time and enter the process details to view the detailed configuration of the process at that time. However, rule processes with errors will not be saved in the historical versions, and rule processes that have not been successfully published will not appear in the historical versions.

[0099] 6.2 When a problem occurs during the release of the latest version, the version rollback module is used to roll back the latest version to the previous stable version or any selected historical version to ensure service operation, allow sufficient time to investigate and fix the problem, and release a new version after successful repair, or set the selected historical version as the current latest version.

[0100] The rule engine in this embodiment accepts data input, interprets business rules, and executes corresponding business logic based on the rules. A business rule contains a set of conditions and the operations to be performed under these conditions. We set one or more conditions in the business logic, and when these conditions are met, the corresponding operations are triggered. The original intention of the rule engine design is to liberate complex and ever-changing rules from hard coding, storing them in the form of rule scripts in files or databases, so that rule changes can be used without modifying the code, achieving maximum flexibility.

[0101] During the rule definition phase, corresponding rules are defined based on business requirements, and these rules are described using a rule language. Multiple rules can form a rule set. The execution of the rule engine begins by loading this rule set and parsing the rules. Simultaneously, the rule reasoning engine executes these parsed rules onto the specific input data objects.

[0102] When the engine executes, it executes rule execution instances one by one according to the priority order in the rule execution queue. Since the execution of a rule may modify data objects in the workspace, some rule execution instances in the queue may become invalid due to changed conditions and must be removed from the queue. Conversely, rules that previously did not meet the conditions may be activated, generating new rule execution instances that enter the queue. This creates a "dynamic" rule execution chain, forming the rule reasoning mechanism. This "chain reaction" of rules is entirely driven by the data in the workspace.

[0103] This rule engine adopts a logic-based programming approach. Business users provide business rules, and developers are responsible for organizing and translating these rules into an interpreter-executable configuration file. The interpreter and compiler then parse and execute the file. This allows businesses to focus solely on rule construction, developers to express their logic, and execution to be managed by the interpreter or compiler. When a caller selects a rule model and passes in initialization data, a loader loads the specified model, and the executor uses relevant decision paths to control execution and return rule results, achieving configurability for a portion of the business process.

[0104] The rule engine employs a divide-and-conquer strategy for branch decisions, and the distribution rule module executor uses the divide-and-conquer strategy to implement a depth-first traversal decision tree. The divide-and-conquer strategy works as follows: for a problem of size n, if the problem can be easily solved (e.g., n is small), it is solved directly; otherwise, it is decomposed into k smaller subproblems. These subproblems are independent of each other and have the same form as the original problem. These subproblems are solved recursively, and then the solutions to the subproblems are combined to obtain the solution to the original problem.

[0105] The basic steps of the divide-and-conquer method are as follows: There are three steps at each level of recursion:

[0106] 1. Decomposition: Decompose the original problem into several smaller, independent subproblems that are in the same form as the original problem;

[0107] 2. Solution: If the subproblem is small and easy to solve, solve it directly; otherwise, solve each subproblem recursively.

[0108] 3. Merging: Merge the solutions of each subproblem into the solution of the original problem.

[0109] The rule engine employs a decision tree approach for decision-making. Decision tree machine learning prediction methods are primarily used for classifying discrete data. A value, after being tested at a corresponding node, skips the false branch and enters the true branch. Therefore, after a set of values ​​passes through the decision tree, a unique path is formed from the tree root to the result node. Thus, in addition to classifying the input, it can also provide an explanation for this classification. The algorithm implementation includes: feature selection, training the decision tree to build the decision model, and model prediction on new data.

[0110] The data dimension extraction reference feature selection of the rule engine is also the data field used for if judgment in hard coding; the construction of the decision tree model adopts the experience rules of business personnel in actual work; the input data is used by the model to perform the analogy prediction stage.

[0111] The processing method and engine system in this embodiment have shown good performance. The standardized business decision-making process, which includes event preparation, node parsing, event evaluation, rule traversal, and conflict resolution, achieves accurate business decision analysis, results in the optimal solution, and high decision-making efficiency. In particular, the conflict resolution step in the method, with its comprehensive conflict resolution mechanism, combined with the multi-dimensional scoring card system in the rule engine system, successfully solves the problem of inaccurate business decision analysis and non-optimal final results.

[0112] The system employs workflow permission management tailored to different users, achieving unified management of all controls by the system administrator. Administrators do not need to understand the implementation details of the controls; familiarity with their functions is sufficient for operation, simplifying business rule processing. Furthermore, the visible controls for different business personnel can be divided using permission control, effectively decoupling different business functions and improving efficiency. Version control records each release as a separate version, allowing for immediate release after update completion. A new version number is created after release, eliminating downtime and improving maintenance efficiency. When issues arise with the latest version, version rollback allows reverting to a previous stable version or any selected historical version, ensuring service operation and providing ample time for troubleshooting and fixing. A new version can be released only after successful repair, or the selected historical version can be prioritized as the current latest version, minimizing losses caused by release issues. The rule-based workflow construction allows for direct drag-and-drop control configuration, enabling a visually configurable tree-structured rule system. This allows even users familiar with the business to quickly learn and use the system to edit and maintain code.

Claims

1. A service decision processing method characterized by, Comprising the following steps: S1, event preparation: First, the created rule file is parsed, and the node relationship formula is loaded synchronously during the parsing of the rule file; the event node is transmitted to the broadcast list, and the kieSession processing method is called to enter the core link of the rule engine, triggering all rules loaded in the session; S2, node parsing: The OTN control node sends all events in the broadcast list to the downstream, following the message transmission principle set by the user, and all branches downstream of the OTN are accessed: S3, event evaluation: First, it is judged whether the event is a branch of the first-level node. When the event is a branch of the first-level node, no event evaluation is performed; when the event is not a branch of the first-level node, event evaluation is performed; After the event enters the evaluation node, matching is performed based on the left and right memories, all successfully matched data is found and put into a set, and the set is continuously brought into the next node, which is a second-level node or a terminal node; S4, rule traversal: After the event evaluation is completed, the rule traversal link is entered, and the rule is executed by using the tuple list of the rule executor; the rule file is compiled into bytecode dynamically by Drools runtime, and one rule is enabled by default in the rule traversal stage; the insertmodify function is called internally in the default rule file, and the event is also inserted into the broadcast list, and the tuple list refresh operation is performed again internally; the entire rule traversal method is a loop, and when the transmitted event hits the rule, the event evaluation and backup will continue to be executed after the rule traversal is completed, until all triggers are completed, to ensure that there is no condition rule missing situation; S5, conflict resolution: After the rule traversal, the regular event has been executed; however, when multiple parallel events are executed at the same time, event conflicts will occur, and the conflict resolution node is used for processing; When it is known which rules are to be executed, the order of execution of these rules is determined.

2. The service decision processing method of claim 1, wherein, In S2, the traversal access, a. When all branches are first-level event nodes, the event is directly propagated to the event terminal node; b. When the event flows to the left input adapter node, the event is stored in the memory corresponding to the left input adapter node; c. When the event flows to the right side of the secondary node, the event is stored in the right side of the secondary node; d. When the branch goes to the secondary event terminal node, a rule dynamic recognizer is constructed and inserted into the internal agent logic group, representing that the current rule needs to proceed to the next stage, and enters the backup evaluation node; the logic of the backup evaluation secondary node is that when all branch entrances store data, the internal agent logic group is inserted.

3. The method of claim 1, wherein, In S3, when the next node is a secondary node, matching is continued, and the successfully matched set is brought into the next node; When the next node is a terminal node, the data is inserted into the tuple list of the rule executor; the relevant data stored in the tuple list represents that the data is truly substituted into the rule execution for analysis; similarly, the event terminal automatically saves a copy of the rule data in the memory.

4. The service decision processing method according to claim 1 or 3, characterized by, In S3, the secondary node is also attached with additional processing rules, when pairing left and right, not only traversing, but also indexing the data when storing, the specific implementation of the index is that Drools implements a HashMap structure to manage the index.

5. The method of claim 1, wherein, In S5, the conflict resolution is implemented by Drools, the rule recognizer is inserted into the internal agent group, and a binary heap queue is used to store elements; the binary heap algorithm is used to ensure that the highest priority rule is popped out of the queue each time, and the priority calculation is completed by PhreakConflictResolver; PhreakConflictResolver judges the priority from two aspects: one is whether the rule declares salience, the larger the salience, the higher the priority; the other is when salience cannot be used to calculate, the loadOrder of the rule is used to determine the priority, the earlier the rule is in the file, the higher the loadOrder.

6. A business decision processing rules engine system using the business decision processing method of claim 1, characterized by, The rule engine system includes six units, namely visual configuration, user permission management, rule set management, decision score card, decision analysis and version management.

7. A business decision handling rules engine system according to claim 6, wherein, The visual configuration includes rule flow construction and rule flow publishing modules, the user permission management includes process permission management and control permission management modules, the rule set management includes wizard rule set and script rule set modules, the decision score card includes two-dimensional score card and complex score card modules, the decision analysis includes decision table and decision tree modules, and the version management includes version control and version rollback modules.

8. The business decision processing rule engine system of claim 7, wherein, The rule flow construction module directly realizes tree structure rule visual configuration by directly dragging and connecting controls, supports complex logic nesting, condition groups and knowledge cycle conditions, and supports selecting data indicators, thereby reducing the user usage threshold and greatly improving user work efficiency; The rule flow publishing module is used to publish the rule flow after construction, and to monitor and check whether the current flow meets the logical specification; If there is a problem with the current flow, the problematic flow or control is highlighted and specific error information is reported for user modification; if there is no error in the flow, the publishing is successful and the flow is in a running state; The rule engine system is equipped with a process permission management module for different users; The process permission management module selects personnel authorized to view and use the process during rule flow publishing, or sets the editable permission of the rule flow for specified personnel; The control permission management module not only controls the permission of the entire process, but also refines the permission to the control granularity to distinguish the permission range of different business personnel. The guide rule set module is composed of a series of single common rules and loop rules, and the designer of the guide rule set module can complete rule configuration in a full guide mode; The script rule set module defines common rules and loop rules by writing a yaml script, and then converts the script into a rule flow; the yaml script is written in a script rule designer.

9. The business decision processing rule engine system of claim 7, characterized in that, The two-dimensional score card module uses a two-dimensional table to display each attribute of the target object, sets different conditions for different attributes, each condition corresponds to a different score, and realizes score calculation of the target object; The complex score card module is a score card provided in URule Pro, which can perform condition superposition judgment on multiple object attributes, and realizes more complex scoring functions; The decision table module adopts a fully visual and graphical operation mode, can quickly define a decision table matched with the business, and facilitates users to directly perform decision analysis; The decision tree module uses a lying down tree structure to represent and construct rules, can more visually represent business rules, and can more intuitively analyze the pros and cons of the decision result, assisting users to make the final decision faster; When a rule flow is modified and published again, the version control module records a version for each publication and stores it in a version list, users can view any historical version in the version list at any time, and enter the flow details to view the detailed configuration of the flow in the version; however, the historical version does not save rules with errors, and a rule flow that is not successfully published does not appear in the historical version; When the latest version publication has a problem, the version rollback module is used to rollback the latest version to the previous stable version or any selected historical version, to ensure service running, have sufficient time to troubleshoot and repair the problem, repair successfully and then publish a new version, or set the selected historical version as the current latest version.

Images