Low-code rule engine method and platform supporting dynamic service adjustment

Abstract

The invention provides a low-code rule engine method and platform supporting dynamic service adjustment, and relates to the technical field of data processing.The method comprises the steps that original rule data are obtained, and the original rule data are subjected to structured conversion and unified format specification; generating a visual rule component, presenting rule logic through a graphical interface, supporting business personnel to edit and modify without coding, and converting a modification result into component rule data; performing real-time analysis and verification on the component rule data to obtain operation rule data; performing version identification on the operation rule data, and storing the operation rule data in a rule warehouse; based on the current service context, matching an applicable version, automatically selecting the operation rule data, and loading the operation rule data to a rule execution engine for execution; the autonomy and accuracy of the low-code rule engine are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and particularly to a low-code rule engine method and platform supporting dynamic service adjustment. Background Art

[0002] In the prior art, rule engines are widely used in enterprise information systems to abstract and configure business logics, thereby reducing the frequency of hard coding. Traditional rule engines usually rely on configuration files or database tables with fixed structures to define rule items and perform reasoning and execution through setting condition-action pairs (IF-THEN rules). These rules are completed by technicians in the initial configuration stage and embedded in the system process through pre-deployment. Some platforms have also started to introduce the concept of "low code" and provide graphical configuration interfaces to help business personnel complete rule formulation under limited templates. However, most of these platforms only support the editing and activation of static rules and lack the ability to support real-time dynamic adjustment of running business logics.

[0003] In an insurance claim review system, a rule engine is often used to determine whether a claim meets the conditions for rapid claim settlement. For example, the system will set a series of rule combinations of claim amounts, accident situations, policy status, etc. to automatically decide whether to enter the rapid process. In the traditional solution, the modification of review rules requires developers to stop the machine for deployment and update, which seems lagging for high-frequency business adjustment scenarios. Especially when there are temporary changes in insurance regulatory policies and new judgment rules need to be introduced immediately or existing rules need to be modified, the existing rule engines may not be able to make online adjustments without interrupting services, easily leading to lagging claim decisions, degraded 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 supporting dynamic service adjustment, aiming to solve the problems mentioned in the background art.

[0005] To solve the above technical problems, the technical solution of the present invention is as follows:

[0006] In a first aspect, a low-code rule engine method supporting dynamic service adjustment, the method includes:

[0007] Obtain original rule data, where the original rule data includes multiple condition items for business judgment and corresponding action items, and an initial rule pair is formed between each condition item and action item;

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

[0009] Generate a visual rule component according to the structured rule data, and present the rule logic through a graphical interface, supporting business personnel to edit and modify without coding, and convert the modification results into component rule data;

[0010] Parse and verify the component rule data in real time to obtain the running rule data;

[0011] Add a version identifier to the running rule data and store it in the rule repository;

[0012] Based on the current business context, match the applicable version, automatically select the running rule data, and load it into the rule execution engine for execution.

[0013] Preferably, perform a structured transformation on the original rule data, unify the format specifications, and obtain the structured rule data, including:

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

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

[0016] Construct the structured rule data according to the standard condition field set and the standard action parameter set.

[0017] Preferably, generate a visual rule component according to the structured rule data, and present the rule logic through a graphical interface, supporting business personnel to edit and modify without coding, and convert the modification results into component rule data, including:

[0018] Generate a condition node component according to the standard condition field set in the structured rule data, and the condition node component displays the condition attributes in the form of editable fields;

[0019] Generate an action node component according to the standard action parameter set in the structured rule data, and the action node component displays the action content in the form of a parameter configuration form;

[0020] Combine the condition node component and the action node component through logical connection lines to form a rule link diagram. After the user edits and adjusts the rule link diagram in the graphical interface, extract its updated content to generate the corresponding component rule data.

[0021] Preferably, parse and verify the component rule data in real time to obtain the running rule data, and the running rule data adapts to the dynamic rule loading interface in the running environment, including:

[0022] Parse the node attributes and connection relationships in the component rule data, and reconstruct a set of rule expressions that conform to the execution engine standard;

[0023] Perform a legality check on the set of rule expressions. If there are conflicts or omissions, return an error message and prevent the generation of running rule data;

[0024] Package the set of rule expressions that pass the legality check to generate running rule data, and attach a rule version identifier to the running rule data.

[0025] Preferably, based on the current business context, match the applicable version, automatically select the running rule data, and load it into the rule execution engine for execution, including:

[0026] Receive the current business context data, and extract the business identification information and environmental attribute parameters;

[0027] Retrieve the matching conditions in the rule repository according to the business identification information, and filter out the version of the running rule data that conforms to the environmental attribute parameters;

[0028] Load the filtered version of the running rule data into the memory area of the rule execution engine, and trigger the rule engine to execute the corresponding rule logic to complete the business judgment.

[0029] Preferably, extract the field information for each condition item in the original rule data, and perform standardization processing based on the field type to form a standard condition field set, including:

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

[0031] Based on the preset field standardization rules, perform a unified processing of the field types in the preliminary field set, and map fields with the same logical meaning but different sources to the standard field set;

[0032] In the standard field set, detect field naming conflicts. If there are naming conflicts and the field types are the same, distinguish the naming by adding a data source identifier to the field name. If the field types are different, reject the merge and generate a conflict warning message;

[0033] Generate a standard condition field set according to the standardized field set after completing the naming adjustment, and establish the mapping relationship between the original fields and the standard fields.

[0034] Preferably, combine the condition node components and the action node components through logical connection lines to form a rule link diagram. After the user edits and adjusts the rule link diagram in the graphical interface, extract its updated content to generate the corresponding component rule data, including:

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

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

[0037] Establish a connection relationship between the set of conditional nodes and the set of action nodes based on the preset connection rules, only allow node combinations that meet the business logic constraints, and detect in real time whether the connection is legal. If the connection violates the predefined constraints, an error is prompted and the node connection is prohibited from being saved;

[0038] After completing the editing of the rule link diagram, extract the changed node information and connection relationship, generate incremental update data, and integrate it into the component rule data to form the updated component rule data.

[0039] Preferably, perform a legality check on the rule expression set, including:

[0040] Extract the rule expression set according to the updated component rule data, and establish a reference index table according to the expression reference relationship;

[0041] According to the reference index table, perform a field validity check on each rule expression. If it is found that a field does not exist in the standard condition field set, record the field reference error and locate it to the specific node;

[0042] Perform an 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] Perform a connectivity and logical rationality analysis on the connection relationship of the rule link diagram. If there are circular references, isolated nodes or broken links, record the structural anomaly error;

