A rule engine execution method based on dynamic format parameters, a rule engine

Abstract

The application relates to a dynamic format parameter-based rule engine execution method, which comprises the following steps: receiving an HTTP call request sent by a calling party, and parsing a knowledge base code, a rule set code and external JSON data; querying and loading corresponding knowledge base objects according to the knowledge base code; parsing corresponding rule set objects from a rule set list according to the rule set code, wherein the rule set objects contain variable structure descriptions, rule lists and out-parameter definitions; dynamically compiling and generating fact objects according to the external JSON data and the variable structure descriptions; generating executable rule definition files according to the rule lists; executing rule matching and reasoning according to the fact objects, the rule definition files and internal parameters, and obtaining an execution result object; extracting corresponding fields from the execution result object according to the out-parameter definitions, and encapsulating the fields into an HTTP response body to return to the calling party; the application provides a flexible rule changing mode, improves rule execution efficiency and is suitable for diversified business scenarios.

Description

Technical Field

[0001] This invention relates to the field of rule engine technology, and in particular to a rule engine execution method and a rule engine based on dynamic format parameters. Background Technology

[0002] A rule engine is a middleware software that separates business decision-making logic from application code and performs condition judgments and action execution through independent rule definition files. Its core architecture typically includes three parts: "Facts," "Rules," and "Inference Engine." Currently, rule engines are widely used in fields such as financial risk control, production scheduling, customer management, and IoT decision-making, becoming a core supporting technology for enterprises to flexibly orchestrate business logic.

[0003] However, existing rule engines have the following shortcomings when dealing with dynamically changing business needs: First, rule configuration based on low-code platforms has low execution efficiency, a fixed rule flow, and lacks intelligent judgment of the execution order, mechanically judging each node according to a preset process, resulting in poor flexibility. Second, custom development based on mature rule engines has high learning and maintenance costs, and rule modifications are difficult to closely align with business needs. It generally lacks a robust rule management, version control, and version switching and release mechanism, easily leading to version misuse. Third, rule parsing based on Excel spreadsheets is difficult to clearly express complex nested or logical relationships, resulting in chaotic version management and a high risk of file conflicts or overwriting. Fourth, rule calculation based on lightweight script engines has a high technical threshold, and malicious code may be introduced during script editing, posing security risks. Summary of the Invention

[0004] Based on the above analysis, the embodiments of the present invention aim to provide a rule engine execution method and a rule engine based on dynamic format parameters, in order to solve the problems of poor data structure flexibility, insufficient dynamic rule update capability, and difficulty in simultaneously meeting the frequent changes in business needs and hot deployment of rules in enterprise-level applications.

[0005] On one hand, embodiments of the present invention provide a rule engine execution method based on dynamic format parameters, including: Receive an HTTP call request sent by the caller, and parse the knowledge base encoding, rule set encoding, and external JSON data from the HTTP call request; The corresponding knowledge base object is queried and loaded according to the knowledge base encoding. The knowledge base object contains a rule set list and internal parameters. The corresponding rule set object is parsed from the rule set list of the knowledge base object according to the rule set encoding. The rule set object contains a variable structure description of dynamic format parameters, a rule list, and output parameter definitions. Based on the external JSON data and the variable structure description, a fact object is dynamically compiled and generated. Generate an executable rule definition file based on the rule list; Based on the fact object, the rule definition file, and the internal parameters in the knowledge base object, rule matching and reasoning are performed to obtain the execution result object; Based on the output parameter definition, the corresponding fields are extracted from the execution result object and encapsulated into a JSON-formatted HTTP response body, which is then returned to the caller.

[0006] Furthermore, the variable structure description of the dynamic format parameters is used to define the field structure, data type, and nesting relationship of the external JSON data; the rule list is used to define rules of preset types; the output parameter definition is used to standardize the name, data type, and default value of the output variables, wherein the output variables are the data fields to be returned contained in the execution result object.

[0007] Furthermore, the step of dynamically compiling and generating a fact object based on the external JSON data and the variable structure description includes: Based on the variable structure description of the dynamic format parameters, analyze the structure of the external JSON data to determine the set of dynamic objects to be created, the field definitions and field types within each dynamic object, and the nesting relationships between the dynamic objects. Based on the dynamic object collection, the field definitions and field types, and the nesting relationships, the corresponding Groovy class source code is generated. The Groovy class source code is dynamically compiled using the GroovyClassLoader class loader, and the compiled object class is instantiated. For the instantiated object class, the external JSON data is parsed layer by layer and populated into the corresponding attributes of the instantiated object class to obtain the fact object.

[0008] Further, the step of generating an executable rule definition file based on the rule list includes: Identify the type of each rule in the rule list, call the corresponding rule builder to generate rule file fragments according to the identified rule type, and integrate the rule file fragments into an executable rule definition file; wherein the executable rule definition file adopts a WHEN-THEN structure. Furthermore, the rule types include at least condition group rules, cross-decision table rules, decision table rules, decision tree rules, lookup table rules, or scorecard rules.

[0009] Furthermore, the step of invoking the corresponding rule builder to generate rule file fragments based on the identified rule type includes: If the rule type is the condition group rule, then a WHEN-THEN structure is generated based on the nested condition judgment items and logical relationships stored in the condition group rule. If the rule type is the cross-decision table rule, then the cross-results of the row header and list header stored in the cross-decision table rule are decomposed into multiple condition-result mappings; If the rule type is the decision table rule, then a multi-condition combination rule is generated based on the multi-column conditions and decision columns stored in the decision table rule; If the rule type is the decision tree rule, then the node branches stored in the decision tree rule are converted into a set of path rules; If the rule type is the lookup table rule, then a lookup operation instruction is generated based on the mapping relationship between row keys and column keys stored in the lookup table rule; If the rule type is the scorecard rule, then an cumulative scoring rule is generated based on the condition list and score stored in the scorecard rule.

[0010] Furthermore, the parameters or variables in the rule definition file are identified using the following unified symbols: Using the symbol " "Identify the input variable obtained based on the fact object; use the symbol " "Identify the output variable to be returned; use the symbol " "Identifies global parameters pre-injected into the execution environment; utilizes the symbol " "Identifies the internal parameters in the knowledge base object."

[0011] Further, the step of performing rule matching and reasoning based on the fact object, the rule definition file, and the internal parameters in the knowledge base object to obtain an execution result object includes: Load the rule definition file and create a rule execution session; Inject the pre-injected global parameters, the internal parameters, and the fact object into the rule execution session; In the rule execution session, the following process is repeated until no rule can be triggered: check whether the fact object satisfies the WHEN condition of each rule in the rule definition file. If it does, execute the THEN action of the corresponding rule and update the fact object according to the action result. The output data generated during execution is encapsulated into an execution result object.

