A low-code rule engine method and platform supporting dynamic business adjustments

Abstract

The present invention provides a low-code rule engine method and platform that supports dynamic business adjustment, which relates to the field of data processing technology. The method includes: obtaining original rule data, performing structured transformation on the original rule data, and unifying format specifications; generating visual rule components, and presenting rule logic through a graphical interface, supporting business personnel to edit and modify without coding, and converting the modification results into component rule data; performing real-time parsing and verification on the component rule data to obtain operation rule data; versioning the operation rule data and storing it in a rule warehouse; matching the applicable version based on the current business context, automatically selecting the operation rule data, and loading it into the rule execution engine for execution; the present invention improves the autonomy and accuracy of the low-code rule engine.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a low-code rule engine method and platform that supports dynamic business adjustments. Background Art

[0002] In existing technologies, rule engines are widely used in enterprise information systems to abstract and configure business logic, thereby reducing the frequency of hard coding. Traditional rule engines typically rely on fixed-structure configuration files or database tables to define rule items and perform inference and execution by setting condition-action pairs (IF-THEN rules). These rules are completed by technical personnel during the initial configuration phase and embedded into system processes through pre-deployment. Some platforms have also begun to incorporate the "low-code" concept, providing graphical configuration interfaces to help business personnel complete rule development within a limited template. However, most of these platforms only support the editing and activation of static rules and lack the ability to dynamically adjust running business logic in real time.

[0003] In insurance claims review systems, rule engines are often used to determine whether a claim meets the criteria for expedited settlement. For example, the system automatically determines whether to proceed with the expedited process by setting a combination of rules based on payout amount, claim circumstances, and policy status. Traditionally, modifications to review rules require developers to downtime and deploy updates, which is sluggish for frequent business adjustments. In particular, when temporary changes in insurance regulatory policies require the immediate introduction of new judgment rules or modifications to existing ones, existing rule engines may be unable to perform these adjustments online without interrupting service. This can easily lead to delayed claims decisions, a poor customer experience, and even compliance risks. Summary of the Invention

[0004] The purpose of the present invention is to provide a low-code rule engine method and platform that supports dynamic business adjustment, aiming to solve the problems mentioned in the background technology.

[0005] In order to solve the above technical problems, the technical solutions of the present invention are as follows:

[0006] In a first aspect, a low-code rule engine method supporting dynamic business adjustment is provided, the method comprising:

[0007] Obtaining original rule data, the original rule data including a plurality of condition items and corresponding action items for business judgment, wherein each condition item and action item forms an initial rule pair;

[0008] Perform structured transformation on the original rule data, unify the format specification, and obtain structured rule data;

[0009] Generate visual rule components based on structural rule data and present rule logic through a graphical interface, allowing business personnel to edit and modify without coding, and convert the modification results into component rule data;

[0010] Analyze and verify component rule data in real time to obtain operation rule data;

[0011] Version identification of the running rule data and storage in the rule warehouse;

[0012] Based on the current business context, the applicable version is matched, the operation rule data is automatically selected, and loaded into the rule execution engine for execution.

[0013] Preferably, the original rule data is structured and converted into a unified format specification to obtain structured rule data, including:

[0014] Extract field information from each condition item in the original rule data, perform standardization based on the field type, and form a standard condition field set;

[0015] Extract execution parameters from each action item in the original rule data, perform unified processing based on the parameter format, and form a standard action parameter set;

[0016] Build structure rule data based on the standard condition field set and the standard action parameter set.

[0017] Preferably, a visual rule component is generated based on the structural rule data, and the rule logic is presented through a graphical interface, which supports business personnel to edit and modify without coding, and convert the modification results into component rule data, including:

[0018] Generate a condition node component based on a set of standard condition fields in the structure rule data, wherein the condition node component displays condition attributes in the form of an editable field;

[0019] Generate an action node component based on a set of standard action parameters in the structure rule data, wherein the action node component displays the action content in the form of a parameter configuration form;

[0020] The condition node components and action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data.

[0021] Preferably, the component rule data is parsed and verified in real time to obtain operation rule data, which is adapted to the dynamic rule loading interface in the operation environment, including:

[0022] Parse the node attributes and connection relationships in the component rule data and reconstruct a set of rule expressions that meet the execution engine standards;

[0023] Check the validity of the rule expression set. If there is a conflict or missing, an error message will be returned and the generation of rule data will be prevented.

[0024] The rule expression set that has passed the legality check is packaged to generate operation rule data, and a rule version identifier is attached to the operation rule data.

[0025] Preferably, based on the current business context matching the applicable version, the operation rule data is automatically selected and loaded into the rule execution engine for execution, including:

[0026] Receive current business context data and extract business identification information and environment attribute parameters;

[0027] Search the rule repository for matching conditions based on the business identification information, and select the running rule data version that meets the environment attribute parameters;

[0028] The filtered running rule data version is loaded into the rule execution engine memory area, triggering the rule engine to execute the corresponding rule logic to complete the business judgment.

[0029] Preferably, field information is extracted from each condition item in the original rule data, and standardized based on the field type to form a standard condition field set, including:

[0030] According to the original rule data, the field name, field type and field constraint information of each condition item are extracted to generate a preliminary field set;

[0031] Based on the preset field standardization rules, the preliminary field set is unified in field type, and fields with different sources but the same logical meaning are mapped into a standard field set;

[0032] In the standard field set, field naming conflicts are detected. If there is a naming conflict and the field types are consistent, the data source identifier is added to the field name to distinguish the names. If the field types are inconsistent, the merge is rejected and a conflict warning message is generated.

[0033] Based on the standardized field set after the naming adjustment, a standard condition field set is generated, and a mapping relationship between the original field and the standard field is established.

[0034] Preferably, the condition node components and the action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data, including:

[0035] Generate a set of conditional nodes based on the standard conditional field set, and set field editable attributes and logical expression editing entries in each conditional node;

[0036] Generate an action node set based on the standard action parameter set, and set a parameter verification template and execution configuration entry in each action node;

[0037] Establish connection relationships between conditional node sets and action node sets based on preset connection rules, allowing only node combinations that meet business logic constraints and checking whether the connections are legal in real time. If the connections violate predefined constraints, an error message will be displayed and the node connection will not be saved.

[0038] After completing the editing of the rule link graph, the changed node information and connection relationship are extracted, and incremental update data is generated and integrated into the component rule data to form the updated component rule data.

[0039] Preferably, the validity check of the regular expression set includes:

[0040] Extract the rule expression set based on the updated component rule data, and create a reference index table based on the expression reference relationship;

[0041] Based on the reference index table, each rule expression is checked for field validity. If a field is found not to exist in the standard condition field set, a field reference error is recorded and located at the specific node.

[0042] Perform integrity check on the execution parameters of the action nodes in the rule expression. If a required parameter is missing, record the parameter missing error and mark it on the parameter configuration interface.

[0043] Analyze the connectivity and logical rationality of the connection relationship of the rule link diagram. If there are circular references, isolated nodes or broken links, record the structural abnormality error;

[0044] Generates a comprehensive verification report with hierarchical prompts based on all field reference errors, parameter missing errors, and structural abnormality errors, and highlights the error nodes and error types.

[0045] Preferably, a comprehensive verification report with hierarchical prompts is generated based on all field reference errors, parameter missing errors, and structural abnormality errors, and the error nodes and error types are highlighted, including:

[0046] Extract the corresponding error node information based on the field reference error and list it in the verification summary report in the form of node number and field name;

[0047] Based on the parameter missing error, extract the missing parameter list of the action node and indicate the missing mandatory items and the corresponding action node location in the verification report;