[0044] Generate a verification comprehensive report with hierarchical prompts according to all field reference errors, parameter missing errors and structural anomaly errors, and indicate the error nodes and error types in a highlighted manner.

[0045] Preferably, generate a verification comprehensive report with hierarchical prompts according to all field reference errors, parameter missing errors and structural anomaly errors, and indicate the error nodes and error types in a highlighted manner, including:

[0046] Extract the corresponding error node information according to the field reference error, and list it in the verification comprehensive report in the form of the node number and the field name;

[0047] Extract the missing parameter list of the action node according to the parameter missing error, and indicate the missing required item and the corresponding action node position in the verification comprehensive report;

[0048] According to the structural anomaly error, 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 link in the verification comprehensive report;

[0049] Classify and summarize the field reference error, parameter missing error, and structural anomaly error respectively, assign a priority identifier, and highlight various error information according to the priority;

[0050] Set an interactive jump function in the verification comprehensive report to support users to click on the error item and directly locate to the corresponding node position in the graphical interface.

[0051] In a second aspect, a low-code rule engine platform supporting dynamic service adjustment, the platform includes:

[0052] An original data acquisition module, used to obtain original rule data, the original rule data includes multiple condition items and corresponding action items for business judgment, and an initial rule pair is formed between each condition item and action item;

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

[0054] A rule component generation module, used to generate visual rule components according to the structured rule data, present the rule logic through a graphical interface, support business personnel to edit and modify without coding, and convert the modification result into component rule data;

[0055] A rule parsing and verification module, used to perform real-time parsing and verification on the component rule data to obtain running rule data, and the running rule data adapts to the dynamic rule loading interface in the running environment;

[0056] A version management module, used to perform version identification on the running rule data and store it in the rule warehouse, and the rule warehouse is used to maintain the rule historical versions and change records, supporting rollback and reload of any version;

[0057] A rule scheduling module, 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 has at least the following beneficial effects:

[0059] The present invention provides a low-code rule engine method supporting dynamic service adjustment, effectively solving the problems commonly existing in the prior art rule engines, such as static deployment, lagging rule adjustment, and inability to update rules in real time during operation. In the present invention, by obtaining the original rule data and performing structured transformation on it, unifying the format specifications, and forming structured rule data, the consistency and standardization of rule definitions are ensured. By further generating visual rule components based on the structured rule data and presenting the rule logic in a graphical interface, it supports business personnel to edit and modify rules without coding, greatly improving the response speed of business adjustment and reducing the dependence on development resources for rule changes.

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

[0061] Through the above improvements, the present invention can support the online dynamic adjustment of rule logic in scenarios such as insurance claim review that require high-frequency business adjustment, avoiding the problem of lagging claim decision-making caused by downtime deployment due to rule changes, and significantly improving the customer experience. At the same time, when dealing with temporary changes in insurance regulatory policies, it can quickly introduce new rules or adjust existing rules, reducing the compliance risk caused by untimely rule response and enhancing the overall flexibility, stability, and compliance. Generally speaking, the present invention innovates from multiple aspects such as rule data standardization, visual editing, dynamic parsing and execution, version management, and context-aware matching, and has prominent substantive features and significant beneficial effects. Brief Description of the Drawings

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

[0063] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the 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. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be fully conveyed to those skilled in the art.

[0064] As Figure 1 shown, an embodiment of the present invention proposes a low-code rule engine method for supporting dynamic service adjustment, and the method includes:

[0065] S100. Obtain original rule data, where the original rule data includes a plurality of condition items for service judgment and corresponding action items, and an initial rule pair is formed between each condition item and the action item;

[0066] S200. Perform structured transformation on the original rule data to unify the format specification and obtain structured rule data;

[0067] S300. Generate a visual rule component according to the structured rule data, and present the rule logic through a graphical interface, supporting business personnel to edit and modify without coding, and convert the modification result into component rule data;

[0068] S400. Perform real-time parsing and verification on the component rule data to obtain running rule data, and the running rule data adapts to the dynamic rule loading interface in the running environment;

[0069] S500. Perform version identification on the running rule data and store it in the rule repository, where the rule repository is used to maintain the rule historical versions and change records, and supports rollback and reload of any version;

[0070] S600. Based on the current business context, match the applicable version, automatically select the running rule data, and load it into the rule execution engine for execution.

[0071] In the embodiment of the present invention, by obtaining the original rule data and performing structured transformation on the original rule data to unify the format specification and obtain 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, enabling 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 reducing the threshold of traditional manual code modification by developers and improving the efficiency and accuracy of rule adjustment.

[0072] Subsequently, the component rule data is parsed and verified in real time to generate the running rule data. By adapting to the dynamic rule loading interface in the running environment in the running rule data, it can ensure that new rules can be directly applied without affecting the existing stable operation, avoiding the risk of service interruption caused by rule adjustment. By versioning the running rule data and storing it in the rule repository, the historical information of each version of the rule can be completely retained, supporting the rollback and reload of subsequent versions, thereby enhancing the flexibility and traceability of rule management.

[0073] During the specific business operation process, it is possible to dynamically match the applicable rule version based on the current business context. By extracting the business identification information and environmental attribute parameters, the version of the running rule data that meets the current conditions is accurately screened, and the selected version is quickly loaded into the rule execution engine for execution, ensuring the accuracy of rule adaptation in different business scenarios. The entire process supports dynamic loading and quick effectiveness, and can respond in a timely manner to policy changes, market adjustments, or personalized needs in a business environment with high-frequency changes, greatly enhancing the adaptability to external changes and the stable operation ability.

[0074] Through the above processing, it can effectively solve the technical problems existing in the prior art, such as rule adjustment relying on developers, long adjustment cycles, and the need for downtime updates due to inability to dynamically load. It realizes the standardized modeling, visual editing, dynamic loading, and version management of rule logic in a low-code environment, has prominent substantive features and significant beneficial effects, and is applicable to various industry application scenarios that need to quickly and flexibly respond to business changes, such as insurance claim review, financial risk control approval, supply chain process management, and other fields.

[0075] Among them, obtaining the original rule data refers to extracting the rule content 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 items information related to specific business scenarios 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 claim amount is less than the set threshold, and whether the cause of the accident belongs to the category of rapid claim settlement. Each action item is used to describe the processing action that should be taken when the condition item is met, such as triggering the rapid claim settlement process, initiating a manual review instruction, etc.

[0076] During the extraction process, the original rules form a corresponding relationship between the condition items and the action items, that is, each condition item is paired with the corresponding action item to form an initial rule pair. These initial rule pairs maintain the original logical structure and serve as the input data source in subsequent processing. In this way, the existing decision rules in the business process can be comprehensively collected, while avoiding damage to the original logic, ensuring the integrity and accuracy of the acquisition of the original rule data.