[0012] Further, the step of extracting corresponding fields from the execution result object according to the output parameter definition and encapsulating them into a JSON-formatted HTTP response body and returning it to the caller includes: Obtain the output variable name specified in the output parameter definition, extract the attribute value with the same name as the output variable name from the execution result object, encapsulate the extracted output variable name and its attribute value into an HTTP response body in JSON format and return it to the caller.

[0013] On the other hand, embodiments of the present invention provide a rule engine based on dynamic format parameters for implementing the rule engine execution method as described in any of the foregoing aspects, comprising at least: The knowledge base management module is used to add, delete, modify, and query knowledge base data. The rule set management module is used to add, delete, modify, and query rule sets. The rules management module is used to manage the business rules that make up the rule set; The variable configuration module is used to configure input variables, intermediate variables, and output variables. The input variables are used to define the dynamic structure of external JSON data, the intermediate variables are used to pass the calculation results within the rule set, and the output variables are used to output the data when the rule set finishes running. The version switching module is used for multi-version management of the knowledge base; The rule configuration module is used to configure condition group rules, cross decision table rules, decision table rules, decision tree rules, lookup table rules, or scorecard rules. The rules application module is used to group and manage the knowledge base by business domain, and supports permission isolation, batch publishing and statistical analysis functions; The lookup table management module is used to add, delete, modify, and query data in the lookup table, and supports importing or maintaining data via Excel. The function management module provides built-in functions from the mathematical function group, logical function group, and set function group for reference when configuring rules and conditions. The global parameter management module is used to add, delete, modify, and query parameters with a global scope, enabling different knowledge bases to share global parameters; The internal parameter management module is used to add, delete, modify, and query parameters with a scope of a single knowledge base, enabling the sharing of internal parameters within the same knowledge base.

[0014] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: First, unlike the poor data structure flexibility in related technologies, this invention adopts a dynamic structure parameter format and uses the Groovy script engine to compile and generate fact objects at runtime. This enables flexible expansion of input parameter fields, types, and nesting relationships. It can adapt to input data of any structure without modifying the code or restarting the service, which enhances the adaptability to diverse data formats. Moreover, the dynamic variable format can be reused, which significantly improves the configuration efficiency of rule variables.

[0015] Secondly, unlike related technologies which suffer from insufficient dynamic rule update capabilities and low efficiency, this invention achieves online hot updates of rules and automatic cache refresh by designing a rule execution file caching structure. Simultaneously, it provides multiple rule configuration methods, adapting to both simple, structured rules and complex rule conditions, effectively reducing the learning cost of the rule engine. Users can intuitively configure rule conditions through the system's rich function library, significantly improving rule reasoning efficiency and avoiding performance losses caused by fixed process judgments based on code or low-code. Third, unlike related technologies that struggle to meet the frequent changes in business needs and the challenges of hot rule deployment, this invention expands and adds parameters in different dimensions, such as input variables, internal parameters, intermediate variables, global parameters, and output variables, to facilitate data changes under multiple rule scenarios. Simultaneously, it supports packaging a single knowledge base, enabling rapid import and unified management of the entire business process. It provides knowledge base management based on multiple rule types, along with convenient version control, offering more flexible rule change methods. This significantly reduces the operational complexity of the rule engine and adapts to diverse business scenarios.

[0016] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0018] Figure 1 This is a flowchart of a rule engine execution method based on dynamic format parameters according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the main functional modules of the rule engine based on dynamic format parameters according to an embodiment of the present invention. Detailed Implementation

[0019] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0020] A specific embodiment of the present invention discloses a rule engine execution method based on dynamic format parameters, such as... Figure 1 As shown, the steps S1 to S7 are as follows: Step S1: Receive the HTTP call request sent by the caller, and parse the knowledge base encoding, rule set encoding, and external JSON data from the HTTP call request.

[0021] In implementation, the system first receives an HTTP request from the caller, whose HTTP request body contains a string containing the knowledge base's structural information. The caller refers to an external system, terminal device, or business user's operating terminal that initiates the HTTP request and receives the HTTP response body. In this embodiment, the caller actively sends the request, and the rule engine returns the result to the same caller after processing. The rule engine can be used directly by business users or remotely via HTTP from other business systems. Furthermore, this invention adopts a RESTful HTTP calling method, which refers to an HTTP protocol calling method that follows the constraints of a state transition architecture. This method is resource-centric, using standardized HTTP methods, unified resource identifiers, and a stateless interaction mechanism to achieve data communication and resource operations between the client and server.

[0022] Specifically, in this embodiment, the data parsed from the HTTP request body includes the knowledge base code (knowledgeCode), the rule set code (ruleSetCode), and the external data object (data, JSON format, variable structure). The knowledge base code uniquely identifies the knowledge base; the rule set code is a string or identifier that uniquely identifies a rule set, specifying the specific rule set to be executed. During processing, the HTTP request body is first parsed to extract the knowledge base code, rule set code, and external data. Then, the integrity of the request parameters is verified, resulting in a structured request object.

[0023] For example, taking the steel production quality inspection scenario as an example, the received HTTP call request contains the following sample data: the knowledge base is encoded as "STEEL_QUALITY_K01", the rule set is encoded as "SURFACE_DEFECT_RS01", the input parameter object of the external JSON data records the product name as "hot-rolled steel plate", the thickness as 25.0 mm, the width as 1500.0 mm, the length as 6000.0 mm, the temperature as 920.0 degrees Celsius, and the nested sub-object of surface condition contains information of type "iron oxide scale", area as 0.15, and severity as 2.

[0024] It is understood that the "dynamic format parameters" in this embodiment of the invention refer to a data structure specification that is dynamically defined and can be adjusted in real time during the rule engine's runtime, which differs from the fixed field set parameters used in existing rule engines. The dynamic format parameters allow users to customize the field names, data types, nesting relationships, and set types of input data according to business needs, and different rule sets under the same knowledge base can use different dynamic format parameter configurations. Through these dynamic format parameters, the rule engine can adapt to input data of arbitrary structures without modifying the underlying code, achieving dynamic parsing, object nesting, and type reuse of external JSON data.

[0025] It should be noted that the rule engine and execution method proposed in this invention are particularly suitable for the field of steel production scheduling. The steel production process involves multiple steps such as steelmaking, continuous casting, hot rolling, and cold rolling. The scheduling constraints of each step (such as steel grade, temperature, time window, equipment status, order priority, etc.) change frequently with the production plan, and the data fields, structures, and nesting relationships required by different steps differ significantly. Traditional rule engines with fixed data structures struggle to meet the real-time and dynamic requirements of steel production scheduling. This application, through dynamic format parameters and a hot rule update mechanism, enables schedulers to adjust the input parameter data structure online and change scheduling rules in real time. Rule configuration and deployment can be completed without system downtime, significantly improving the flexibility and response efficiency of the steel production scheduling system.