[0048] Based on structural abnormal errors, analyze and form an error connection relationship diagram, mark the node path information with loops, isolation or broken links, and draw a schematic diagram of the abnormal links in the verification comprehensive report;

[0049] Classify and summarize field reference errors, parameter missing errors, and structural abnormality errors, assign priority identifiers, and highlight each error message based on priority.

[0050] An interactive jump function is set in the verification summary report, allowing users to click on the error item to directly locate the corresponding node position in the graphical interface.

[0051] In a second aspect, a low-code rule engine platform supporting dynamic business adjustments is provided, the platform comprising:

[0052] A raw data acquisition module is used to obtain raw rule data, wherein the raw rule data includes multiple condition items and corresponding action items for business judgment, wherein each condition item and action item form an initial rule pair;

[0053] The original data processing module is used to perform structured transformation on the original rule data, unify the format specification, and obtain structured rule data;

[0054] The rule component generation module is used to generate visual rule components based on structural rule data and present the rule logic through a graphical interface. This allows business personnel to edit and modify the rules without coding, and convert the modified results into component rule data.

[0055] A rule parsing and verification module is used to parse and verify component rule data in real time to obtain operation rule data, which is adapted to the dynamic rule loading interface in the operation environment;

[0056] The version management module is used to version the running rule data and store it in the rule warehouse. The rule warehouse is used to maintain the historical version and change records of the rules and supports the rollback and reload of any version;

[0057] The rule scheduling module is used to match the applicable version based on the current business context, automatically select the running rule data, and load it into the rule execution engine for execution.

[0058] The above solution of the present invention includes at least the following beneficial effects:

[0059] The present invention effectively solves the problems of static deployment, delayed rule adjustment, and inability to dynamically update rules in real time during operation that are common in rule engines in the prior art by providing a low-code rule engine method that supports dynamic business adjustments. In the present invention, by obtaining the original rule data and performing a structured transformation on it, unifying the format specifications, and forming structured rule data, the consistency and standardization of rule definitions are guaranteed. By further generating visual rule components based on the structured rule data and presenting the rule logic in a graphical interface, business personnel are supported to edit and modify rules without coding, which greatly improves the response speed of business adjustments and reduces the dependence of rule changes on development resources.

[0060] By performing real-time parsing and verification on the component rule data, the operating rule data adapted to the operating environment is generated, ensuring that the rule logic can be quickly and accurately converted into an executable format. After the rule data is generated, it is versioned and stored in the rule repository, supporting the maintenance of historical versions of the rules and the rollback and reloading of any version, effectively improving the flexibility and traceability of rule management. Of particular importance is that the present invention introduces a mechanism for dynamically matching applicable versions based on the current business context, which can automatically select the operating rule data version that best suits the current scenario based on different business identification information and environmental attribute parameters, and load it into the rule execution engine for immediate execution, thereby achieving dynamic effectiveness of rule logic without downtime.

[0061] Through the above-mentioned improvements, the present invention can support online dynamic adjustment of rule logic in scenarios such as insurance claims review that require high-frequency business adjustments, avoiding the problem of delayed claims decision-making due to the need for downtime deployment due to rule changes, and significantly improving customer experience. At the same time, when responding to temporary changes in insurance regulatory policies, new rules can be quickly introduced or existing rules can be adjusted, reducing compliance risks caused by untimely rule responses and improving overall flexibility, stability and compliance. Overall, the present invention has outstanding substantive characteristics and significant beneficial effects by innovating in multiple aspects such as rule data standardization, visual editing, dynamic parsing and execution, version management, and context-aware matching. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 It is a flowchart of a low-code rule engine method supporting dynamic business adjustment provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0063] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0064] like Figure 1 As shown, an embodiment of the present invention proposes a low-code rule engine method that supports dynamic business adjustment, the method comprising:

[0065] S100: Acquire original rule data, where the original rule data includes multiple condition items and corresponding action items for business judgment, wherein each condition item and action item form an initial rule pair;

[0066] S200, performing structured transformation on the original rule data, unifying the format specification, and obtaining structured rule data;

[0067] S300: Generate visual rule components based on structural rule data and present rule logic through a graphical interface, enabling business personnel to edit and modify without coding, and convert the modified results into component rule data;

[0068] S400: Analyze and verify component rule data in real time to obtain operation rule data, where the operation rule data is adapted to a dynamic rule loading interface in the operation environment;

[0069] S500: Version the running rule data and store it in a rule repository. The rule repository is used to maintain historical rule versions and change records, and supports rollback and reload of any version.

[0070] S600: Match the applicable version based on the current business context, automatically select the operation rule data, and load it into the rule execution engine for execution.

[0071] In an embodiment of the present invention, by obtaining the original rule data and performing a structured transformation on the original rule data, unifying the format specifications, and obtaining the structured rule data, it is possible to effectively unify the business logic descriptions from different sources and in different formats. Through the standardized structured rule data, a visual rule component is further generated, and the business logic is intuitively presented through a graphical interface, allowing business personnel to directly edit and adjust the rules without coding. After the editing is completed, the modified content can be converted into new component rule data in real time, effectively lowering the threshold for traditional reliance on developers to manually modify code, and improving the efficiency and accuracy of rule adjustment.

[0072] Subsequently, component rule data is parsed and verified in real time to generate operational rule data. By adapting the dynamic rule loading interface within the runtime environment to the operational rule data, new rules can be directly applied without impacting existing stable operations, avoiding the risk of service interruptions caused by rule adjustments. By versioning the operational rule data and storing it in the rule repository, the historical information of each rule version is fully preserved, supporting the rollback and reload of subsequent versions, thereby improving the flexibility and traceability of rule management.

[0073] During specific business operations, the applicable rule version can be dynamically matched based on the current business context. By extracting business identification information and environmental attribute parameters, it accurately selects the operational rule data version that meets the current conditions and quickly loads the selected version into the rule execution engine for execution, ensuring accurate rule adaptation in different business scenarios. The entire process supports dynamic loading and rapid implementation, enabling timely response to policy changes, market adjustments, or personalized needs in a frequently changing business environment, greatly enhancing adaptability to external changes and stable operation capabilities.

[0074] Through the above processing, it is possible to effectively solve technical problems existing in existing technologies such as rule adjustment relying on developers, long adjustment cycle, inability to dynamically load and resulting in downtime for updates, and realize standardized modeling, visual editing, dynamic loading and version management of rule logic in a low-code environment. It has outstanding substantive characteristics and significant beneficial effects, and is suitable for various industry application scenarios that require rapid and flexible response to business changes, such as insurance claims review, financial risk control approval, supply chain process management and other fields.

[0075] Among them, obtaining original rule data refers to extracting the rule content used for business judgment through the existing business process definitions, rule configuration files or database tables in the enterprise information, specifically including: reading the condition items and action item information related to the specific business scenario from the stored business rule configuration table. Each condition item is used to describe the judgment criteria that need to be met in a specific situation, such as whether the compensation amount is less than the set threshold, or whether the cause of the accident falls within the scope of quick claims. Each action item is used to describe the processing action that should be taken when the condition item is met, such as triggering a quick claims process, initiating a manual review instruction, etc.

[0076] During the extraction process, the original rules are mapped to their conditional and actionable terms, pairing each conditional term with its corresponding action to form initial rule pairs. These initial rule pairs maintain their original logical structure and serve as input data for subsequent processing. This approach allows for comprehensive collection of existing decision rules within the business process while avoiding disruption to the original logic and ensuring the integrity and accuracy of the original rule data captured.

[0077] In a preferred embodiment of the present invention, the original rule data is structured and standardized to obtain structured rule data, including:

[0078] Extract field information from each condition item in the original rule data, perform standardization based on the field type, and form a standard condition field set;