[0077] In a preferred embodiment of the present invention, the original rule data is structurally transformed and the format specification is unified to obtain structured rule data, including:

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

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

[0080] Construct structured rule data according to the standard condition field set and the standard action parameter set.

[0081] In the embodiment of the present invention, in the process of structurally transforming the original rule data and unifying the format specification to obtain structured rule data, by extracting field information for each condition item in the original rule data and performing standardization processing based on the field type, it is possible to effectively unify the rule condition definitions from different business modules or different data sources. By extracting field names, field types, and field constraint information, a preliminary field set is formed, and on this basis, unified processing is carried out according to the preset field standardization rules, so that fields with the same logical meaning but different presentation forms can be standardized and mapped to form a standard condition field set with good consistency.

[0082] Similarly, by extracting execution parameters for each action item in the original rule data and performing unification processing based on the parameter format, it can be ensured that the action items can be parsed and executed according to a unified parameter template in subsequent processing, avoiding rule logic errors caused by parameter definition differences. Through the combination of the standard condition field set and the standard action parameter set, a unified and standardized structured rule data is constructed, ensuring the consistency and accuracy of the basic data for generating subsequent visual rule components.

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

[0084] Among them, extracting execution parameters for each action item in the original rule data and performing unification processing based on the parameter format to form a standard action parameter set specifically includes: in the original rule data, each action item is usually defined by a set of parameters, and these parameters describe the specific requirements for action execution, such as notification type, approval node, time limit for completion, etc. For each action item, first parse its parameter fields, including attribute information such as parameter name, data type, default value range, and whether it is a required item.

[0085] After the extraction is completed, the parameter data is uniformly formatted. Specifically, for text-type parameters, a standard character encoding is uniformly adopted and invalid characters are cleaned; for numerical-type parameters, they are uniformly processed into floating-point formats and unit standardization is performed. For example, the amount fields are unified into the unit of RMB yuan; for boolean-type parameters, the standard values of "true" or "false" are uniformly adopted; for date and time-type parameters, the international standard time format is uniformly used for expression. After the above normalization process, the execution parameters of all action items 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 the compatibility problems caused by format differences between different action definitions, but also lays a data foundation for the subsequent generation of visualization components and the automatic parsing of rule logic, ensuring the accuracy and consistency during the execution of action items.

[0087] Among them, according to the standard condition field set and the standard action parameter set, structural rule data is constructed, specifically including: after the generation of the standard condition field set and the standard action parameter set is completed, according to the corresponding relationship between each condition item and action item in the original rule data, a structural rule object is established. Each structural rule object contains at least the following two parts: one is the corresponding conditional logic expression in the standard condition field set, that is, the value range, comparison relationship, and combined logical relationship of each field; the other is the corresponding action execution parameter configuration in the standard action parameter set, that is, the parameter settings required for action execution and the description of the execution method.

[0088] During the process of establishing the structural rule data, it is necessary to standardize the binding of the association relationship between the conditional logic and the action parameters. For example, if a certain conditional logic determines that the indemnity amount is less than 5,000 yuan and the cause of the accident belongs to the accidental accident type, the corresponding action parameter should be configured to start the fast claim settlement process and complete the review within the specified time. The binding process ensures the consistency of conditions and actions within each piece of structural rule data, avoiding execution logic errors caused by mismatches between conditions and actions.

[0089] Finally, all the formed structural rule objects are stored and managed according to a unified data format, forming a complete set of structural rule data. This set serves as the direct data source for the subsequent generation of visualization rule components, providing a standard, stable, and extensible data foundation for graphical rule configuration, rule real-time adjustment, and dynamic execution in a low-code environment.

[0090] In a preferred embodiment of the present invention, a visual rule component is generated according to the structural rule data, and the rule logic is presented through a graphical interface, supporting business personnel to edit and modify without coding, and converting the modification result into component rule data, including:

[0091] According to the standard condition field set in the structural rule data, a condition node component is generated, and the condition attributes are displayed in the form of editable fields for the condition node component;

[0092] According to the standard action parameter set in the structural rule data, an action node component is generated, and the action content is displayed in the form of a parameter configuration form for the action node component;

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

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

[0095] When constructing the rule logic link, by logically connecting and combining the condition node component and the action node component to form a rule link diagram, the complex rule relationship is presented in a graphical manner, facilitating business personnel to understand, edit, and adjust the business process in the visual interface. By adjusting and editing the rule link in the graphical interface, the updated content can be extracted in real time to generate new component rule data, ensuring that the business logic adjustment can be quickly reflected to the execution level.

[0096] Through this process, the technical threshold for adjusting the rule logic based on the traditional coding method is effectively reduced, the rule online cycle is shortened, and the flexibility and maintainability of rule management are improved. At the same time, the graphical rule configuration method greatly reduces the error rate in the rule modeling and adjustment process, improves the intelligent level and response speed of the overall business process management, and has good application prospects and promotion value.

[0097] Among them, according to the set of standard condition fields in the structure rule data, a condition node component is generated. The condition node component displays condition attributes in the form of editable fields, specifically including: reading each standard field information in the set of standard condition fields, and extracting the field name, field type, field value range, and field constraint conditions. Based on the above-extracted information, a corresponding condition node component is instantiated for each standard field. The condition node component includes a field display area and a field editing area.

[0098] The field display area is used to visually present the basic attribute information of the field, such as the field name and its brief description, facilitating business personnel to understand the business meaning 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 (e.g., greater than, less than, equal to), setting expected values or expected value ranges, and configuring logical relationships between fields (such as AND or OR). For numeric fields, a numeric input box and a comparator selector are provided; for string fields, text matching or inclusion judgment options are provided; for date and time fields, a date selector and a time interval editor are provided.

[0099] By generating condition node components, the set of standard condition fields can be concretized into editable logical judgment units in the graphical interface, facilitating business personnel to configure and adjust rule condition logic in an intuitive and code-free manner, and improving the flexibility and accuracy of rule modeling.

[0100] Among them, according to the set of standard action parameters in the structure rule data, an action node component is generated. The action node component displays action content in the form of a parameter configuration form, specifically including: traversing each action parameter entry in the set of standard action parameters, and instantiating the action node component according to the action type and parameter definition. The action node component mainly includes an action name display area and a parameter configuration form area.

[0101] The action name display area is used to clearly identify the action represented by this node, such as triggering payment, sending a reminder, modifying the status, etc., facilitating business personnel to quickly understand the node function. The parameter configuration form area generates corresponding form input controls according to the different types of action parameters, such as text boxes, drop-down selectors, date selectors, or boolean value togglers. The form control for each parameter item sets default values, verification rules, and filling prompts according to preset rules to ensure that users can follow data integrity requirements when configuring action parameters.