[0026] Step S2: Query and load the corresponding knowledge base object according to the knowledge base encoding. The knowledge base object contains a rule set list and internal parameters.

[0027] Specifically, this embodiment can parse strings using a rule engine based on a predefined knowledge base structure. The knowledge base structure includes a list of rule sets and internal parameters. These internal parameters provide shared internal variable information for all rule set structures within the current knowledge base. A knowledge base object can be understood as a configuration data entity in the rule engine used to encapsulate a complete business knowledge domain. Each knowledge base object uniquely corresponds to a business domain (such as steel quality inspection or production scheduling), containing the definitions of all rule sets within that domain and the shared internal parameters. At runtime, the rule engine loads the corresponding knowledge base object based on the knowledge base encoding provided by the caller, serving as the basis for subsequent rule matching and execution.

[0028] During processing, the basic information of the knowledge base is first queried based on the knowledge base code to obtain the list of rule sets under the knowledge base (including the code and ID of each rule set). Then, the internal parameter configuration of the knowledge base is loaded to obtain a knowledge base object containing complete design information of the knowledge base.

[0029] For example, the data structure of a knowledge base object is as follows: the knowledge base is encoded as "STEEL_QUALITY_K01", the rule set list is an empty array, and the internal parameter list is an empty array. As another example, if the knowledge base is encoded as "STEEL_QUALITY_K02", the rule set list contains two rule sets: surface defect judgment and dimensional deviation judgment, and the internal parameters include two parameters: temperature threshold and upper limit of defect area.

[0030] In this embodiment, all rule sets under the same knowledge base can share internal parameters, avoiding redundant parameter configuration. Simultaneously, the rule set list provides an optional range of rule sets, facilitating flexible scheduling according to business needs. This mechanism effectively reduces the redundancy of rule configuration and improves management efficiency and loading speed in multi-knowledge base scenarios.

[0031] Step S3: Parse the corresponding rule set object from the rule set list of the knowledge base object according to the rule set encoding. The rule set object contains a variable structure description of dynamic format parameters, a rule list, and output parameter definitions.

[0032] Specifically, the system first searches for the corresponding coded rule set in the rule set list of the knowledge base object, and then loads the complete definition of the rule set, which includes: the variable structure description of the dynamic format parameter, used to define the field structure, data type and nesting relationship of the external JSON data (input parameter data); the rule list, used to define rules of preset types, such as the configuration of various rules such as condition groups and decision tables; and the output parameter definition, also known as the output parameter definition, which is used to specify the name, data type and default value of the output variable; wherein, the output variable, also known as the output parameter variable, is the data field to be returned contained in the execution result object.

[0033] For example, an instance of a rule set object is as follows: This rule set object is identified as "RS001_id", encoded as "SURFACE_DEFECT_RS01", and named "Surface Defect Judgment Rule Set". Its definition includes dynamic structure variable descriptions and output parameter definitions. The variable structure description defines a fact object named "ProjectFact", which contains three fields: thickness (data type Double, default value 0), width (data type Double, default value 0), and surface condition (data type Object, referenced object encoded as "SurfaceCondition"), demonstrating the object nesting and type reuse supported by dynamic format parameters. The output parameter definition defines three output variables: judgment result (data type String), judgment reason (data type String), and level (data type Integer). In addition, this rule set object also contains a list of rules, such as condition group rules and cross-decision table rules.

[0034] This allows different rule sets within the same knowledge base to have their own independent input parameter structures, and the input parameter structure of each rule set can be adjusted at any time according to business needs without modifying the underlying code or redeploying the system. Simultaneously, the independently defined output parameters in the rule set object clearly specify the variable names, data types, and default values ​​to be output after rule execution, avoiding parsing difficulties for callers caused by inconsistent output structures across different rule sets. This ensures both the flexibility and scalability of rule execution and the standardization of output results, enhancing the rule engine's adaptability across multiple business scenarios.

[0035] Step S4: Dynamically compile and generate a fact object based on the external JSON data and the variable structure description.

[0036] In practice, this includes: analyzing the structure of the external JSON data based on the variable structure description of the dynamic format parameters, determining the set of dynamic objects to be created, the field definitions and field types within each dynamic object, and the nesting relationships between the dynamic objects; Based on the dynamic object collection, the field definitions and field types, and the nesting relationships, the corresponding Groovy class source code is generated. The Groovy class source code is dynamically compiled using the GroovyClassLoader class loader, and the compiled object class is instantiated. For the instantiated object class, the external JSON data is parsed layer by layer and populated into the corresponding attributes of the instantiated object class to obtain the fact object.

[0037] In this embodiment of the invention, a fact object is dynamically generated according to the variable structure description. This fact object is a dynamic structure variable, which is a specific data structure defined according to the dynamic format parameter specification. It is used to receive external JSON data passed in when calling the knowledge base, and to structure the external JSON data according to the fields, types and nesting relationships defined in the variable structure description, so as to be used for rule matching and reasoning in subsequent steps.

[0038] It is understandable that the dynamic structure variables obtained by parsing the predefined dynamic format parameters of the rule engine support the reuse of already created structure variables; through the dynamic combination of multiple structure variables, a data structure scheme that meets business requirements can be defined, and the structure can also be dynamically adjusted according to data received from outside the rules, resulting in higher adaptability. In this embodiment, Groovy is a dynamic programming language based on the Java Virtual Machine (JVM), which, while fully compatible with the Java ecosystem, possesses a simpler syntax and greater runtime flexibility.

[0039] This embodiment uses Groovy technology to preprocess fact data, eliminating the need for pre-compilation and allowing direct execution of fact logic or action code. It boasts excellent compatibility, seamlessly integrating with the overall framework of the rule engine. Furthermore, it offers performance advantages, with fast parsing speed, support for rapid logic changes, and significantly improved processing efficiency of the rule engine.

[0040] Meanwhile, leveraging Groovy's dynamic compilation capabilities, this invention achieves dynamic generation and real-time compilation of input variable structures, avoiding redundant coding and frequent deployments caused by fixed data structures in traditional methods. Users can flexibly configure data preprocessing logic according to actual business needs, dynamically load and process input data, greatly enhancing the system's adaptability to changing business scenarios. This not only reduces development complexity but also significantly improves the efficiency of rule execution and data preparation.