[0079] Extract execution parameters from each action item in the original rule data, perform unified processing based on the parameter format, and form a standard action parameter set;

[0080] Build structure rule data based on the standard condition field set and the standard action parameter set.

[0081] In an embodiment of the present invention, during the process of structurally transforming the original rule data and unifying the format specifications to obtain the structured rule data, the field information is extracted for each condition item in the original rule data and standardized based on the field type, thereby effectively unifying the rule condition definitions from different business modules or different data sources. By extracting the field name, field type, and field constraint information to form a preliminary field set, and then performing unified processing based on the preset field standardization rules, fields with the same logical meaning but different forms of expression can be standardized and mapped to form a consistent set of standard condition fields.

[0082] Similarly, by extracting execution parameters from each action item in the original rule data and standardizing them based on the parameter format, we ensure that the action items are parsed and executed according to the unified parameter template during subsequent processing, avoiding rule logic errors caused by differences in parameter definitions. By combining a standard set of condition fields with a standard set of action parameters, we construct a unified and standardized structured rule data, ensuring the consistency and accuracy of the underlying data for the subsequent generation of visual rule components.

[0083] This process not only improves the compatibility and scalability of rule data, but also effectively reduces the risk of ambiguity in data processing, ensures the consistency and standardization of rule logic modeling, lays a solid data foundation for subsequent visual editing, dynamic analysis and execution, and greatly enhances stability and flexible adaptability.

[0084] The execution parameters for each action item in the original rule data are extracted and standardized based on the parameter format to form a standard action parameter set. Specifically, in the original rule data, each action item is typically defined by a set of parameters that describe the specific requirements for action execution, such as notification type, approval node, and deadline. For each action item, its parameter fields are first parsed, including attribute information such as parameter name, data type, default value range, and whether it is required.

[0085] After extraction is complete, the parameter data is formatted uniformly. Specifically, text parameters are encoded using a standard character encoding and invalid characters are removed. Numeric parameters are formatted as floating-point numbers and standardized, with units standardized, such as RMB for the amount field. Boolean parameters are represented using the standard values of "true" or "false." Date and time parameters are expressed using the International Standard Time format. After this standardization, all action execution parameters are organized and stored according to a unified data specification, forming a standard action parameter set.

[0086] The standard action parameter set not only eliminates compatibility issues caused by format differences between different action definitions, but also lays a data foundation for subsequent visual component generation and automatic parsing of rule logic, ensuring accuracy and consistency when executing action items.

[0087] The structured rule data is constructed based on the standard condition field set and the standard action parameter set. Specifically, after the standard condition field set and the standard action parameter set are generated, a structured rule object is created based on the corresponding relationship between each condition item and action item in the original rule data. Each structured rule object contains at least the following two parts: one is the corresponding conditional logic expression in the standard condition field set, namely, the value range, comparison relationship, and combination logic relationship of each field; the other is the corresponding action execution parameter configuration in the standard action parameter set, namely, the parameter settings required for action execution and the execution method description.

[0088] When establishing structured rule data, it's necessary to standardize the relationship between conditional logic and action parameters. For example, if a conditional logic determines that the claim amount is less than 5,000 yuan and the cause of the claim is an accident, the corresponding action parameter should be configured to initiate a fast claims process and complete the review within the specified time. This binding process ensures consistency between the conditions and actions within each structured rule data, avoiding execution logic errors caused by mismatched conditions and actions.

[0089] Ultimately, all generated structured rule objects are stored and managed in a unified data format, forming a complete structured rule data set. This data set serves as the direct data source for subsequent visual rule component generation, providing a standard, stable, and scalable data foundation for graphical rule configuration, real-time rule adjustment, and dynamic execution in a low-code environment.

[0090] In a preferred embodiment of the present invention, a visual rule component is generated based on the structural rule data, and the rule logic is presented through a graphical interface, which supports business personnel to edit and modify without coding, and convert the modification results into component rule data, including:

[0091] Generate a condition node component based on a set of standard condition fields in the structure rule data, wherein the condition node component displays condition attributes in the form of an editable field;

[0092] Generate an action node component based on a set of standard action parameters in the structure rule data, wherein the action node component displays the action content in the form of a parameter configuration form;

[0093] The condition node components and action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data.

[0094] In an embodiment of the present invention, a visual rule component is generated based on the structural rule data, and the rule logic is presented through a graphical interface, allowing business personnel to edit and modify without coding, and convert the modification results into component rule data. By generating conditional node components based on the standard condition field set in the structural rule data, each conditional node component displays the conditional attributes in the form of an editable field, allowing business personnel to intuitively understand and configure the conditional logic. At the same time, by generating action node components based on the standard action parameter set and displaying the action content in the form of a parameter configuration form, the operational complexity is further reduced and the configuration accuracy is improved.

[0095] When building rule logic chains, conditional node components and action node components are logically connected to form a rule chain diagram. This graphically displays complex rule relationships, making it easier for business personnel to understand, edit, and adjust business processes within a visual interface. By adjusting and editing rule chains within the graphical interface, updated content can be extracted in real time, generating new component rule data, ensuring that business logic adjustments are quickly fed back to the execution level.

[0096] This process effectively lowers the technical barriers to traditional coding-based rule logic adjustments, shortens the time it takes to deploy rules, and improves the flexibility and maintainability of rule management. Furthermore, the graphical rule configuration method significantly reduces the error rate during rule modeling and adjustment, improving the overall intelligence and responsiveness of business process management, and possesses promising application prospects and promotional value.

[0097] The process generates a conditional node component based on the set of standard conditional fields in the structure rule data. This component displays conditional attributes as editable fields. Specifically, the process involves reading information about each standard field in the set of standard conditional fields and extracting the field name, field type, field value range, and field constraints. Based on this extracted information, a corresponding conditional node component is instantiated for each standard field. The conditional node component includes a field display area and a field editing area.

[0098] The field display area visually presents basic field attribute information, such as the field name and a brief description, to help business personnel understand the business significance of the field. The field editing area allows users to edit specific judgment conditions based on the field type, such as setting comparison symbols for field values (such as greater than, less than, and equal to), setting expected values or expected value ranges, and configuring logical relationships between fields (such as AND or OR). For numeric fields, a value input box and a comparison symbol selector are provided; for string fields, text matching or containing judgment options are provided; for date and time fields, a date selector and a time range editor are provided.

[0099] By generating conditional node components, standard conditional field sets can be visualized as editable logical judgment units in the graphical interface, making it easier for business personnel to configure and adjust rule conditional logic in an intuitive and code-free manner, thereby improving the flexibility and accuracy of rule modeling.

[0100] Based on the standard action parameter set in the structure rule data, an action node component is generated. This action node component displays the action content in the form of a parameter configuration form. Specifically, the process involves traversing each action parameter entry in the standard action parameter set and instantiating the action node component based on the action type and parameter definition. The action node component primarily includes an area for displaying the action name and an area for configuring the parameter form.

[0101] The action name display area clearly identifies the action represented by the node, such as triggering a payment, sending a reminder, or modifying status, making it easier for business personnel to quickly understand the node's functionality. The parameter configuration form area generates corresponding form input controls based on the different types of action parameters, such as text boxes, drop-down selectors, date pickers, or Boolean switches. Each parameter's form control sets default values, validation rules, and prompts based on pre-set rules, ensuring that users adhere to data integrity requirements when configuring action parameters.

[0102] After users fill out the action node parameter form in the graphical interface, the values of each parameter are recorded in real time for subsequent component rule data generation. By generating action node components, the standard action parameter set is clearly and structuredly presented in the graphical interface, allowing business personnel to intuitively and systematically configure action execution logic, further ensuring the accuracy and reliability of the rule execution phase.