[0102] After the user fills in the parameter form of the action node in the graphical interface, the value of each parameter is recorded in real time for subsequent generation of component rule data. Through the generation of the action node component, the standard action parameter set can be clearly and structurally displayed in the graphical interface, enabling business personnel to intuitively and standardly configure the action execution logic, further ensuring the accuracy and reliability of the rule execution phase.

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

[0104] Parse the node attributes and connection relationships in the component rule data, and reconstruct a set of rule expressions that conform to the execution engine standard;

[0105] Perform a legality check on the set of rule expressions. If there are conflicts or omissions, return an error prompt and prevent the generation of the running rule data;

[0106] Package the set of rule expressions that pass the legality check to generate the running rule data, and attach a rule version identifier to the running rule data.

[0107] In the embodiment of the present invention, in the process of parsing and verifying the component rule data in real time to obtain the running rule data and making the running rule data adapt to the dynamic rule loading interface in the running environment, first, by parsing the node attributes and connection relationships in the component rule data, a set of rule expressions that conform to the execution engine standard can be accurately reconstructed. Through this parsing step, it can be ensured that the rule logic remains consistent and correct during the conversion from the graphical interface expression to the execution engine language, avoiding rule failure or logical errors caused by expression differences.

[0108] After generating the set of rule expressions, further perform a legality check on this set. By promptly discovering conflicts or omissions in the rule definition during the verification phase, and returning an error prompt and preventing the generation of the running rule data when problems are found, it can effectively prevent logically incorrect rules from being deployed to the execution engine, improving the overall running stability and reliability. Only the set of rule expressions that pass all legality checks can be packaged and generate the final running rule data, and a rule version identifier is attached during the generation process to ensure that subsequent rule version management and dynamic loading operations can be based on evidence.

[0109] Through the above processing flow, seamless connection of rule logic from graphical editing to execution in standard format can be achieved. Moreover, an automatic verification mechanism is introduced in this process, greatly improving the accuracy and security of rule online deployment. Especially in the scenario of dynamic business adjustment, this process ensures that rule adjustments can take effect in real time without disrupting the normal operation of existing businesses, significantly enhancing the ability to quickly respond to business changes and the continuity of operation.

[0110] Among them, the node attributes and connection relationships in the component rule data are parsed, and a set of rule expressions that conform to the standards of the execution engine are reconstructed. Specifically, it includes: reading each node object in the component rule data, extracting the node type, node field information, and configuration parameters, and at the same time reading the connection relationship information between each node. For conditional nodes, extract their field editing content, including comparison logic, value range, and association logic; for action nodes, extract the specific execution parameters recorded in their parameter configuration form.

[0111] After parsing the attribute information of a single node, according to the connection relationship between the nodes, the trigger path from the conditional node to the action node is deduced, and the logical expressions are organized according to the path order. Specifically, each logical path is composed of the judgment logic of the conditional node and the execution instruction of the action node. The expression order of the logical path strictly follows the node connection direction. If there are multiple conditional node combinations, the priority and combination method of the expression are determined according to 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 generation of running rule data, ensuring the logical consistency and correctness from graphical editing to execution.

[0113] Among them, the set of rule expressions that pass the legality verification is packaged to generate running rule data, and a rule version identifier is attached to the running rule data. Specifically, after the set of rule expressions passes the legality verification, each legal rule expression is encapsulated into a standard rule record according to a preset format. The standard rule record contains the conditional logic description of the rule, the action execution instruction, and the logical association method between the two, and is organized according to a unified data structure to form running rule data.

[0114] When generating the running rule data, a rule version identifier is automatically attached to each piece of running rule data. The rule version identifier usually consists of a timestamp, a version number, and source information, and is used to uniquely identify the rule data generated in this batch. By recording the rule version identifier, not only can version management and traceability of rules be realized, but also subsequent version rollback, difference comparison, and dynamic version switching operations can be supported.

[0115] By encapsulating a set of legal regular expressions into running rule data and adding a version identifier, it is possible to ensure the compatibility and accuracy of different business versions at the rule execution level. At the same time, it enhances the controllability and flexible adaptability of the rule data in a dynamic business environment.

[0116] In a preferred embodiment of the present invention, based on the current business context to match the applicable version, automatically select the running rule data, and load it into the rule execution engine for execution, including:

[0117] Receive the current business context data, and extract the business identification information and environmental attribute parameters;

[0118] According to the business identification information, retrieve the matching conditions in the rule repository, and filter out the version of the running rule data that meets the environmental attribute parameters;

[0119] Load the filtered version of the running rule data into the memory area of the rule execution engine, and trigger the rule engine to execute the corresponding rule logic to complete the business judgment.

[0120] In the embodiment of the present invention, during the process of automatically selecting the running rule data based on the current business context to match the applicable version and loading it into the rule execution engine for execution, first receive the current business context data, and extract the business identification information and environmental attribute parameters. This processing step ensures that the actual characteristics of the current business request can be accurately understood, providing a basic condition for the dynamic matching of subsequent rule versions.

[0121] Subsequently, according to the extracted business identification information, retrieve the matching conditions in the rule repository, and filter out the version of the running rule data that meets the requirements of the environmental attribute parameters. Through such a filtering mechanism, it can ensure that the most suitable rule version can be applied in different business scenarios, avoiding errors or exceptions in the execution of business logic caused by mismatched rule versions. At the same time, through fine-grained filtering based on environmental attribute parameters, more flexible and dynamic business adaptation strategies can be supported, such as applying different rule logics in scenarios such as different regions, different product lines, and different customer types.

[0122] After filtering out the version of the running rule data that meets the conditions, load this version into the memory area of the rule execution engine, and trigger the rule engine to execute the corresponding rule logic to realize the automated processing of business decisions. Through this mechanism of dynamically selecting rule versions based on the business context, the intelligent decision-making ability and adaptability can be greatly improved, ensuring the accuracy and efficiency of business processes. It is especially suitable for business scenarios with high concurrency and high change frequencies, which helps to improve the 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, the context information related to the current business processing is parsed from the request data. The business context data usually includes but is not limited to the business process identification, operating user information, geographical location, request time, version number, and other environmental variables. The business identification information is extracted from it to represent the business type, sub-process identification, or specific business rule application scenario to which the business request belongs, such as classification identifications like auto insurance claims and health insurance claims in insurance claims. At the same time, the environmental attribute parameters are further extracted. These parameters are mainly used to describe the characteristics of the external environment, such as the operation version, client type, geographical location, access channel, etc.