[0041] In some implementations, dynamically compiling to generate fact objects specifically includes the following process: First, perform dynamic object structure analysis. Based on the variable structure description (such as ProjectFact and SurfaceCondition in the example), analyze the structure of the external JSON data to determine the number of dynamic object types to be created, the number and type of fields in each object, and the nesting relationships between objects.

[0042] Secondly, the Groovy script engine is used for runtime dynamic compilation to generate fact objects: variable structure descriptions (such as the DynamicObjectDescription list) that receive dynamic format parameters are parsed, the field definitions of each object are parsed, and Groovy class source code strings are generated. For example, the ProjectFact class is generated, which contains Double type fields for thickness, width, length, and temperature, as well as a SurfaceCondition field of type surfaceCondition. At the same time, the SurfaceCondition class is generated, which contains String type type, Double type area, and Integer type severity fields.

[0043] Next, the Groovy source code is dynamically compiled using GroovyClassLoader, the compiled object class is instantiated, and the external JSON data is mapped to the corresponding properties of the object. Finally, the fact object data is populated: the fact object is parsed and populated layer by layer according to the external JSON data.

[0044] For example, parsing the `thickness`, `width`, and `surfaceCondition` fields from external JSON data, creating a `ProjectFact` instance and setting its basic properties: assigning `thickness` to 25.0 and `width` to 1500.0; then, creating a nested `SurfaceCondition` object, instantiating it, and assigning its `type` to "iron oxide scale", `area` to 0.15, and `severity` to 2. Finally, establishing the nesting relationship, for example, `projectFact.surfaceCondition = sc`. Outputting an executable `ProjectFact` instance containing complete data, with a thickness of 25.0, a width of 1500.0, a length of 6000.0, a temperature of 920.0, and a surface condition of a nested `SurfaceCondition` instance with a type of "iron oxide scale", an area of ​​0.15, and a severity of 2.

[0045] Therefore, the ProjectFact instance mentioned above, as a dynamically generated fact object, provides a well-structured data foundation for rule matching and reasoning in subsequent steps, enabling the rule engine to directly evaluate conditions and execute actions based on the field values ​​of this instance.

[0046] Step S5: Generate an executable rule definition file based on the rule list.

[0047] Specifically, each rule type has a predefined structure, and rule sets are matched according to the choices made by business users. The rule engine uses a drag-and-drop UI interface for rule configuration, reducing the difficulty of use for non-business users; the system automatically generates rule templates to avoid syntax errors caused by incorrect configuration.

[0048] The specific rule information in this embodiment consists of condition structure data and assignment structure data.

[0049] Among them, the conditional structure data includes two forms of expression: formulas and conditional groups. The formula is a text string, which can reference dynamic format parameters (i.e., input variables), output variables, internal parameters of the knowledge base, global parameters, and functions in the function library built into the rule engine. It is calculated to obtain a Boolean value as the condition judgment result. Preferably, the parameters or variables in the rule definition file are identified using the following unified symbols: Using the symbol " "Identify the input variables (dynamic data from external input) obtained based on the stated fact object, such as " " indicates that the variable width is being referenced; Using the symbol " "Identify the output variable to be returned (the output variable of the rule execution result), such as " " indicates that a value is assigned to the variable result; Using the symbol " "Identifiers are global parameters pre-injected into the execution environment (shared across the knowledge base), such as " " indicates referencing a global parameter; Using the symbol " "Identifies internal parameters within the knowledge base object (shared within the current knowledge base), for example, " "" indicates referencing internal parameters.

[0050] For example, " In this expression, width is the input parameter, length is the output parameter, high is the global parameter, and inner is the internal parameter of the knowledge base. Therefore, the expression is represented as "input variable width × output variable length - global parameter high) × internal parameter inner > 0". Furthermore, when the above formula is true, the expression performs the corresponding decision assignment operation that is true, and when the above formula is false, the expression performs the corresponding decision assignment operation that is false.

[0051] The condition group of the condition structure data is a set of logical judgment structures that support multi-level nesting. The whole consists of several independent sub-condition groups that can be dynamically adjusted. Each sub-condition group contains several atomic judgment items. The sub-condition groups are related by "AND / OR" logic. The atomic judgment items within the sub-condition groups can also be aggregated by "AND / OR" relationship. Sub-condition groups or atomic judgment items can be flexibly added or removed according to business needs. In the end, all judgment rules can be transformed into complete executable logical formulas according to hierarchical logic, realizing the structured definition and flexible configuration of complex business conditions.

[0052] The rule information in this embodiment also includes assignment structure data. This assignment structure consists of one or more assignment decision expressions, used to define the specific actions to be performed when the condition part of the rule is met. Each assignment decision expression adopts the format "assignment variable = assignment expression".

[0053] For example," ", which means assigning the value 5 to the result variable named result; or, for example, " "The dynamic input variables length, width, and height will be used for calculation, and the result will be assigned to the output variable result."

[0054] As can be seen from the above, the embodiments of the present invention provide users with two flexible and complementary expression configuration methods to support the writing needs of business rules with varying degrees of complexity. In particular, the custom data structure expression based on formula configuration allows users to intuitively combine various predefined elements to construct rule judgment formulas. These elements include: input variables (i.e., externally input data structures), intermediate variables (intermediate results passed during rule execution), output variables (final output target data), global parameters (static parameters shared across knowledge bases), internal parameters (parameters limited to those used in the current knowledge base), and various functions built into the system. Users combine these elements through a visual interface or configuration syntax to form complete business expressions, which the system's underlying layer automatically parses into a standardized formula form that the engine can recognize and execute. This significantly reduces the difficulty for users in writing complex rules while ensuring the structured and maintainable nature of the expressions, effectively balancing development flexibility and system reliability.

[0055] In practice, generating an executable rule definition file specifically includes: identifying the type of each rule in the rule list, calling the corresponding rule builder to generate rule file fragments according to the identified rule type, and integrating the rule file fragments into an executable rule definition file; wherein, the executable rule definition file adopts a WHEN-THEN structure. It is understandable that the aforementioned rule information customized by business personnel refers to the specific content and logic of the rule, while the identification here refers to identifying the structure type of the rule based on the type field (i.e., identifying whether the rule is defined in the form of a condition group, decision table, or decision tree, etc.) so as to call the corresponding converter to convert it into code that the engine can execute.

[0056] Furthermore, the rule types include at least condition group rules (conditionType), crossDecisionTableType, decisionTableType, decisionTreeType, searchTableType, or scoreCardType.

[0057] Preferably, the step of invoking the corresponding rule builder to generate rule file fragments based on the identified rule type includes: If the rule type is the condition group rule, then a WHEN-THEN structure is generated based on the nested condition judgment items and logical relationships stored in the condition group rule; for example, a WHEN-THEN structure is generated based on nested conditions (such as "thickness>10 and (width>100 or length>5000)"): WHEN thickness>10 AND (width>100 OR length>5000)THEN $$result = "qualified".