[0103] In a preferred embodiment of the present invention, component rule data is parsed and verified in real time to obtain operation rule data, which is adapted to a dynamic rule loading interface in the operation environment, including:

[0104] Parse the node attributes and connection relationships in the component rule data and reconstruct a set of rule expressions that meet the execution engine standards;

[0105] Check the validity of the rule expression set. If there is a conflict or missing, an error message will be returned and the generation of rule data will be prevented.

[0106] The rule expression set that has passed the legality check is packaged to generate operation rule data, and a rule version identifier is attached to the operation rule data.

[0107] In this embodiment of the present invention, component rule data is parsed and verified in real time to obtain runtime rule data, which is then adapted to the dynamic rule loading interface within the runtime environment. This first involves parsing the node attributes and connection relationships within the component rule data to accurately reconstruct a set of rule expressions that conform to the execution engine's standards. This parsing step ensures that rule logic remains consistent and correct when translating from graphical interface expression to the execution engine's language, preventing rule failures or logical errors due to expression discrepancies.

[0108] After generating a set of rule expressions, the set is further validated. By promptly identifying conflicts or missing issues in rule definitions during the validation phase, and returning error prompts and preventing the generation of runtime rule data when issues are discovered, this effectively prevents logically incorrect rules from being deployed to the execution engine, improving the stability and reliability of overall operation. Only rule expression sets that pass all validation checks are packaged and used to generate the final runtime rule data. During the generation process, a rule version identifier is attached to ensure a reliable basis for subsequent rule version management and dynamic loading operations.

[0109] The above process enables seamless transition of rule logic from graphical editing to standard format execution. The introduction of an automatic verification mechanism significantly improves the accuracy and security of rule rollout. Especially in dynamic business adjustments, this process ensures that rule adjustments take effect in real time without disrupting existing business operations, significantly improving responsiveness to business changes and operational continuity.

[0110] This involves parsing the node attributes and connection relationships within the component rule data and reconstructing a set of rule expressions that meet the execution engine's standards. Specifically, this involves reading each node object within the component rule data, extracting the node type, node field information, and configuration parameters, and reading the connection relationships between nodes. For conditional nodes, their field edit content is extracted, including comparison logic, value ranges, and association logic. For action nodes, the specific execution parameters recorded in their parameter configuration form are extracted.

[0111] After parsing the attribute information of a single node, the trigger path from the conditional node to the action node is derived based on the connection relationship between the nodes, and the logical expression is organized according to the path sequence. Specifically, each logical path is composed of the judgment logic of the conditional node and the execution instructions of the action node. The expression order of the logical path strictly follows the direction of the node connection. If there are multiple conditional node combinations, the priority and combination method of the expression are determined by the logical symbols (such as AND or OR) in the connection relationship.

[0112] Through the above parsing process, a set of rule expressions that meet the standard syntax requirements of the execution engine is finally reconstructed, which can be directly used for subsequent legality verification and operation rule data generation, ensuring logical consistency and correctness from graphical editing to execution.

[0113] The set of rule expressions that pass the validity check is packaged to generate operational rule data, which is supplemented with a rule version identifier. Specifically, after the set of rule expressions passes the validity check, each legal rule expression is packaged into a standard rule record according to a preset format. The standard rule record contains the rule's conditional logic description, action execution instructions, and the logical relationship between the two, organized according to a unified data structure to form the operational rule data.

[0114] As rule data is generated, a rule version identifier is automatically added to each copy. This identifier typically consists of a timestamp, version number, and source information, uniquely identifying the generated batch of rule data. Recording rule version identifiers not only enables rule version management and traceability, but also supports subsequent version rollbacks, diff comparisons, and dynamic version switching.

[0115] By encapsulating a set of legal rule expressions into running rule data and adding version identifiers, the compatibility and accuracy of the rule execution layer for different business versions can be guaranteed, while enhancing the controllability and flexible adaptability of rule data in dynamic business environments.

[0116] In a preferred embodiment of the present invention, based on the current business context matching the applicable version, the operation rule data is automatically selected and loaded into the rule execution engine for execution, including:

[0117] Receive current business context data and extract business identification information and environment attribute parameters;

[0118] Search the rule repository for matching conditions based on the business identification information, and select the running rule data version that meets the environment attribute parameters;

[0119] The filtered running rule data version is loaded into the rule execution engine memory area, triggering the rule engine to execute the corresponding rule logic to complete the business judgment.

[0120] In this embodiment of the present invention, the process of automatically selecting and loading operational rule data into the rule execution engine based on the current business context and matching the applicable version to the current business context begins by receiving the current business context data and extracting business identification information and environmental attribute parameters. This processing step ensures a precise understanding of the actual characteristics of the current business request, providing the foundation for the dynamic matching of subsequent rule versions.

[0121] Subsequently, based on the extracted business identification information, matching conditions are searched in the rule repository to select the operational rule data versions that meet the environmental attribute parameter requirements. This screening mechanism ensures that the most appropriate rule version is applied to different business scenarios, avoiding business logic execution errors or anomalies caused by rule version mismatches. Furthermore, fine-grained screening based on environmental attribute parameters supports more flexible and dynamic business adaptation strategies, such as applying different rule logic to different regions, product lines, and customer types.

[0122] After selecting the eligible rule data version, it is loaded into the rule execution engine's memory area, triggering the engine to execute the corresponding rule logic, thus automating business decision-making. This dynamic rule version selection mechanism based on business context significantly enhances intelligent decision-making capabilities and adaptability, ensuring the accuracy and efficiency of business processes. It is particularly suitable for high-concurrency and high-frequency business scenarios, helping to improve overall stability and customer experience quality.

[0123] Among them, the current business context data is received, and the business identification information and environmental attribute parameters are extracted, specifically including: after receiving a request from the business, parsing the context information related to the current business processing from the request data. Business context data usually includes but is not limited to business process identification, operation user information, geographic location, request time, version number and other environmental variables. Business identification information is extracted from it to characterize the business type, sub-process identification or specific business rule application scenario to which the business request belongs, such as classification identification of auto insurance claims, health insurance claims, etc. At the same time, environmental attribute parameters are further extracted. These parameters are mainly used to describe external environment characteristics, such as operation version, client category, geographical location, access channel, etc.

[0124] The extraction process parses and categorizes data based on pre-set data extraction templates or context field mapping tables, ensuring standardized output of all business identification information and environmental attribute parameters for subsequent rule filtering modules. This process accurately extracts the contextual feature information required for rule filtering in real time without increasing the burden of business changes. This supports dynamic matching of applicable rule versions and ensures the accuracy and adaptability of business rule application.

[0125] The selected operational rule data versions are loaded into the rule execution engine's memory area, triggering the rule engine to execute the corresponding rule logic to complete the business judgment. Specifically, after selecting the appropriate operational rule data version based on the business identification information and environment attribute parameters, the data of that version is loaded into the pre-configured rule execution engine. The loading process includes initializing the rule expression set, configuring execution parameters, and preheating the cache, ensuring that the rule execution environment can immediately recognize and call the newly loaded rule set.

[0126] After the rule data is loaded, the current business request data triggers the rule engine's execution process. Based on the conditional logic defined in the rule data, the rule engine determines whether the business data meets the specific rules. Based on the judgment result, the corresponding action logic is executed, such as allowing the process to proceed, issuing an exception warning, or triggering further approval. The entire process is completed in real time in the business backend, without service interruption or manual intervention, effectively improving the application efficiency of the dynamically adjusted rules.

[0127] By quickly loading the selected rule versions and triggering their execution instantly, it not only ensures the continuity of business processing, but also enables flexible response to frequently changing business needs and external policy adjustments, significantly improving the intelligence level and response speed of the business.