[0124] The extraction process is parsed and classified according to a preset data extraction template or context field mapping table to ensure that all business identification information and environmental attribute parameters can be output in a standardized manner for use by the subsequent rule screening module. Through the above processing, the context feature information required for rule screening can be extracted in real time and accurately without increasing the burden of business changes, thereby supporting the dynamic matching of applicable rule versions and ensuring the accuracy and adaptability of business rule applications.

[0125] Among them, the selected version of the running rule data is loaded into the memory area of the rule execution engine to trigger the rule engine to execute the corresponding rule logic to complete the business judgment, specifically including: after filtering out the applicable version of the running rule data according to the business identification information and environmental attribute parameters, the data of this version is loaded into the preset rule execution engine. The loading process includes operations such as initializing the rule expression set, configuring execution parameters, and warming up the cache to ensure that the rule execution environment can immediately recognize and call the newly loaded rule set.

[0126] After the rule data is loaded, the execution process of the rule engine is triggered according to the current business request data. The rule engine judges whether the business data conforms to specific rules based on the conditional logic defined in the running rule data, and executes the corresponding action logic according to the judgment result, such as allowing the process to pass, sending an exception warning, or triggering a further approval process. The whole process is completed in real time in the business background without interrupting the service or manual intervention, effectively improving the application efficiency after the dynamic adjustment of the rules.

[0127] By quickly loading and immediately triggering the execution of the selected rule version, not only is the continuity of business processing ensured, but also the ability to flexibly respond to high-frequency changing business requirements and external policy adjustments is achieved, significantly improving the intelligent level and response speed of the business.

[0128] In a preferred embodiment of the present invention, in the process of retrieving matching conditions in the rule repository according to the service identification information and screening the running rule data version that meets the environmental attribute parameters, version screening is performed based on the comprehensive fitness score, including:

[0129] Extract the service identification information, environmental attribute parameters, and historical call records according to the service context data, and calculate the service matching degree respectively , environmental matching degree and historical stability ;

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

[0131] Among them, The comprehensive fitness score represents the overall fitness degree of the current running rule version and the service context. The higher the score, the more suitable it is; Is the normalized weight of the service matching degree weight coefficient, which determines The contribution ratio to Score; Is the normalized weight of the environmental matching degree weight coefficient, which determines The contribution ratio to Score; Is the normalized weight of the stability parameter weight coefficient, which determines The contribution ratio to Score; Is the th service identification field value, such as service type, product number, etc. (from the current service context); Is the th rule version field value, the definition of the corresponding field in the rule data; Is And The similarity score between them, ranging from [0,1], 1 means complete match, 0 means complete mismatch; Is the total number of service identification fields, the number of fields participating in the match; Is the th environmental attribute field value, such as geographical location, version number, etc. environmental parameters; Is the The field definition corresponding to the field value in a rule version field rule data; is the similarity score between and, ranging from [0, 1]; is the number of fields participating in the matching out of the total number of environmental attribute fields; is the set of response latencies when the historical call response latency sequence called this rule version in the past; is the variance of T used to measure the stability of the call latency. The smaller the value, the more stable it is; .

[0132] In the embodiments of the present invention, the entire formula calculates the final score through the comprehensive calculation of three parts of indicators:

[0133] Business matching degree : Compare the similarity between the current business identification field and the rule version defined field; take the average of multi-field normalization to reflect the overall business scenario adaptability.

[0134] Environmental matching degree : Compare the environmental adaptability between the current environmental parameters and the rule definition; take the average of multi-field normalization to reflect the consistency of the external environment.

[0135] Historical stability : Statistically analyze the response latency sequence of the historical calls of the rule version; the smaller the variance, the more stable the rule execution and the higher the score.

[0136] Finally, with weight coefficients , , perform weighted summation to form the comprehensive adaptability . Then select the version with the highest

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

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

[0139] Based on the preset field standardization rules, perform unified processing of the field types on the preliminary field set, and map fields with different sources but the same logical meaning to the standard field set;

[0140] In the standard field set, detect field naming conflicts. If there are naming conflicts and the field types are the same, then distinguish the naming by adding a data source identifier to the field name. If the field types are different, reject the merge and generate a conflict warning message;

[0141] Generate a standard condition field set according to the standardized field set after naming adjustment, and establish the mapping relationship between the original fields and the standard fields.

[0142] In the embodiment of the present invention, when extracting field information for each condition item in the original rule data and performing standardization processing based on the field type to form a standard condition field set, by first extracting the field name, field type, and field constraint information of each condition item, the key information of the business logic defined in the original rule data can be comprehensively captured. Subsequently, based on the preset field standardization rules, the unified processing of the field types of the extracted preliminary field set is carried out, so that fields with different sources but the same logical meaning can be mapped to the same standard field, thus solving the problem of inconsistent fields caused by heterogeneous data sources.

[0143] After the standardization processing, further detect field naming conflicts in the standard field set. If there are naming conflicts and the field types are the same, then distinguish the naming by adding a data source identifier to the field name to ensure that the field is clearly pointed to in the subsequent processing process and avoid logical confusion caused by repeated naming. If the field types are inconsistent, reject the merge and generate a conflict warning message to ensure data consistency and reliability in the rule modeling process. Finally, by generating a standard condition field set according to the standardized field set after naming adjustment and establishing the mapping relationship between the original fields and the standard fields, both the traceability of the original data is retained and the high consistency and standardization of the subsequent processing process are ensured.

[0144] Through the above standardization processing process, not only the clarity and compatibility of the rule data are improved, but also a solid foundation is laid for the subsequent rule component generation, graphical editing, and dynamic parsing, significantly improving the ability to manage complex business rules and the adaptability to flexibly respond to changing business requirements, and having good application and promotion prospects.

[0145] Among them, based on the preset field standardization rules, the unified processing of the field types of the preliminary field set is carried out, and fields with different sources but the same logical meaning are mapped to the standard field set, which specifically includes: after the extraction of the preliminary field set is completed, each field is analyzed and processed according to the preset field standardization rule set. The field standardization rules include field name standardization rules, field type standardization rules, and field unit standardization rules.

[0146] In terms of field name standardization, through keyword matching, business dictionary comparison, etc., fields with the same logical meaning but different names are normalized into standard field names. For example, different names such as "compensation amount", "claim settlement amount", and "payout amount" are unified and merged into the standard field "payout amount". In terms of field type standardization, if the original data types of fields from different sources are different, such as one field stores an amount as a string and another stores it as a floating point number, they are uniformly converted into a standard numerical format. For fields with differences in physical quantity units, such as a length field having two unit representations of "meter" and "centimeter", conversion is performed according to the unified unit to ensure the consistency and comparability of field values.

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