[0058] If the rule type is the cross-decision table rule, then the cross-result of the row header and list header stored in the cross-decision table rule is decomposed into multiple condition-result mappings; for example, multiple condition-result mappings are generated based on the cross-result of the row header (temperature: high, medium, low) and the list header (humidity: high, low): (temperature=high AND humidity=high) → action = close valve, (temperature=high AND humidity=low) → action = open valve.

[0059] If the rule type is the decision table rule, then a multi-condition combination rule is generated based on the multi-column conditions and decision column stored in the decision table rule; for example, based on the multi-column conditions (steel type, width mm, thickness mm, temperature °C) and the decision column (rolling speed m / s), the following combination rule is generated: WHEN steel type = "Q235" AND width < 1500 AND thickness < 20 AND temperature > 900 THEN rolling speed = 5, WHEN steel type = "Q345" AND width >= 1500 AND thickness >= 20 AND temperature > 950 THEN rolling speed = 4.

[0060] If the rule type is the decision tree rule, then the node branches stored in the decision tree rule are converted into a set of path rules; for example, based on the root node "Defect area > 0.2?", the left branch (yes) → "Severity level >= 2?", the right branch (no) → "Pass", generating the path conversion: WHEN Defect area > 0.2 AND Severity level >= 2 THEN Final level = "Scrap", WHEN Defect area <= 0.2 THEN Final level = "Pass".

[0061] If the rule type is the lookup table rule, then a lookup operation instruction is generated based on the mapping relationship between row keys and column keys stored in the lookup table rule; for example, if the row key is "product brand", the column key is "customer code", and the value is "priority delivery level", the lookup instruction is generated as: priority = delivery priority table.get(brand, customer code), for example, the records in the table are: (Q235, customer code A) → level 1, (Q345, customer code B) → level 2.

[0062] If the rule type is the scorecard rule, then an additive scoring rule is generated based on the condition list and scores stored in the scorecard rule. For example, the condition list and scores are: defect area <0.05 → +10 points, 0.05~0.1 → +5 points, >0.1 → 0 points; temperature >950℃ → +20 points, 900~950℃ → +10 points, <900℃ → 0 points. The additive scoring is generated as follows: IF defect area <0.05 THEN quality score += 10; IF temperature >950 THEN quality score += 20; final total score = quality score.

[0063] It should be noted that the rule builder in this embodiment refers to a conversion component pre-configured for each preset rule type. The specific implementation can use a template engine or related compilation technology, which will not be elaborated here. Of course, the various examples of generating rule file fragments mentioned above are only for ease of understanding and simplification of description, and are not intended to limit the present invention.

[0064] Therefore, by integrating all the rule fragments, a complete rule definition file can be obtained. For example, a rule definition file using a "WHEN-THEN" structure is as follows: In the WHEN section, the triggering conditions are defined. First, a fact object `fact` of type `ProjectFact` is declared, and its thickness and width are limited to be greater than 0. Second, a nested object `fact` of type `SurfaceCondition` is declared, and its thickness and width are limited to be greater than 0. Third, a nested object `sc` of type `SurfaceCondition` is declared, and its severity is limited to be greater than or equal to 3. In the THEN section, the action to be performed when the conditions are met is defined, that is, calling the method of the `ActionResult` object, using `fact` and the string "unqualified" as parameters to set the judgment result, and using `fact` and the string "severe surface defect" as parameters to set the judgment reason.

[0065] It is understandable that rule files can be written using DRL (Drools Rule Language), which adopts an intuitive "When-Then" structure: the "When" part defines the condition pattern, that is, the condition that satisfies a certain factual state; the "Then" part specifies the action to be performed when the condition is met. This structure is highly consistent with the thinking mode of business personnel, enhancing the readability and maintainability of the rules, which will not be elaborated here.

[0066] Therefore, by automatically identifying the rule type and calling the corresponding builder, the visual configuration is converted into an executable rule file, avoiding the complexity and error risk of manually writing code, improving the efficiency of rule configuration, and reducing the difficulty of rule configuration.

[0067] Step S6: Perform rule matching and reasoning based on the fact object, the rule definition file, and the internal parameters in the knowledge base object to obtain the execution result object.

[0068] Specifically, this invention adapts and optimizes the traditional RETE algorithm to suit the characteristics of dynamic format parameters. During the compilation phase, it supports real-time binding of dynamic fields, avoiding full recompilation triggered by field changes, thereby improving rule matching efficiency for complex dynamic structure data. When the knowledge base is published, the rule set is pre-compiled into a DRL format rule definition file and cached in a distributed cache; when a rule is invoked, the cached file is loaded directly, eliminating the need for real-time generation. If the rule set is updated and republished, the cache is automatically refreshed, ensuring hot-update capabilities for rules. This significantly optimizes matching efficiency for large-scale rule sets and complex object models, avoids redundant condition calculations, and enables rapid inference and response to real-time incoming data.

[0069] Furthermore, before formally executing rule matching, Groovy's dynamic processing capabilities are used to preprocess the external input data, including data cleaning, format conversion, and structural encapsulation. After preprocessing, structured data objects conforming to the recognition specifications are dynamically generated based on the syntax structure required by the rule engine. This processed data, in the form of fact objects, is loaded into the working memory in batches at the beginning of rule execution, completing the data ingestion. Subsequently, these sets of variables carrying dynamic structural information are stored in the rule engine's workspace, providing support for subsequent rule matching and inference.

[0070] In practice, the execution of rule matching and reasoning specifically includes: Load the rule definition file and create a rule execution session; Inject the pre-injected global parameters, the internal parameters, and the fact object into the rule execution session; In the rule execution session, the following process is repeated until no rule can be triggered: check whether the fact object satisfies the WHEN condition of each rule in the rule definition file. If it does, execute the THEN action of the corresponding rule and update the fact object according to the action result. The output data generated during execution is encapsulated into an execution result object.

[0071] For example, first, the execution environment is initialized: the generated rule definition file is loaded and a rule execution session is created. Global parameters (system-level shared parameters) and internal parameters of the knowledge base object are injected into the execution environment of this session. The global parameters are shared by all rules, while the internal parameters are shared only by rules under the current knowledge base. Second, the fact object is injected: the dynamically compiled fact object is inserted into the working memory, and a result object for receiving the output results is also created and inserted into the working memory.