[0128] In a preferred embodiment of the present invention, in the process of searching the rule repository for matching conditions based on the business identification information and screening the operating rule data versions that meet the environmental attribute parameters, version screening is performed based on the comprehensive adaptability score, including:

[0129] According to the business context data, extract the business identification information, environment attribute parameters and historical call records, and calculate the business matching degree respectively , environmental matching and historical stability ;

[0130] According to the calculated 、 and , the comprehensive fitness score Score is calculated according to the following formula:

[0131] ;

[0132] in, The comprehensive fit score represents the overall fit between the current running rule version and the business context. A higher score indicates a better fit.

[0133] Normalized weight for business matching weight coefficient, determined Contribution ratio to Score;

[0134] The normalized weight of the environmental matching weight coefficient determines Contribution ratio to Score;

[0135] is the normalized weight of the stability parameter weight coefficient, which determines Contribution ratio to Score;

[0136] For the Business identification field values such as business type, product number, etc. (from the current business context);

[0137] For the Definition of the corresponding field in the rule data of each rule version field value;

[0138] for and The similarity score between them is in the range of [0,1], where 1 indicates a perfect match and 0 indicates a complete mismatch;

[0139] The total number of business identification fields and the number of fields involved in the matching;

[0140] For the Environment attribute field values such as geographic location, version number and other environment parameters;

[0141] For the The corresponding field definition in the rule data of each rule version field value;

[0142] for and The similarity score between them is in the range of [0,1];

[0143] The total number of environment attribute fields involved in the matching.

[0144] The historical call response delay sequence is the set of response delays when calling this rule version in the past;

[0145] The variance of T is used to measure the stability of the call delay. The smaller the value, the more stable it is.

[0146] .

[0147] In this embodiment of the present invention, the entire formula calculates the final score through comprehensive calculation of three indicators:

[0148] Business matching : Compare the similarity between the current business identification field and the rule version definition field; normalize multiple fields and take the average value to reflect the adaptability of the overall business scenario.

[0149] Environmental Match : Compare the current environment parameters with the environment adaptability defined by the rules; normalize multiple fields and take the average value to reflect the consistency of the external environment.

[0150] Historical stability : Counts the response delay sequence of historical rule version calls; the smaller the variance, the more stable the rule execution and the higher the score.

[0151] Finally, the weight coefficient 、 、 Weighted summation to form comprehensive fitness Then select The highest version is used as the final execution version.

[0152] In a preferred embodiment of the present invention, field information is extracted from each condition item in the original rule data, and standardized based on the field type to form a standard condition field set, including:

[0153] According to the original rule data, the field name, field type and field constraint information of each condition item are extracted to generate a preliminary field set;

[0154] Based on the preset field standardization rules, the preliminary field set is unified in field type, and fields with different sources but the same logical meaning are mapped into a standard field set;

[0155] In the standard field set, field naming conflicts are detected. If there is a naming conflict and the field types are consistent, the data source identifier is added to the field name to distinguish the names. If the field types are inconsistent, the merge is rejected and a conflict warning message is generated.

[0156] Based on the standardized field set after the naming adjustment, a standard condition field set is generated, and a mapping relationship between the original field and the standard field is established.

[0157] In an embodiment of the present invention, field information is extracted from each condition item in the original rule data, and standardized based on the field type to form a standard condition field set. By first extracting the field name, field type, and field constraint information for each condition item, the key business logic information defined in the original rule data can be fully captured. Subsequently, based on preset field standardization rules, the extracted preliminary field set is subjected to field type standardization, allowing fields from different sources but with consistent logical meanings to be mapped to the same standard field, thereby resolving the field inconsistency issue caused by heterogeneous data sources.

[0158] After standardization, field naming conflicts are further detected in the standard field set. If there is a naming conflict and the field types are consistent, the data source identifier is added to the field name to distinguish the names. This ensures that the field points clearly in the subsequent processing process and avoids logical confusion caused by repeated naming. If there is an inconsistency in the field type, the merge is rejected and a conflict warning message is generated, ensuring data consistency and reliability in the rule modeling process. Finally, a standard conditional field set is generated based on the standardized field set after the naming adjustment, and a mapping relationship between the original field and the standard field is established. This not only retains the traceability of the original data, but also ensures high consistency and standardization of the subsequent processing process.

[0159] Through the above-mentioned standardized processing flow, not only the clarity and compatibility of rule data are improved, but also a solid foundation is laid for subsequent rule component generation, graphical editing and dynamic analysis. It significantly improves the ability to manage complex business rules and the adaptability to flexibly respond to changing business needs, and has good prospects for application promotion.

[0160] Based on preset field standardization rules, the preliminary field set is standardized in field type, mapping fields from different sources but with the same logical meaning into a standard field set. Specifically, after extracting the preliminary field set, each field is analyzed and processed according to the preset set of field standardization rules. Field standardization rules include field name standardization rules, field type standardization rules, and field unit standardization rules.

[0161] In terms of field name standardization, fields with the same logical meaning but different names are unified into standard field names through keyword matching, business dictionary comparison, etc. For example, different names such as "compensation amount", "claim amount", and "payment amount" are unified into the standard field "payment amount". In terms of field type standardization, if there are differences in the original data types of different source fields, such as one field storing the amount as a string and another as a floating-point number, they are uniformly converted to a standard numeric format. For fields with different physical units, such as a length field with both "meters" and "centimeters" units, conversion is performed according to the unified unit to ensure consistency and comparability of field values.

[0162] Through the above standardization processing, fields with different sources and formats but consistent logic are uniformly mapped to a standard field set, thereby eliminating data ambiguity in the subsequent rule generation and execution process and improving the accuracy and reliability of rule application.

[0163] Among them, in the standard field set, field naming conflicts are detected. If there is a naming conflict and the field types are consistent, the naming is distinguished by adding a data source identifier to the field name. If the field types are inconsistent, the merge is rejected and a conflict warning message is generated. Specifically, after generating the standard field set, the field entries in the set are traversed to retrieve whether there are repeated field names. If two or more fields are detected to have the same name and the field type is consistent, for example, two fields are both floating point types and named "compensation amount", then the source identifier is appended to the original field name, such as appending "_Source A" or "_Source B" suffix to the field to distinguish the names and ensure that each field can be accurately identified in subsequent processing.

[0164] If a field with the same name but different types is detected—for example, one field with the same name is numeric and the other is text—then the merge is rejected, as the conflict cannot be resolved through simple naming. This conflict warning includes the name of the conflicting field, its data type, and the source of the conflict, allowing business personnel or administrators to manually decide how to resolve the conflict based on their needs.

[0165] The above-mentioned naming conflict detection and handling mechanism ensures the internal consistency and resolvability of the standard field set, prevents rule logic execution errors caused by field naming ambiguity or type confusion, and thus improves the stability and correctness of the overall operation of the rule engine.

[0166] In a preferred embodiment of the present invention, conditional node components and action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate corresponding component rule data, including:

[0167] Generate a set of conditional nodes based on the standard conditional field set, and set field editable attributes and logical expression editing entries in each conditional node;

[0168] Generate an action node set based on the standard action parameter set, and set a parameter verification template and execution configuration entry in each action node;

[0169] Establish connection relationships between conditional node sets and action node sets based on preset connection rules, allowing only node combinations that meet business logic constraints and checking whether the connections are legal in real time. If the connections violate predefined constraints, an error message will be displayed and the node connection will not be saved.

[0170] After completing the editing of the rule link graph, the changed node information and connection relationship are extracted, and incremental update data is generated and integrated into the component rule data to form the updated component rule data.