[0148] Among them, in the standard field set, field naming conflicts are detected. If there are naming conflicts and the field types are the same, naming differentiation is carried out by adding a data source identifier to the field name. If the field types are different, the merge is rejected and a conflict warning message is generated. Specifically, after generating the standard field set, traverse the field entries in the set to retrieve whether there are cases of duplicate field names. If it is detected that two or more fields have the same name and the same field type, for example, both fields are floating point type and the name is "payout amount", then a source identifier is appended to the original field name, such as appending a suffix of "_source A" or "_source B" after the field, for naming differentiation to ensure that each field can be accurately identified in subsequent processing.

[0149] If it is detected that the names are the same but the field types are different, for example, one of the fields with the same name is numerical type and the other is text type, it is determined that this conflict cannot be resolved by simple naming differentiation. Therefore, the merge of this field is rejected and a conflict warning message is generated. The conflict warning message includes the name of the conflicting field, the respective data types of the conflicting fields, and the conflict source, for business personnel or administrators to manually decide on the processing method according to actual needs.

[0150] Through the above naming conflict detection and processing mechanism, the internal consistency and resolvability of the standard field set are ensured, preventing rule logic execution errors caused by field naming ambiguity or type confusion, thereby improving the overall stability and correctness of the rule engine operation.

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

[0152] Generate a set of condition nodes based on the standard condition field set, and set the field editable attribute and the logical expression editing entry in each condition node;

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

[0154] Establish a connection relationship between the set of condition nodes and the set of action nodes based on the preset connection rules, only allow node combinations that conform to the business logic constraints, and detect in real time whether the connection is legal. If the connection violates the predefined constraints, an error is prompted and the node connection is prohibited from being saved;

[0155] After completing the editing of the rule link diagram, extract the changed node information and connection relationship, generate incremental update data, and merge it into the component rule data to form the updated component rule data.

[0156] In the embodiment of the present invention, by combining the condition node component and the action node component through logical connections to form a rule link diagram, when the user edits and adjusts the rule link diagram in the graphical interface and extracts its updated content to generate the corresponding component rule data, first generate a set of condition nodes based on the standard condition field set, and set the field editable attribute and the logical expression editing entry in each condition node, so that business personnel can easily perform personalized configuration for the condition logic in the graphical interface. At the same time, generate a set of action nodes based on the standard action parameter set, and set the parameter verification template and the execution configuration entry in each action node to ensure the standardization and accuracy of the action configuration.

[0157] After the node generation is completed, establish a connection relationship between the set of condition nodes and the set of action nodes based on the preset connection rules, effectively restricting unreasonable node combinations, only allowing node connections that conform to the business logic constraints, and avoiding the occurrence of potential logical errors. At the same time, detect in real time whether the connection is legal during the connection operation. If the connection violates the predefined constraints, an error is immediately prompted and the node connection is prohibited from being saved, thereby preventing the introduction of invalid logic at the editing stage and improving the overall quality and stability of the rule link data.

[0158] After completing the editing of the rule link diagram, it is possible to extract the changed node information and connection relationship in real time, generate incremental update data, avoid the reconstruction of the full volume of data, and improve the processing efficiency. By merging the incremental update data into the component rule data to form the updated component rule data, it is possible to ensure the efficiency and reliability of the rule adjustment process, and ensure that the modification of the business logic can be synchronized to the subsequent parsing and execution stages in a timely manner, significantly improving the flexibility, controllability and operational stability of rule maintenance.

[0159] Among them, between the conditional node set and the action node set, a connection relationship is established based on preset connection rules, only allowing node combinations that conform to business logic constraints, and the legality of the connections is detected in real time. If a connection violates the predefined constraints, an error is prompted and the node connection is prohibited from being saved. Specifically, it includes: after generating the conditional node set and the action node set, according to the predefined connection rule control logic, allowing the user to perform connection operations between nodes in the interface. The preset connection rules include, but are not limited to: conditional nodes can only be connected to action nodes; action nodes cannot be upstream nodes of conditional nodes; the same conditional node can be connected to multiple action nodes, but an action node cannot be directly upstream by connecting to multiple conditional nodes, unless a composite conditional logic module is configured.

[0160] When the user initiates a connection request, it is judged in real time whether the connection conforms to the above rule constraints. If the connection conforms to the rules, the connection is allowed and the connection relationship is saved; if the connection violates the rules, for example, a conditional node is connected to another conditional node, or an action node is connected back to itself, an error prompt message is immediately popped up on the interface, and the current connection operation is refused to be saved, so as to prevent the formation of logical errors or invalid process paths. Through this process, the business logic correctness of the node combination can be guaranteed at the rule link construction stage, and the risk of subsequent rule execution exceptions can be reduced.

[0161] Among them, after completing the editing of the rule link diagram, the changed node information and connection relationship are extracted to generate incremental update data, and merged into the component rule data to form updated component rule data. Specifically, it includes: when the user completes operations such as adding or deleting nodes, modifying attributes, or adjusting connections in the rule link diagram in the graphical interface, based on the operation log or the difference comparison mechanism, the node data and connection data that have changed compared with the original link state are extracted.

[0162] The changes in node data include the modification of node attributes, such as changes in conditional fields and updates of action parameters; the changes in connection data include the addition of connection relationships or the deletion of original connection relationships. These changed parts are separately sorted out to form incremental update data, avoiding the performance overhead caused by full-scale data reconstruction. Subsequently, the incremental update data is merged and updated with the existing component rule data, and only the changed nodes or connections are updated, maintaining the data stability and continuity of the unchanged parts.

[0163] 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 content edited and modified by the user can be accurately synchronized to the component rule data, providing an accurate rule basis for subsequent rule parsing and execution.

[0164] In a preferred embodiment of the present invention, the legality verification of the rule expression set is performed, including:

[0165] Extract the set of rule expressions according to the updated component rule data, and establish a reference index table based on the expression reference relationship;

[0166] According to the reference index table, perform field validity verification on each rule expression. If it is found that a field does not exist in the standard condition field set, record the field reference error and locate it to the specific node;

[0167] Perform integrity verification 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;

[0168] Analyze the connectivity and logical rationality of the connection relationships in the rule link diagram. If there are circular references, isolated nodes, or broken links, record the structure anomaly error;

[0169] Generate a verification comprehensive report with hierarchical prompts based on all field reference errors, parameter missing errors, and structure anomaly errors, and indicate the error nodes and error types in a highlighted manner.