[0072] After completing the above preparations, the rule pattern matching and execution phase begins: Upon the fact object entering the working memory, rule condition evaluation is triggered, automatically evaluating the WHEN condition portion of all rules in the rule definition file. When a fact object satisfies the WHEN condition of a rule, the THEN action portion of that rule is executed. This action execution may modify the object's state in the working memory, and the state change may trigger the execution of other rules, thus achieving linkage between multiple rules. This evaluation and action process is repeated until no more rules can be triggered. Finally, the output data generated during execution is encapsulated into an execution result object.

[0073] This enables real-time binding of dynamic fields and hot updating of rules, significantly improving the matching efficiency of complex dynamic data and enhancing response speed and flexibility.

[0074] Step S7: Extract the corresponding fields from the execution result object according to the output parameter definition, encapsulate them into an HTTP response body in JSON format, and return it to the caller.

[0075] In practice, the specific steps include: obtaining the output variable name specified in the output parameter definition, extracting the attribute value with the same name as the output variable name from the execution result object, encapsulating the extracted output variable name and its attribute value into an HTTP response body in JSON format, and returning it to the caller.

[0076] For example, the calculation results can be summarized by the assignment variable structure. According to the structure of the variable configuration, all assignment results (including the final decision result and the derived values ​​of key intermediate variables) can be summarized and encapsulated in the standard JSON format as an HTTP response body and returned to the caller. At the same time, the execution log (including call parameters, execution time and result details) can be recorded for troubleshooting and auditing.

[0077] In some implementations, the specific encapsulation process includes: first, obtaining a list of output parameter definitions, where each output parameter definition contains a variable code, a name, and a data type; second, traversing the list of output parameter definitions and extracting the specific values ​​corresponding to each output parameter code from the execution result object; finally, according to the structure of the output parameter definitions, encapsulating these extracted values ​​into a standard JSON format HTTP response body and returning it to the caller. For example, a complete response body format is: status code 200, message "execution successful", the data part includes the knowledge base code "STEEL_QUALITY_K01", the rule set code "SURFACE_DEFECT_RS01", and the specific output from the execution result object, where the result object includes the judgment result "downgrade", the judgment reason "surface defect area exceeds the standard", level 2, and score 45. This ensures the structural uniformity and parsability of the output data.

[0078] It is understood that the above implementation methods are only for ease of understanding and simplification of description, and should not be construed as limitations on the present invention. The present invention does not specifically limit the types of knowledge bases and rule sets, the setting and parsing methods of dynamic format parameters, the rule matching and reasoning process, etc.

[0079] In another embodiment of the present invention, a rule engine based on dynamic format parameters is proposed to implement the rule engine execution method as described in any of the foregoing embodiments, such as... Figure 2 As shown, it includes at least: The knowledge base management module is used to add, delete, modify, and query knowledge base data. The rule set management module is used to add, delete, modify, and query rule sets. The rules management module is used to manage the business rules that make up the rule set; The variable configuration module is used to configure input variables, intermediate variables, and output variables. The input variables are used to define the dynamic structure of external JSON data, the intermediate variables are used to pass the calculation results within the rule set, and the output variables are used to output the data when the rule set finishes running. The version switching module is used for multi-version management of the knowledge base; The rule configuration module is used to configure condition group rules, cross decision table rules, decision table rules, decision tree rules, lookup table rules, or scorecard rules. The rules application module is used to group and manage the knowledge base by business domain, and supports permission isolation, batch publishing and statistical analysis functions; The lookup table management module is used to add, delete, modify, and query data in the lookup table, and supports importing or maintaining data via Excel. The function management module provides built-in functions from the mathematical function group, logical function group, and set function group for reference when configuring rules and conditions. The global parameter management module is used to add, delete, modify, and query parameters with a global scope, enabling different knowledge bases to share global parameters; The internal parameter management module is used to add, delete, modify, and query parameters with a scope of a single knowledge base, enabling the sharing of internal parameters within the same knowledge base.

[0080] In some preferred embodiments, the functional modules of the rule engine are divided as follows: user management, role management, permission management, department management, and system monitoring serve as the platform's basic functional modules; knowledge base management, rule set management, rule management, variable configuration, version switching, rule configuration, rule application, lookup tables, function management, and global parameters constitute the core rule modules of the rule engine. Among them, the rule set module is the core component of the system, responsible for specific rule processing and the parsing and execution of custom dynamic format parameters.

[0081] It should be noted that, unlike existing rule engines that use fixed-field set parameter injection (i.e., a "flat" structure that only supports one-dimensional fixed fields and does not support object nesting, dynamic field expansion, or data type reuse), the rule engine in this embodiment of the invention firstly adopts user-definable dynamic format parameters. The data structure can be adjusted in real time according to business needs, supporting flexible field expansion, object embedding, and type reuse. Secondly, a user-customizable data preprocessing module is added, which dynamically transforms, cleans, or adjusts the structure of external input data by configuring preset functions or custom functions to adapt to rule execution requirements. In addition, dynamic configuration of rule configurations is supported, allowing business personnel to dynamically change rules based on business information. Simultaneously, version control functionality is added, supporting parallel management of multiple versions of the knowledge base, including version copying (quickly reusing existing configurations), version inheritance (packaging existing knowledge bases to generate new instances), version release (providing services independently after deployment), and version switching (editing / rollback does not affect online operation). Published versions support remote invocation and are completely isolated from edited versions.

[0082] The following describes the specific functions of each module of the rules engine.

[0083] (1) User Management Module: Used to perform user addition, deletion, modification, query operations, and role binding functions.

[0084] (2) Role Management Module: Used to perform operations such as adding, deleting, modifying, and querying roles, as well as binding permissions.

[0085] (3) Permission Management Module: Used to perform functions of adding, deleting, modifying and querying permission configurations.

[0086] (4) Department Management Module: Used to perform functions such as adding, deleting, modifying, and querying departments, as well as binding users to departments.

[0087] (5) Knowledge base: Used to perform the functions of adding, deleting, modifying and querying the knowledge base. The knowledge base contains at least predefined internal parameters and a list of rule sets. The list of rule sets consists of one or more rule sets.

[0088] (6) Rule set module: used to perform the functions of adding, deleting, modifying and querying rule sets. Each rule set consists of one or more rules. The rule set includes a rule list, variable configuration and interface debugging, etc., and the rule set can be copied to achieve quick configuration.

[0089] (7) Rule management module: used to perform rule management functions. Specific business rules are composed of multiple rules in a permutation and combination.

[0090] (8) Variable configuration module: In this module, the configured variables are divided into several different types, namely input variables, intermediate variables, and output variables, among which: The input variable is a data structure representation of external data. This structure can be dynamically configured by the user according to the actual situation, including various embedded object structures and collection types; thus, object nesting and type reuse are realized through dynamic structure description. Intermediate variables are limited to the current rule set and are used to pass calculation results between rules. After the rule set is executed, they are not output externally and are only used as internal data carriers.