[0171] In an embodiment of the present invention, a rule chain diagram is formed by combining condition node components and action node components through logical connections. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data. First, a condition node set is generated based on the standard condition field set, and field editable attributes and logical expression editing entries are set in each condition node, so that business personnel can easily perform personalized configuration for the conditional logic in the graphical interface. At the same time, an action node set is generated based on the standard action parameter set, and a parameter verification template and execution configuration entry are set in each action node to ensure the standardization and accuracy of the action configuration.

[0172] After node generation is complete, connections are established between the conditional node set and the action node set based on pre-set connection rules. This effectively limits unreasonable node combinations and only allows connections that comply with business logic constraints, avoiding potential logical errors. Furthermore, during the connection process, the legality of the connection is checked in real time. If a connection violates pre-defined constraints, an error message is immediately displayed and the node connection is prohibited from being saved. This prevents the introduction of invalid logic during the editing phase, improving the overall quality and stability of rule-based link data.

[0173] After editing the rule link graph, the changed node information and connection relationships can be extracted in real time to generate incremental update data, avoiding full data reconstruction and improving processing efficiency. By integrating incremental update data into the component rule data to form updated component rule data, the rule adjustment process is ensured to be efficient and reliable, and business logic modifications are synchronized to the subsequent parsing and execution stages in a timely manner, significantly improving the flexibility, controllability, and operational stability of rule maintenance.

[0174] Specifically, a connection relationship is established between the conditional node set and the action node set based on preset connection rules. Only node combinations that meet business logic constraints are allowed, and the legality of the connection is checked in real time. If the connection violates the predefined constraints, an error message is displayed and the node connection is prohibited from being saved. Specifically, after the conditional node set and the action node set are generated, the logic is controlled according to the predefined connection rules, allowing users to connect nodes in the interface. Preset connection rules include, but are not limited to: conditional nodes can only be connected to action nodes; action nodes cannot be used as upstream nodes of conditional nodes; the same conditional node can be connected to multiple action nodes, but an action node cannot be connected to multiple conditional nodes as the direct upstream, unless a compound conditional logic module is configured.

[0175] When a user initiates a connection request, a real-time check is performed to determine whether the connection complies with the aforementioned rules and constraints. If the connection complies with the rules, the connection is allowed and the connection relationship is saved. If the connection violates the rules, such as a conditional node connecting to another conditional node, or an action node connecting back to itself, an error message will immediately pop up on the interface and the connection operation will be rejected, thus preventing logical errors or invalid process paths. This process ensures the correctness of the business logic of the node combination during the rule link construction phase, reducing the risk of subsequent rule execution anomalies.

[0176] Among them, after completing the editing of the rule link graph, the changed node information and connection relationship are extracted, incremental update data is generated, and integrated into the component rule data to form the updated component rule data, specifically including: when the user completes the node addition and deletion, attribute modification or connection adjustment operation of the rule link graph in the graphical interface, based on the operation log or difference comparison mechanism, the node data and connection data that have changed compared with the original link state are extracted.

[0177] Changes to node data include modifications to node attributes, such as changes to condition fields and updates to action parameters. Changes to connection data include adding new connections or deleting existing ones. These changes are organized separately into incremental update data to avoid the performance overhead of a full data reconstruction. Subsequently, this incremental update data is merged with the existing component rule data, updating only the changed nodes or connections while maintaining the stability and continuity of the unchanged data.

[0178] By adopting the incremental update method, the response speed of rule editing and saving can be effectively improved, the data processing load can be reduced, and at the same time, it can ensure that the user's edited and modified content can be accurately synchronized to the component rule data, providing an accurate rule basis for subsequent rule parsing and execution.

[0179] In a preferred embodiment of the present invention, the validity check of the regular expression set includes:

[0180] Extract the rule expression set based on the updated component rule data, and create a reference index table based on the expression reference relationship;

[0181] Based on the reference index table, each rule expression is checked for field validity. If a field is found not to exist in the standard condition field set, a field reference error is recorded and located at the specific node.

[0182] Perform integrity check on the execution parameters of the action nodes in the rule expression. If a required parameter is missing, record the parameter missing error and mark it on the parameter configuration interface.

[0183] Analyze the connectivity and logical rationality of the connection relationship of the rule link diagram. If there are circular references, isolated nodes or broken links, record the structural abnormality error;

[0184] Generates a comprehensive verification report with hierarchical prompts based on all field reference errors, parameter missing errors, and structural abnormality errors, and highlights the error nodes and error types.

[0185] In an embodiment of the present invention, during the process of performing a validity check on a set of rule expressions, the set of rule expressions is first extracted based on the updated component rule data, and a reference index table is established according to the expression reference relationship. By establishing the reference index table, the fields and action parameters involved in each expression can be accurately recorded, ensuring that subsequent verification operations have a clear association relationship basis. For each extracted rule expression, by checking the validity of the field, if it is found that the referenced field does not exist in the standard condition field set, the field reference error is recorded in a timely manner and located at the specific node, which helps to quickly discover and correct reference omissions or errors.

[0186] The integrity of the action node execution parameters in the rule expression is checked. If a required parameter is missing, a missing parameter error is automatically recorded and annotated on the parameter configuration interface, reminding business personnel to promptly supplement the missing information, thereby avoiding rule execution anomalies caused by missing parameters. In terms of structural logic, by analyzing the connectivity and logical rationality of the connection relationships in the rule link diagram, structural anomalies such as circular references, isolated nodes, or broken links can be detected, and structural anomalies errors can be recorded in a timely manner to prevent unexpected process interruptions or the risk of dead loops during rule execution.

[0187] Finally, a comprehensive verification report with graded prompts is generated based on all field reference errors, missing parameter errors, and structural anomalies. The error nodes and error types are highlighted, allowing business personnel to intuitively understand the source and severity of the problem. This meticulous legality verification process significantly improves the accuracy, robustness, and execution reliability of rule data, greatly reducing the probability of logical vulnerabilities or business anomalies after the rules are launched, and significantly enhancing overall stability and business continuity.

[0188] Among them, according to the reference index table, the field validity of each rule expression is checked. If it is found that the field does not exist in the standard condition field set, the field reference error is recorded and located at the specific node. Specifically, after parsing the component rule data and reconstructing the rule expression set, a reference index relationship between the rule expression and the condition field is established, and the field name and corresponding node referenced by each rule expression are recorded.

[0189] When performing field validity checks, the system traverses each field name involved in the rule expression and checks whether a corresponding definition exists in the standard condition field set. If a field is not registered in the standard condition field set, it indicates an illegal reference. The error is recorded in the error list, and the specific condition node or action node that references the field is marked to facilitate subsequent problem identification by business personnel.

[0190] Through the above verification, illegal field reference problems caused by field omissions, spelling errors or version inconsistencies can be discovered in a timely manner, thereby preventing logical anomalies or execution failures before the rule is officially run, and improving overall reliability.

[0191] The integrity of the action node execution parameters in the rule expression is checked. If a required parameter is missing, a missing parameter error is recorded and noted on the parameter configuration interface. Specifically, after extracting the rule expression set, each action node is checked against the parameter configuration template defined in the action node component. The verification process includes checking whether each required parameter has been correctly filled in or configured and whether it meets the data type and value range requirements.

[0192] If it is detected that a required parameter in an action node is not filled in, is empty, or has an incorrect format, the error will be recorded in the error list, and the missing or incorrect parameter items will be clearly marked in the parameter configuration area of the graphical interface through highlighting, prompt bubbles, etc., so that business personnel can find and correct them in time.

[0193] By performing parameter integrity checks on action nodes, we can effectively avoid action execution failures or exceptions due to missing parameters or configuration errors, greatly improving the stability and fault tolerance of the rule execution process.