[0170] In the embodiment of the present invention, during the process of performing legality verification on the set of rule expressions, first extract the set of rule expressions according to the updated component rule data, and establish a reference index table based on the expression reference relationship. By establishing the reference index table, it is possible to accurately record the fields and action parameters involved in each expression, ensuring a clear basis for the subsequent verification operations. For each extracted rule expression, by verifying the field validity, if it is found that a referenced field does not exist in the standard condition field set, record the field reference error in a timely manner and locate it to the specific node, which helps to quickly discover and correct reference omissions or errors.

[0171] Perform integrity verification on the execution parameters of the action nodes in the rule expression. If a required parameter is missing, automatically record the parameter missing error and mark it on the parameter configuration interface to remind the business personnel to supplement the missing information in a timely manner, thereby avoiding abnormal rule execution caused by parameter omission. In terms of structural logic, by analyzing the connectivity and logical rationality of the connection relationships in the rule link diagram, it is possible to detect structural anomalies such as circular references, isolated nodes, or broken links, record the structure anomaly errors in a timely manner, and prevent the risk of unexpected process interruption or infinite loop during the rule execution process.

[0172] Finally, based on all field reference errors, parameter missing errors, and structural exception errors, a hierarchical prompt verification comprehensive report is generated, and the error nodes and error types are indicated in a highlighted manner, enabling business personnel to intuitively understand the problem sources and severity levels. Through the above meticulous legality verification process, the accuracy, robustness, and execution reliability of the rule data have been greatly improved, the probability of logical loopholes or business exceptions occurring after the rules are launched has been significantly reduced, and the overall stability and business continuity guarantee capabilities have been remarkably enhanced.

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

[0174] When performing field validity verification, traverse the field names involved in the rule expression one by one, and query whether there is a corresponding definition in the standard condition field set. If it is found that a certain field is not registered in the standard condition field set, it indicates that the field is an illegal reference. The error is recorded in the error list, and at the same time, the position of the specific condition node or action node that references the field is marked, so as to facilitate subsequent business personnel to locate the problem.

[0175] Through the above verification, illegal field reference problems caused by field omission, spelling mistakes, or version inconsistencies can be detected in a timely manner, thereby preventing logical exceptions or execution failures before the rules are officially run and improving the overall reliability.

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

[0177] If it is detected that there is a situation where a required parameter in the action node is not filled, filled as empty, or has a wrong format, the error is recorded in the error list, and in the parameter configuration area of the graphical interface, the missing or wrong parameter items are significantly marked by means of highlighting, prompt bubbles, etc., so as to facilitate business personnel to discover and correct them in a timely manner.

[0178] Through the integrity verification of the execution parameters of the action nodes, it is possible to effectively avoid action execution failures or exceptions caused by parameter missing or configuration errors, and greatly improve the stability and fault tolerance of the rule execution process.

[0179] Among them, for the analysis of the connectivity and logical rationality of the rule link diagram, if there are circular references, isolated nodes or broken links, structural anomaly errors are recorded, specifically including: after the construction of the rule link diagram is completed, the overall node connection relationship is detected through a connectivity analysis algorithm. The detection content includes: whether there are isolated nodes that cannot reach the action nodes starting from the starting node; whether there are circular reference paths where nodes are connected to themselves or form closed loops; whether there are broken links where the connection lines are broken, resulting in part of the logical link being unable to execute in a closed loop.

[0180] When the above structural anomaly situations are detected, the relevant anomalies are immediately recorded in the structural anomaly error list, and the positions of the abnormal nodes or abnormal paths are visually displayed through methods such as interface highlighting and connection line warning marks. Business personnel can adjust the node connection lines or correct the logical structure according to the prompts to ensure that the rule link complies with the correct execution process requirements.

[0181] By real-time detection and feedback on the structural integrity and logical rationality of the rule link 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.

[0182] In a preferred embodiment of the present invention, according to all field reference errors, parameter missing errors and structural anomaly errors, a hierarchical prompt verification comprehensive report is generated, and the error nodes and error types are indicated in a highlighted manner, including:

[0183] According to the field reference errors, the corresponding error node information is extracted and listed in the verification comprehensive report in the form of node numbers and field names;

[0184] According to the parameter missing errors, the list of missing parameters of the action nodes is extracted, and the missing required items and the positions of the corresponding action nodes are indicated in the verification comprehensive report;

[0185] According to the structural anomaly errors, an error connection relationship diagram is analyzed, the node path information with loops, isolation or broken links is marked, and an abnormal link schematic is drawn in the verification comprehensive report;

[0186] The field reference errors, parameter missing errors and structural anomaly errors are classified and summarized respectively, priority identifiers are assigned, and various error information is highlighted according to the priority;

[0187] An interactive jump function is set in the verification comprehensive report to support users to click on the error item to directly locate to the corresponding node position in the graphical interface.

[0188] In the embodiments of the present invention, when generating a hierarchical prompt verification comprehensive report based on all field reference errors, parameter missing errors, and structural anomaly errors, and indicating the error nodes and error types in a highlighted manner, first, extract the corresponding error node information according to the field reference errors, and accurately list it in the verification comprehensive 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, extract the list of missing parameters of the action nodes according to the parameter missing errors, and mark the missing required items and the corresponding action node positions in the verification comprehensive report to help users quickly locate and supplement the necessary parameters.

[0189] Regarding structural anomaly errors, analyze to form an error connection relationship diagram, mark the node path information with loops, isolation, or broken links, and further draw a schematic diagram of the abnormal link in the verification comprehensive report, so that the overall rule structure problems can be presented in a visual way, facilitating business personnel to quickly understand and correct logical defects. To improve the usability and emergency management of the verification report, classify and summarize the field reference errors, parameter missing errors, and structural anomaly errors respectively, and assign priority identifiers to ensure that business personnel can reasonably arrange the repair order according to the severity of the problems and optimize the debugging efficiency.

[0190] Set an interactive jump function in the verification comprehensive report to support users to click on the error item to directly locate to the corresponding node position 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 increase in rule complexity, improves the overall experience of rule configuration and management, and further enhances the usability and intelligent level in high-complexity business scenarios.

[0191] Among them, according to the structural anomaly errors, analyze to 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 link in the verification comprehensive report, specifically including: after completing the analysis of the connectivity and logical rationality of the rule link diagram, for the detected structural anomaly errors, sort out the node and connection relationship information according to the error types to form an error connection relationship diagram.

[0192] For detected circular reference errors, the node set and connection path that cause the loop to be formed are recorded, and the loop structure is identified with a closed-loop path in the error connection relationship diagram, highlighting the nodes and connections that cause the loop; for isolated node errors, the conditional nodes or action nodes that have not formed an effective connection with any action node or start node are identified, and the isolated nodes are highlighted separately in the connection relationship diagram, and their unconnected status is marked; for broken link errors, the nodes and connection breakpoints with interrupted positions in the link are analyzed, and interruption marks are drawn in the connection relationship diagram to clearly indicate the specific location where the link cannot be closed.