[0091] The output variable is the data output when the rule set finishes running. It is the output carrier of the rule execution result and the assignment result is summarized according to the output variable configuration structure.

[0092] (9) Version Switching Module: Used to provide different configurations for multiple versions of the knowledge base, including: Copy function: Performs rapid version creation of the current knowledge base with existing data, enabling editing of the new version without affecting online access to the old version; Inheritance function: Existing data can be quickly packaged into a new knowledge base for management; Publishing function: The configured knowledge base can be deployed online, and after deployment, the rule set to which the current knowledge base belongs can be called from outside. Switching Functionality: Provides the ability to switch between historical versions and the current editing version, and supports publishing after switching versions. Versions are divided into the current editing version and historical versions, with publishing and editing operations performed on the current editing version.

[0093] (10) Rule configuration module: used for the management of individual rules. Specifically, it includes the management of rules such as condition group rules, cross decision table rules, decision table rules, decision tree rules, lookup table rules, and scorecard rules.

[0094] (11) Rule Application Module: Used to perform the functions of adding, deleting, modifying and querying rules. The rule application is a business scenario classification container, used to group and manage the knowledge base according to business domains (such as quality design and scheduling). It supports permission isolation, batch publishing and statistical analysis functions.

[0095] (12) Lookup table management module: used to perform lookup table addition, deletion, modification and query functions. For example, users can import or maintain lookup table data through Excel. At the same time, lookup table management is a prerequisite for lookup table rules.

[0096] (13) Function Management Module: This module provides a variety of built-in functions for users to reference when configuring rule conditions. Functions are managed by different function groups, namely mathematical function group, logical function group, and set function group. Business personnel can directly reference functions to construct rule conditions.

[0097] (14) Global Parameter Module: Used to perform functions of adding, deleting, modifying and querying global parameters, and to complete the configuration of parameters with global scope; at the same time, when configuring formulas, different knowledge bases of the same rule engine share the data of global parameters.

[0098] (15) Internal parameter module: used to perform functions of adding, deleting, modifying and querying internal parameters, and to complete the configuration of parameters with a single knowledge base; at the same time, when configuring formulas, common internal parameter data are shared under the same knowledge base.

[0099] (16) System monitoring module: used to implement system-level monitoring, which can monitor online users, configure database monitoring, SQL query efficiency monitoring, service monitoring (CPU, memory, disk status, etc.), distributed cache monitoring (including basic information of cache service, running status, memory consumption, data volume and cache hit rate, etc.), and cache list (displays each cache list, and can query the corresponding cache content by key name).

[0100] (17) Condition group rule module: used to configure a condition group consisting of multiple condition judgments, and set corresponding decision assignments when the condition group is true and false respectively. When the condition group is true, the decision assignment is executed to satisfy the condition, and when it is false, the decision assignment is executed to not satisfy the condition.

[0101] (18) Cross-Decision Table Rule Module: This module is used to configure a structured table with two-way dimensions defined by row headers and column headers, and to determine a unique decision result in the cell corresponding to the intersection of the row and column. Its core logic is as follows: the row header is used to define one decision dimension, the column header is used to define another decision dimension, the intersection of the row and column corresponds to a specific rule condition, and the content of the cell where the intersection is located is the unique decision result under that rule condition.

[0102] (19) Decision table rules module: used to configure multiple column conditions, and output a decision if multiple conditions match true.

[0103] (20) Decision tree rule module: used to configure a tree structure consisting of multiple condition nodes, where non-leaf nodes are condition judgments and leaf nodes are decision outputs; each path from the root node to the leaf node corresponds to a set of condition combinations and a unique decision assignment.

[0104] (21) Lookup table rules module: used to match based on the uploaded row and column data, and output the matched cell data as the decision assignment result.

[0105] (22) Scoring card rules module: used to configure multiple condition judgment items, each condition item is associated with a unique score; when the condition matches true, the corresponding score is accumulated, and the final score is output (supports summation or weighted summation).

[0106] (23) Input variable module: used to receive dynamic structured data from outside the rule engine. The dynamic structure can be defined by the user. Input variables pass external data to the rule engine as fact objects.

[0107] (24) Output variable module: used to define the data results output by the rule engine after execution, including intermediate variables and output variables; intermediate variables are used for temporary data storage during the internal calculation process of the rule engine and are not output to the outside; the final output variables are used to pass the decision assignment results to the outside of the rule engine.

[0108] As can be seen from the above, the rule engine of this embodiment of the invention achieves a highly efficient and flexible rule loading and invocation mechanism through a custom rule execution file caching structure. This caching structure can batch load the online knowledge base and its rule sets during system startup, ensuring that core rules are immediately executable when the service is ready. Simultaneously, the system supports dynamic changes to the knowledge base during runtime, including the deployment of new rules or the removal and updating of existing rules, all taking effect in real time without requiring a service restart. This caching management mechanism not only significantly improves the efficiency of rule retrieval and execution but also ensures the hot-update capability of business rules and the high availability of the system, better adapting to the continuously changing business needs in an enterprise environment.

[0109] Furthermore, to lower the barrier to entry and operational complexity of the rule engine, this invention designs an intuitive and easy-to-use graphical user interface (GUI). This interface allows users to complete the entire lifecycle configuration of the knowledge base through simple operations such as drag-and-drop and selection, enabling abstract management and visual expression of complex business concepts. Users can directly and flexibly define and describe complete business process logic through rule sets without writing underlying code. In addition, the system provides a clear tree-like knowledge base management structure, displaying the composition and relationships of the business knowledge system in a hierarchical manner. This makes the management of multi-level rule sets, variables, and parameters neat and intuitive, greatly improving the system's maintainability and user experience.

[0110] Therefore, it can be seen that the embodiments of the present invention can achieve at least one of the following beneficial effects: First, improve efficiency: using the RETE algorithm for rule and fact pattern matching greatly improves the efficiency of rule reasoning and avoids the performance loss caused by fixed process judgment based on code or low code. Second, it increases data adaptability: through the dynamic variable structure, it enhances the ability to adapt to diverse data formats, and the dynamic variable format is reusable, which significantly improves the configuration efficiency of rule variables. Third, simplified use: effectively reduces the learning cost of the rule engine, and users can intuitively configure rule conditions through the rich function library provided by the system; Fourth, enhance flexibility: provide multiple rule configuration methods such as condition group expressions and formula expressions, which can adapt to both simple structured rules and meet the editing needs of complex rule conditions; Fifth, it supports multiple scope parameters: it expands and adds parameters of different dimensions to facilitate the reuse of variables or parameters, and provides input variables, internal parameters, intermediate variables, global parameters, and output variables respectively, so that users can make data changes under multiple rules. Sixth, it establishes a knowledge management system and improves user experience: it supports packaging of a single knowledge base, enabling rapid import and packaging management of the entire business process; in addition, it provides knowledge base management composed of multiple types of rules, and offers convenient version control, allowing users to switch, copy, and deploy historical versions, providing users with a convenient way to change rules.