[0194] The connectivity and logical rationality of the rule link graph are analyzed. If there are circular references, isolated nodes, or broken links, a structural anomaly error is recorded. Specifically, after the rule link graph is constructed, the overall node connection relationship is tested using a connectivity analysis algorithm. The test content includes: whether there are isolated nodes that cannot reach the action node from the starting node; whether there are circular reference paths where nodes connect to themselves or form closed loops; and whether there are broken links where some logical links cannot be closed-loop executed due to broken connections.

[0195] When any of the above structural anomalies are detected, they are immediately recorded in the structural anomaly error list, and the abnormal node or path location is visually displayed through interface highlighting and connection warning icons. Business personnel can adjust node connections or correct the logical structure based on the prompts to ensure that the rule chain meets the correct execution process requirements.

[0196] Through real-time detection and feedback of the structural integrity and logical rationality of the rule chain diagram, the risk of business processing failure caused by logical design defects is greatly reduced, and the robustness and maintainability of the overall rules are improved.

[0197] In a preferred embodiment of the present invention, a comprehensive verification report with hierarchical prompts is generated based on all field reference errors, parameter missing errors, and structural abnormality errors, and the error nodes and error types are highlighted, including:

[0198] Extract the corresponding error node information based on the field reference error and list it in the verification summary report in the form of node number and field name;

[0199] Based on the parameter missing error, extract the missing parameter list of the action node and indicate the missing mandatory items and the corresponding action node location in the verification report;

[0200] Based on structural abnormal errors, analyze and form an error connection relationship diagram, mark the node path information with loops, isolation or broken links, and draw a schematic diagram of the abnormal links in the verification comprehensive report;

[0201] Classify and summarize field reference errors, parameter missing errors, and structural abnormality errors, assign priority identifiers, and highlight each error message based on priority.

[0202] An interactive jump function is set in the verification summary report, allowing users to click on the error item to directly locate the corresponding node position in the graphical interface.

[0203] In an embodiment of the present invention, a verification report with hierarchical prompts is generated based on all field reference errors, parameter missing errors, and structural abnormality errors. In the process of highlighting the error nodes and error types, the corresponding error node information is first extracted based on the field reference errors, and accurately listed in the verification report in the form of node numbers and field names to ensure that business personnel can clearly understand the source and specific location of each error. At the same time, a list of missing parameters of the action node is extracted based on the parameter missing errors, and the missing required items and the corresponding action node positions are indicated in the verification report to help users quickly locate and supplement the necessary parameters.

[0204] In terms of structural anomaly errors, we analyze and form an error connection diagram, annotate node paths with loops, isolation, or broken links, and further draw a schematic diagram of the abnormal links in the verification report, so that the overall rule structure problems can be visualized, making it easier for business personnel to quickly understand and correct logical defects. To improve the usability and urgency management of verification reports, field reference errors, parameter missing errors, and structural anomaly errors are categorized and summarized separately, and assigned priority labels. This ensures that business personnel can arrange the repair sequence according to the severity of the problem and optimize debugging efficiency.

[0205] An interactive jump function is provided in the verification summary report, allowing users to click on an error item and directly navigate to the corresponding node location in the graphical interface, thereby significantly reducing the time cost of manual search and troubleshooting and improving the efficiency of rule adjustment and correction. Through the above mechanism, the present invention not only greatly improves the speed of error discovery and location, but also effectively reduces the maintenance difficulty caused by the increased complexity of rules, improves the overall experience of rule configuration and management, and further enhances the usability and intelligence level in highly complex business scenarios.

[0206] Among them, according to the structural abnormality errors, an error connection relationship diagram is formed by analysis, the node path information with loops, isolation or broken links is marked, and a schematic diagram of the abnormal links is drawn in the verification comprehensive report. Specifically, after completing the connectivity and logical rationality analysis of the regular link diagram, for the detected structural abnormality errors, the node and connection relationship information is sorted according to the error type to form an error connection relationship diagram.

[0207] For detected circular reference errors, record the node set and connection path that cause the loop to be formed, and identify the loop structure with a closed-loop path in the error connection relationship diagram, highlighting the nodes and connections that cause the loop; for isolated node errors, identify the conditional nodes or action nodes that have not formed an effective connection with any action node or start node, and highlight the isolated nodes separately in the connection relationship diagram, marking their unconnected status; for broken link errors, analyze the nodes and connection breakpoints with interrupted positions in the link, and draw interruption marks in the connection relationship diagram to clearly indicate the specific location where the link cannot be closed.

[0208] Embedding the above-mentioned error connection diagram as an abnormal link diagram in the verification report allows business personnel to intuitively understand the specific location of structural anomalies, error types, and associated node relationships when reviewing the report, facilitating subsequent rapid correction and reconstruction of the correct rule link structure. By drawing an abnormal link diagram, the labor cost of troubleshooting complex rule logic errors is effectively reduced, and the maintainability and debugging efficiency of rule modeling are improved.

[0209] Field reference errors, missing parameter errors, and structural anomaly errors are categorized and summarized separately, assigned priority identifiers, and displayed with each type of error information highlighted according to priority. Specifically, after completing all rule verifications, the collected error information of different types is categorized and organized. Field reference errors primarily include references to undefined fields or misspellings of field references; missing parameter errors primarily include required parameters not configured in action nodes or invalid configuration content; structural anomaly errors primarily include circular references, isolated nodes, or broken link structures.

[0210] Based on the classification and organization, each type of error is assigned a predefined priority. Priority definitions follow risk assessment principles. For example, structural anomalies are given the highest priority because they may render the entire rule chain inoperable; missing parameter errors are given medium-high priority because they affect the correct execution of action nodes; and field reference errors are given medium priority because they may cause deviations in judgment logic.

[0211] In the verification report, each error is highlighted based on its priority, using different methods such as color, bold font, and flashing borders to differentiate severity. This helps guide business personnel to prioritize issues that have the greatest impact on stability. High-priority errors are ranked higher in the verification report, ensuring they receive priority attention and fixes before rule adjustments and releases, improving overall rule quality and the success rate of online releases.

[0212] Through the above-mentioned classification, prioritization and highlighting mechanism, the rule review work can be made more efficient and standardized, helping business personnel to efficiently identify and prioritize the correction of key errors when faced with complex rules, thereby effectively ensuring the stable operation of the rule engine and business continuity.

[0213] An embodiment of the present invention further provides a low-code rule engine platform that supports dynamic business adjustments, the platform comprising:

[0214] A raw data acquisition module is used to obtain raw rule data, wherein the raw rule data includes multiple condition items and corresponding action items for business judgment, wherein each condition item and action item form an initial rule pair;

[0215] The original data processing module is used to perform structured transformation on the original rule data, unify the format specification, and obtain structured rule data;

[0216] The rule component generation module is used to generate visual rule components based on structural rule data and present the rule logic through a graphical interface. This allows business personnel to edit and modify the rules without coding, and convert the modified results into component rule data.

[0217] A rule parsing and verification module is used to parse and verify component rule data in real time to obtain operation rule data, which is adapted to the dynamic rule loading interface in the operation environment;

[0218] The version management module is used to version the running rule data and store it in the rule warehouse. The rule warehouse is used to maintain the historical version and change records of the rules and supports the rollback and reload of any version;

[0219] The rule scheduling module is used to match the applicable version based on the current business context, automatically select the running rule data, and load it into the rule execution engine for execution.

[0220] It should be noted that this system is a system corresponding to the above method, and all implementation methods in the above method embodiment are applicable to this embodiment and can achieve the same technical effects.