[0193] The above error connection relationship diagram is embedded in the verification comprehensive report as an abnormal link diagram, so that business personnel can intuitively understand the specific location of the structural abnormality, the error type and the related node relationship when viewing the report, which is convenient for subsequent rapid correction and reconstruction of the correct rule link structure. By drawing the 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.

[0194] Among them, field reference errors, parameter missing errors and structural abnormal errors are classified and summarized separately, assigned priority identification, and various error information is highlighted according to the priority, including: after completing all rule verifications, the collected error information of different types is classified and sorted. Field reference errors mainly include references to undefined fields or misspellings of field references; parameter missing errors mainly include mandatory parameters in action nodes that are not configured or the configuration content is invalid; structural abnormal errors mainly include circular references, isolated nodes or broken link structure problems.

[0195] Based on the classification and sorting, each type of error is assigned a predefined priority identifier. The priority definition follows the risk assessment principle. For example, structural abnormality errors are given the highest priority because they may cause the entire rule chain to be unexecutable; parameter missing errors are given medium-high priority because they affect the correct execution of action nodes; field reference errors are given medium priority because they may cause judgment logic deviations.

[0196] In the verification comprehensive report, different highlighting methods are used according to the priority of each error, such as different colors, bold fonts, flashing borders, etc. to distinguish the severity, and guide business personnel to prioritize the issues that have a greater impact on stability. Error items with high priority are ranked higher in the verification report to ensure that they can be paid attention to and repaired first before the rules are adjusted and released, thereby improving the overall rule quality and the success rate of online release.

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

[0198] An embodiment of the present invention further provides a low-code rule engine platform supporting dynamic service adjustment, and the platform includes:

[0199] A raw data acquisition module, configured to obtain raw rule data, where the raw rule data includes a plurality of condition items for business judgment and corresponding action items, and an initial rule pair is formed between each condition item and the action item;

[0200] A raw data processing module, configured to perform structured conversion on the raw rule data and unify the format specification to obtain structured rule data;

[0201] A rule component generation module, configured to generate visual rule components according to the structured rule data, present the rule logic through a graphical interface, support business personnel to edit and modify without coding, and convert the modification result into component rule data;

[0202] A rule parsing and verification module, configured to perform real-time parsing and verification on the component rule data to obtain running rule data, where the running rule data adapts to a dynamic rule loading interface in the running environment;

[0203] A version management module, configured to perform version identification on the running rule data and store it in a rule repository, where the rule repository is used to maintain rule historical versions and change records, and support rollback and reload of any version;

[0204] A rule scheduling module, configured to match an applicable version based on the current business context, automatically select the running rule data, and load it into a rule execution engine for execution.

[0205] It should be noted that this system corresponds to the above method, and all implementation manners in the above method embodiments are applicable to this embodiment and can also achieve the same technical effects.

[0206] An embodiment of the present invention further provides a computing device, including: a processor and a memory storing a computer program. When the computer program is run by the processor, it executes the method as described above. All implementation manners in the above method embodiments are applicable to this embodiment and can also achieve the same technical effects.

[0207] An embodiment of the present invention further provides a computer-readable storage medium storing instructions. When the instructions are run on a computer, the computer is made to execute the method as described above. All implementation manners in the above method embodiments are applicable to this embodiment and can also achieve the same technical effects.

[0208] The above are the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A low-code rule engine method supporting dynamic business adjustment, characterized in that: The method comprises: Acquire original rule data, wherein the original rule data includes a plurality of condition items and corresponding action items for business judgment, wherein each condition item and action item form 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; Analyze and verify component rule data in real time to obtain operation rule data; Version the running rule data and store it in the rule warehouse; 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.

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 for each action item in the original rule data, and perform unified processing based on the parameter format to 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, support business personnel to edit and modify without coding, and convert the modification results into component rule data, including: Generate a condition node component according to 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 according to 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 3, characterized in that: 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: 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 rule data generation will be stopped. 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.

5. A low-code rule engine method supporting dynamic business adjustment according to claim 4, characterized in that: 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, including: Receive current business context data and extract business identification information and environment attribute parameters; Retrieve matching conditions in the rule warehouse based on the business identification information and filter out the running rule data version that meets the environment attribute parameters; 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.

6. A low-code rule engine method supporting dynamic business adjustment according to claim 4, characterized in that: 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, 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 processed uniformly in terms of field type, and fields from different sources but with 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. According to 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.

7. A low-code rule engine method supporting dynamic business adjustment according to claim 6, 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 a set of standard conditional fields, and set field editable attributes and logical expression editing entries in each conditional node; Generate an action node set according to the standard action parameter set, and set a parameter verification template and execution configuration entry in each action node; Establish a connection relationship between the condition node set and the action node set based on the preset connection rules, only allow node combinations that meet the business logic constraints, and detect whether the connection is legal in real time. If the connection violates the predefined constraints, an error is prompted and the node connection is prohibited from being saved; After completing the editing of the rule link graph, extract the changed node information and connection relationship, generate incremental update data, and merge it into the component rule data to form updated component rule data.

8. A low-code rule engine method supporting dynamic business adjustment according to claim 7, characterized in that: Check the validity of the rule expression set, including: According to the updated component rule data, a rule expression set is extracted, and a reference index table is established according to the expression reference relationship; According to the reference index table, the field validity is checked for each rule expression. 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; 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 abnormalities, and highlights the error nodes and error types.

9. A low-code rule engine method supporting dynamic business adjustment according to claim 8, characterized in that: Generates a comprehensive verification report with hierarchical prompts based on all field reference errors, parameter missing errors, and structural abnormal errors, and highlights the error nodes and error types, including: According to the field reference error, the corresponding error node information is extracted and listed in the verification summary report in the form of node number and field name; According to the parameter missing error, extract the missing parameter list of the action node, and indicate the missing mandatory items and the corresponding action node position in the verification comprehensive report; According to the 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 abnormal links in the verification comprehensive report; Classify and summarize field reference errors, parameter missing errors, and structure abnormal errors, assign priority labels, and highlight various error messages according to priority. An interactive jump function is set in the verification summary report to support users to click on the error item to directly locate the corresponding node position in the graphical interface.

10. A low-code rule engine platform that supports dynamic business adjustments, characterized in that: Applied to the method according to any one of claims 1 to 9, the platform comprises: The original data acquisition module is used to obtain the original rule data, wherein the original rule data includes a plurality of 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, supporting business personnel to edit and modify without coding, and convert the modification 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, and the operation rule data 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, which 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