[0111] The above-described method and system embodiments are based on the same principles, and their related aspects can be referenced from each other to achieve the same technical effects. For specific implementation processes, please refer to the foregoing embodiments, which will not be repeated here.

[0112] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0113] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A rule engine execution method based on dynamic format parameters, characterized in that, include: Receive an HTTP call request sent by the caller, and parse the knowledge base encoding, rule set encoding, and external JSON data from the HTTP call request; The corresponding knowledge base object is queried and loaded according to the knowledge base encoding. The knowledge base object contains a rule set list and internal parameters. The corresponding rule set object is parsed from the rule set list of the knowledge base object according to the rule set encoding. The rule set object contains a variable structure description of dynamic format parameters, a rule list, and output parameter definitions. Based on the external JSON data and the variable structure description, a fact object is dynamically compiled and generated. Generate an executable rule definition file based on the rule list; Based on the fact object, the rule definition file, and the internal parameters in the knowledge base object, rule matching and reasoning are performed to obtain the execution result object; Based on the output parameter definition, the corresponding fields are extracted from the execution result object and encapsulated into a JSON-formatted HTTP response body, which is then returned to the caller.

2. The execution method according to claim 1, characterized in that, The variable structure description of the dynamic format parameters is used to define the field structure, data type, and nesting relationship of the external JSON data; the rule list is used to define rules of preset types; the output parameter definition is used to standardize the name, data type, and default value of the output variables, wherein the output variables are the data fields to be returned contained in the execution result object.

3. The execution method according to claim 2, characterized in that, The step of dynamically compiling and generating a fact object based on the external JSON data and the variable structure description includes: Based on the variable structure description of the dynamic format parameters, analyze the structure of the external JSON data to determine the set of dynamic objects to be created, the field definitions and field types within each dynamic object, and the nesting relationships between the dynamic objects. Based on the dynamic object collection, the field definitions and field types, and the nesting relationships, the corresponding Groovy class source code is generated. The Groovy class source code is dynamically compiled using the GroovyClassLoader class loader, and the compiled object class is instantiated. For the instantiated object class, the external JSON data is parsed layer by layer and populated into the corresponding attributes of the instantiated object class to obtain the fact object.

4. The execution method according to claim 3, characterized in that, The step of generating an executable rule definition file based on the rule list includes: Identify the type of each rule in the rule list, call the corresponding rule builder to generate rule file fragments according to the identified rule type, and integrate the rule file fragments into an executable rule definition file; wherein the executable rule definition file adopts a WHEN-THEN structure.

5. The execution method according to claim 4, characterized in that, The rule types include at least condition group rules, cross decision table rules, decision table rules, decision tree rules, lookup table rules, or scorecard rules.

6. The execution method according to claim 5, characterized in that, The step of calling the corresponding rule builder to generate rule file fragments based on the identified rule type includes: If the rule type is the condition group rule, then a WHEN-THEN structure is generated based on the nested condition judgment items and logical relationships stored in the condition group rule. If the rule type is the cross-decision table rule, then the cross-results of the row header and list header stored in the cross-decision table rule are decomposed into multiple condition-result mappings; If the rule type is the decision table rule, then a multi-condition combination rule is generated based on the multi-column conditions and decision columns stored in the decision table rule; If the rule type is the decision tree rule, then the node branches stored in the decision tree rule are converted into a set of path rules; If the rule type is the lookup table rule, then a lookup operation instruction is generated based on the mapping relationship between row keys and column keys stored in the lookup table rule; If the rule type is the scorecard rule, then an cumulative scoring rule is generated based on the condition list and score stored in the scorecard rule.

7. The execution method according to claim 4, characterized in that, The parameters or variables in the rule definition file are identified using the following unified symbols: Using symbols "Identify the input variables obtained based on the stated fact object; utilize symbols" "Identify the output variable to be returned; use symbols" "Identify global parameters pre-injected into the execution environment; utilize symbols" "Identifies the internal parameters in the knowledge base object." 8. The execution method according to claim 7, characterized in that, The step of performing rule matching and reasoning based on the fact object, the rule definition file, and the internal parameters in the knowledge base object to obtain an execution result object includes: Load the rule definition file and create a rule execution session; Inject the pre-injected global parameters, the internal parameters, and the fact object into the rule execution session; In the rule execution session, the following process is repeated until no rule can be triggered: check whether the fact object satisfies the WHEN condition of each rule in the rule definition file. If it does, execute the THEN action of the corresponding rule and update the fact object according to the action result. The output data generated during execution is encapsulated into an execution result object.

9. The execution method according to claim 8, characterized in that, The step of extracting corresponding fields from the execution result object according to the output parameter definition, encapsulating them into a JSON-formatted HTTP response body, and returning it to the caller includes: Obtain the output variable name specified in the output parameter definition, extract the attribute value with the same name as the output variable name from the execution result object, encapsulate the extracted output variable name and its attribute value into an HTTP response body in JSON format and return it to the caller.

10. A rule engine based on dynamic format parameters, used to implement the rule engine execution method as described in any one of claims 1 to 9, characterized in that, At least including: The knowledge base management module is used to add, delete, modify, and query knowledge base data. The rule set management module is used to add, delete, modify, and query rule sets. The rule management module is used to manage the business rules that make up the rule set; The variable configuration module is used to configure input variables, intermediate variables, and output variables. The input variables are used to define the dynamic structure of external JSON data, the intermediate variables are used to pass the calculation results within the rule set, and the output variables are used to output the data when the rule set finishes running. The version switching module is used for multi-version management of the knowledge base; The rule configuration module is used to configure condition group rules, cross decision table rules, decision table rules, decision tree rules, lookup table rules, or scorecard rules. The rules application module is used to group and manage the knowledge base by business domain, and supports permission isolation, batch publishing and statistical analysis functions; The lookup table management module is used to add, delete, modify, and query data in the lookup table, and supports importing or maintaining data via Excel. The function management module provides built-in functions from the mathematical function group, logical function group, and set function group for reference when configuring rules and conditions. The global parameter management module is used to add, delete, modify, and query parameters with a global scope, enabling different knowledge bases to share global parameters; The internal parameter management module is used to add, delete, modify, and query parameters with a scope of a single knowledge base, enabling the sharing of internal parameters within the same knowledge base.

Images