[0221] An embodiment of the present invention further provides a computing device comprising: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the above-described method. All implementations in the above-described method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0222] The embodiment of the present invention further provides a computer-readable storage medium storing instructions, which, when executed on a computer, causes the computer to execute the above-described method. All implementations in the above-described method embodiment are applicable to this embodiment and can achieve the same technical effects.

[0223] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A low-code rule engine method that supports dynamic business adjustments, characterized in that: The method comprises: Obtaining original rule data, the original rule data including a plurality of condition items and corresponding action items for business judgment, wherein each condition item and action item forms an initial rule pair; Perform structured transformation on the original rule data, unify the format specification, and obtain structured rule data; Generate visual rule components based on structural rule data and present rule logic through a graphical interface, allowing business personnel to edit and modify without coding, and convert the modification results into component rule data; Component rule data is parsed and verified in real time to obtain operation rule data. The specific steps include: Parse the node attributes and connection relationships in the component rule data and reconstruct a set of rule expressions that meet the execution engine standards; Check the validity of the rule expression set. If there is a conflict or missing, an error message will be returned and the generation of rule data will be prevented. Packing the rule expression set that has passed the legality check to generate operation rule data, wherein the operation rule data is supplemented with a rule version identifier; Version identification of the running rule data and storage in the rule warehouse; Based on the current business context, the applicable version is matched, and the operation rule data is automatically selected and loaded into the rule execution engine for execution. The specific steps include: Receive current business context data and extract business identification information and environment attribute parameters; Search the rule repository for matching conditions based on the business identification information and select the running rule data version that meets the environment attribute parameters. The specific steps include: Based on the business context data, business identification information, environment attribute parameters and historical call records are extracted to calculate the business matching degree, environment matching degree and historical stability respectively; Based on the business matching, environment matching and historical stability, a weighted sum is performed according to the preset weight coefficient to calculate the comprehensive adaptability score; The version with the highest comprehensive adaptability score is selected as the final running rule data version; The service matching degree is obtained by comparing the similarity between the current service identification field and the rule version definition field, and performing multi-field normalization and averaging calculation; The environmental matching degree is obtained by comparing the current environmental parameters with the environmental adaptability defined by the rules and performing multi-field normalization and averaging calculation; The historical stability is obtained by counting the response delay sequence of historical calls of the rule version, calculating the variance, adding 1 to the variance and taking the inverse of the variance; The filtered running rule data version is loaded into the rule execution engine memory area, triggering the rule engine to execute the corresponding rule logic to complete the business judgment.

2. A low-code rule engine method supporting dynamic business adjustment according to claim 1, characterized in that: The original rule data is structured and standardized to obtain structured rule data, including: Extract field information from each condition item in the original rule data, perform standardization based on the field type, and form a standard condition field set; Extract execution parameters from each action item in the original rule data, perform unified processing based on the parameter format, and form a standard action parameter set; Build structure rule data based on the standard condition field set and the standard action parameter set.

3. A low-code rule engine method supporting dynamic business adjustment according to claim 2, characterized in that: Generate visual rule components based on structural rule data and present rule logic through a graphical interface, allowing business personnel to edit and modify without coding, and convert the modification results into component rule data, including: Generate a condition node component based on a set of standard condition fields in the structure rule data, wherein the condition node component displays condition attributes in the form of an editable field; Generate an action node component based on a set of standard action parameters in the structure rule data, wherein the action node component displays the action content in the form of a parameter configuration form; The condition node components and action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data.

4. A low-code rule engine method supporting dynamic business adjustment according to claim 1, characterized in that: Extract field information from each condition item in the original rule data and perform standardization based on the field type to form a standard condition field set, including: According to the original rule data, the field name, field type and field constraint information of each condition item are extracted to generate a preliminary field set; Based on the preset field standardization rules, the preliminary field set is unified in field type, and fields with different sources but the same logical meaning are mapped into a standard field set; In the standard field set, field naming conflicts are detected. If there is a naming conflict and the field types are consistent, the data source identifier is added to the field name to distinguish the names. If the field types are inconsistent, the merge is rejected and a conflict warning message is generated. Based on the standardized field set after the naming adjustment, a standard condition field set is generated, and a mapping relationship between the original field and the standard field is established.

5. A low-code rule engine method supporting dynamic business adjustment according to claim 4, characterized in that: The condition node components and action node components are combined through logical connections to form a rule chain diagram. After the user edits and adjusts the rule chain diagram in the graphical interface, the updated content is extracted to generate the corresponding component rule data, including: Generate a set of conditional nodes based on the standard conditional field set, and set field editable attributes and logical expression editing entries in each conditional node; Generate an action node set based on the standard action parameter set, and set a parameter verification template and execution configuration entry in each action node; Establish connection relationships between conditional node sets and action node sets based on preset connection rules, allowing only node combinations that meet business logic constraints and checking whether the connections are legal in real time. If the connections violate predefined constraints, an error message will be displayed and the node connection will not be saved. After completing the editing of the rule link graph, the changed node information and connection relationship are extracted, and incremental update data is generated and integrated into the component rule data to form the updated component rule data.

6. A low-code rule engine method supporting dynamic business adjustment according to claim 5, characterized in that: Verify the validity of the regular expression set, including: Extract the rule expression set based on the updated component rule data, and create a reference index table based on the expression reference relationship; Based on the reference index table, each rule expression is checked for field validity. If a field is found not to exist in the standard condition field set, a field reference error is recorded and located at the specific node. Perform integrity check on the execution parameters of the action nodes in the rule expression. If a required parameter is missing, record the parameter missing error and mark it on the parameter configuration interface. Analyze the connectivity and logical rationality of the connection relationship of the rule link diagram. If there are circular references, isolated nodes or broken links, record the structural abnormality error; Generates a comprehensive verification report with hierarchical prompts based on all field reference errors, parameter missing errors, and structural abnormality errors, and highlights the error nodes and error types.

7. A low-code rule engine method supporting dynamic business adjustment according to claim 6, characterized in that: Generates a comprehensive verification report with hierarchical prompts based on all field reference errors, parameter missing errors, and structural abnormality errors, and highlights the error nodes and error types, including: Extract the corresponding error node information based on the field reference error and list it in the verification summary report in the form of node number and field name; Based on the parameter missing error, extract the missing parameter list of the action node and indicate the missing mandatory items and the corresponding action node location in the verification report; Based on structural abnormal errors, analyze and form an error connection relationship diagram, mark the node path information with loops, isolation or broken links, and draw a schematic diagram of the abnormal links in the verification comprehensive report; Classify and summarize field reference errors, parameter missing errors, and structural abnormality errors, assign priority identifiers, and highlight each error message based on priority. An interactive jump function is set in the verification summary report, allowing users to click on the error item to directly locate the corresponding node position in the graphical interface.

8. A low-code rule engine platform that supports dynamic business adjustments, characterized by: Applied to the method according to any one of claims 1 to 7, the platform comprises: A raw data acquisition module is used to obtain raw rule data, wherein the raw rule data includes multiple condition items and corresponding action items for business judgment, wherein each condition item and action item form an initial rule pair; The original data processing module is used to perform structured transformation on the original rule data, unify the format specification, and obtain structured rule data; The rule component generation module is used to generate visual rule components based on structural rule data and present the rule logic through a graphical interface. This allows business personnel to edit and modify the rules without coding, and convert the modified results into component rule data. A rule parsing and verification module is used to parse and verify component rule data in real time to obtain operation rule data, which is adapted to the dynamic rule loading interface in the operation environment; The version management module is used to version the running rule data and store it in the rule warehouse. The rule warehouse is used to maintain the historical version and change records of the rules and supports the rollback and reload of any version; The rule scheduling module is used to match the applicable version based on the current business context, automatically select the running rule data, and load it into the rule execution engine for execution.

Images