Parameter verification method and device, electronic equipment and nonvolatile storage medium

Abstract

The invention discloses a parameter verification method and device, electronic equipment and a nonvolatile storage medium. The method comprises the steps that in response to a rule configuration instruction triggered by a front-end interaction interface, a rule language text is generated, visual configuration options of parameter verification rules are displayed in the front-end interaction interface, and the rule configuration instruction is triggered by dragging the configuration options by a user; performing grammatical analysis on the rule language text to obtain an abstract syntax tree; according to the abstract syntax tree, generating a target annotation, and binding the target annotation to a target class, the target annotation being used for defining a verification rule which needs to be followed by a field of the target class so as to perform verification through a verifier when the target class runs; and verifying the parameter verification object according to the verification rule by adopting a verifier. According to the method and the device, the technical problem of low parameter verification rule updating configuration efficiency caused by serious coupling of a front end and a verification rule code in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and more specifically, to a parameter verification method, apparatus, electronic device, and non-volatile storage medium. Background Technology

[0002] In enterprise Java application development, especially in complex distributed applications involving multi-tenant systems, SaaS platforms, and fintech, parameter validation technology plays a crucial role. It ensures the integrity of system data and the correctness of business processes. However, parameter validation techniques have many shortcomings when faced with complex business logic and ever-changing rule requirements.

[0003] For example, in related technologies, the front-end form design and back-end validation rules are tightly coupled, making it difficult for business personnel to directly participate in the rule definition process, resulting in low efficiency in updating and configuring parameter validation rules; and the parameter validation technology in related technologies often cannot effectively achieve tenant-level rule isolation, which may affect the rules of other tenants when maintaining and updating the rules of a specific tenant, thereby increasing the difficulty and risk of system management.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a parameter verification method, apparatus, electronic device, and non-volatile storage medium to at least solve the technical problem of low efficiency in updating and configuring parameter verification rules caused by the severe coupling between the front-end and verification rule code in related technologies.

[0006] According to one aspect of the embodiments of this application, a parameter validation method is provided, comprising: generating rule language text in response to a rule configuration instruction triggered by a front-end interactive interface, wherein the front-end interactive interface displays visual configuration options for parameter validation rules, and the rule configuration instruction is triggered by the user dragging and dropping configuration options; performing syntactic analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the validation logic in the rule language text; generating a target annotation based on the abstract syntax tree, and binding the target annotation to a target class, wherein the target annotation is used to define the validation rules that the fields of the target class need to follow, so that the target class can be validated by a validator at runtime; and using a validator to validate the parameter validation object according to the validation rules.

[0007] Optionally, in response to a rule configuration command triggered by the front-end interactive interface, generating rule language text includes: determining the user identifier corresponding to the currently logged-in user account; obtaining the back-end field corresponding to the user identifier from the database and displaying the back-end field in a tree structure in the front-end interactive interface, wherein each form control in the tree structure corresponds to a back-end field; monitoring cursor movement data of the cursor dragging operations on form controls and / or condition blocks in the front-end interactive interface, and generating a hierarchical structure based on the cursor movement data, wherein different condition blocks correspond to different logical operation relationships, and the hierarchical structure is used to represent the logical judgment rules corresponding to the back-end fields; and generating rule language text based on the hierarchical structure.

[0008] Optionally, performing syntactic analysis on the rule-based language text to obtain an abstract syntax tree includes: performing text cleaning on the rule-based language text, and dividing the cleaned text into at least one text segment based on preset target characters, wherein the text cleaning is used to remove invalid characters from the rule-based language text, and each text segment corresponds to a validation rule; performing word segmentation on the text segment according to preset syntactic rules to obtain word segmentation results, wherein the preset syntactic rules are used to define the structure of the rule-based language; and using a syntax analyzer to perform syntactic analysis on the word segmentation results to obtain an abstract syntax tree.

[0009] Optionally, generating the target annotation based on the abstract syntax tree includes: traversing the abstract syntax tree, extracting key information from the abstract syntax tree, and constructing an intermediate representation result based on the key information, wherein the key information includes at least one of the following: conditional expression, logical relationship, and validation prompt information; mapping the intermediate representation result to the annotation corresponding to the condition type based on the condition type to obtain the target annotation.

[0010] Optionally, binding the target annotation to the target class includes: generating a bytecode file containing the target annotation; inserting the bytecode file into the bytecode structure of the field corresponding to the target annotation in the target class during the target class loading process; and updating the mapping relationship between the field and the target annotation in the cache.

[0011] Optionally, the method further includes: monitoring whether the rule language text has been updated; if the rule language text has been updated, regenerating the target annotation based on the updated rule language text and binding the newly generated target annotation to the target class; and refreshing the validator's cache to ensure that the new validation rules take effect.

[0012] Optionally, a validator is used to validate the parameter validation object according to the validation rules, including: determining the user identifier corresponding to the parameter validation object; determining the target annotation corresponding to the user identifier; and calling the validator corresponding to the annotation type to validate the parameter validation object based on the annotation type corresponding to the target annotation.

[0013] According to another aspect of the embodiments of this application, a parameter verification device is also provided, comprising: a rule text generation module, used to generate rule language text in response to a rule configuration instruction triggered by a front-end interactive interface, wherein the front-end interactive interface displays visual configuration options for parameter verification rules, and the rule configuration instruction is triggered by the user dragging and dropping configuration options; a syntax tree construction module, used to perform syntactic analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the verification logic in the rule language text; a target annotation generation module, used to generate target annotations based on the abstract syntax tree and bind the target annotations to a target class, wherein the target annotations are used to define the verification rules that the fields of the target class need to follow, so that the target class can be verified by a validator at runtime; and a parameter verification execution module, used to use a validator to verify the parameter verification object according to the verification rules.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes a parameter verification method during runtime.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes a parameter verification method by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program, wherein when the computer program is executed by a processor, it implements the steps of a parameter verification method.

[0017] In this embodiment, rule language text is generated in response to rule configuration instructions triggered by the front-end interactive interface. The front-end interactive interface displays visual configuration options for parameter validation rules, and the rule configuration instructions are triggered by the user dragging and dropping configuration options. Syntactic analysis is performed on the rule language text to obtain an abstract syntax tree, which represents the validation logic in the rule language text. Based on the abstract syntax tree, target annotations are generated and bound to target classes. The target annotations define the validation rules that the fields of the target class must follow, so that the validator can perform validation at runtime on the target class. By using a validator to validate the parameter validation object according to the validation rules, the separation of business rules and validation code, and allowing business personnel to directly participate in rule formulation through front-end visual configuration, achieves the goal of reducing technical communication costs and shortening the response time for rule changes. It also realizes parameter validation isolation and dynamic updates in a multi-tenant environment, thereby solving the technical problem of low efficiency in updating parameter validation rule configurations caused by the severe coupling between the front-end and validation rule code in related technologies. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or electronic device) for implementing a parameter verification method according to an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a parameter verification method provided according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of an architecture for front-end visual parameter validation based on the Drools rule engine, according to an embodiment of this application.

[0022] Figure 4 This is a timing diagram of a front-end visual parameter verification process provided according to an embodiment of this application;

[0023] Figure 5 This is a schematic diagram illustrating a rule definition, parsing, and conversion process according to an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of a complete structure of an enhanced DRL rule according to an embodiment of this application;

[0025] Figure 7This is a schematic diagram illustrating an example of a DRL rule text provided according to an embodiment of this application;

[0026] Figure 8 This is a schematic diagram of a code example for generating an abstract syntax tree (AST) according to an embodiment of this application;

[0027] Figure 9 This is a schematic diagram of a complete DRLLexer.g4 file provided according to an embodiment of this application;

[0028] Figure 10 This is a schematic diagram illustrating a code example for constructing an intermediate representation result according to an embodiment of this application;

[0029] Figure 11 This is a schematic diagram illustrating a code example generated according to an embodiment of this application;

[0030] Figure 12 This is a schematic diagram illustrating a dynamic binding and verification execution process according to an embodiment of this application;

[0031] Figure 13 This is a schematic diagram illustrating a code example of dynamic binding according to an embodiment of this application;

[0032] Figure 14 This is a schematic diagram illustrating a code example for verification execution provided in an embodiment of this application;

[0033] Figure 15 This is a schematic diagram illustrating a code example of rule hot updating according to an embodiment of this application;

[0034] Figure 16 This is a schematic diagram of a parameter verification device provided according to an embodiment of this application. Detailed Implementation

[0035] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0036] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0037] To facilitate a better understanding of the embodiments of this application by those skilled in the art, some technical terms or nouns involved in the embodiments of this application are explained as follows:

[0038] Enhanced DRL rule structure: Extends the syntax of traditional Drools Rule Language (DRL) to support rule expressions with multi-level nested conditions, dynamic parameter references, combinational logic operations, and tenant isolation declarations. It is the core carrier for implementing complex verification logic and multi-tenant isolation.

[0039] The four-layer parsing architecture is a process that converts DRL rule text into executable validation logic. The steps are: DRL text preprocessing, ANTLR lexical / syntactic analysis, Abstract Syntax Tree (AST) processing, rule mapping algorithm, and finally, Spring Validation annotations.

[0040] Front-end visual rule definition: Business users can configure validation rules through a drag-and-drop interface, which can automatically generate enhanced DRL text without manually writing rule code.

[0041] Tenant-isolated information display: The front end displays the back end field paths in a tree structure. Each control is associated with the tenant ID attribute and loads the corresponding field metadata based on the tenant context, ensuring the display unit of multi-tenant data isolation.

[0042] ANTLR Lexical / Syntax Analysis: The ANTLR tool is used to process DRL text. Lexical analysis is responsible for word segmentation of the text (identifying keywords, operators, etc.), while syntax analysis is the parsing process that generates a structured abstract syntax tree (AST) according to rules.

[0043] AST (Abstract Syntax Tree): A tree-like data structure generated through ANTLR parsing, used to structurally represent the conditional expressions, logical relationships, and validation hints in DRL rules. It serves as the intermediate carrier for rule parsing.

[0044] Rule mapping algorithm: An algorithm that converts ConditionNodes obtained from AST processing into SpringValidation annotations, including direct mapping of simple conditions to basic annotations and conversion of complex conditions to custom validator annotations.

[0045] ASM bytecode generation technology: Based on the parsed annotation metadata, it dynamically generates bytecode files containing verification annotations and inserts them into the target Java class field structure through class loader hooks, achieving non-intrusive binding between rules and fields.

[0046] Multi-dimensional validator: A custom ConstraintValidator implementation that supports loading corresponding rules based on tenant context, recursively parsing nested object fields, and calculating dynamic parameter values ​​in real time. It is the core component for executing complex validation logic.

[0047] Hot rule updates: This mechanism uses Drools' KieScanner to monitor changes in DRL files, triggering rule recompilation, annotation regeneration, bytecode reset, and cache refresh, so that new rules can take effect without restarting the application.

[0048] In enterprise-level Java application development using related technologies, especially in scenarios such as large-scale distributed systems, SaaS platforms, and fintech systems, the following typical application scenarios exist:

[0049] 1) Multi-tenant system: Different tenants have different business rules and verification requirements, such as different merchants in an e-commerce platform having different verification rules for product information;

[0050] 2) Frequently changing business rules: such as risk control rules in the financial industry and promotional activity rules on e-commerce platforms, which need to be adjusted quickly;

[0051] 3) Business personnel participate in rule setting: Non-technical personnel need to adjust the validation rules in real time according to business changes, such as operations personnel configuring form validation logic;

[0052] 4) Complex nested object validation: Validation of multi-level data structures commonly found in enterprise applications, such as order information containing user information, product information, address information, etc.

[0053] Therefore, how to enable business personnel to visually configure complex and ever-changing parameter validation is the problem that this application aims to solve. In order to solve this problem, this application provides a relevant solution in its embodiments. Business personnel can directly configure complex validation rules through a visual interface on the front end. The system automatically parses and generates corresponding code annotations, thereby decoupling from business logic and ensuring real-time updates and efficient execution of the rules. The following is a detailed description.

[0054] According to an embodiment of this application, a method embodiment for parameter verification is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0055] The method embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or electronic device) for implementing a parameter verification method is shown. Figure 1 As shown, the computer terminal 10 (or electronic device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0056] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or electronic device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0057] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the parameter verification method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the above-mentioned parameter verification method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0058] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0059] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or electronic device).

[0060] Under the above operating environment, this application provides a parameter verification method. Figure 2 This is a schematic diagram of a parameter verification method flow provided in an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0061] Step S202: In response to the rule configuration command triggered by the front-end interactive interface, generate rule language text. The front-end interactive interface displays a visual configuration option for parameter validation rules. The rule configuration command is triggered by the user dragging and dropping configuration options.

[0062] Step S204: Perform syntactic analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the validation logic in the rule language text;

[0063] Step S206: Based on the abstract syntax tree, generate target annotations and bind the target annotations to the target class. The target annotations are used to define the validation rules that the fields of the target class need to follow, so that the validator can perform validation at runtime.

[0064] Step S208: Use a validator to validate the parameter validation object according to the validation rules.

[0065] By separating business rules from validation code and allowing business personnel to directly participate in rule formulation through front-end visual configuration, the goals of reducing technical communication costs and shortening the response time for rule changes are achieved. Furthermore, parameter validation isolation and dynamic updates are realized in a multi-tenant environment, thereby solving the technical problem of low efficiency in updating parameter validation rule configurations caused by the severe coupling between the front-end and validation rule code in related technologies.

[0066] The parameter verification method in steps S202 to S208 of the embodiments of this application will be further described below.

[0067] Figure 3 This is a schematic diagram of a front-end visual parameter validation architecture based on the Drools rule engine, according to an embodiment of this application. Figure 3 As shown, this architecture mainly includes: a front-end visual rule definition and information display module, an enhanced DRL rule parsing and mapping module, a dynamic binding and validation execution module, and a rule hot update module. Through the collaborative work of these modules, this embodiment of the application can achieve tenant isolation, rule and business decoupling, and dynamic updates for front-end visual parameter validation. The following section will combine... Figure 4 The timing diagram shown illustrates the parameter verification process in the embodiments of this application.

[0068] First, the front-end visual rule definition and information display module can be used to provide business personnel with a visual operation interface (front-end interactive interface). This interface supports the definition of tenant isolation rules and the display of field metadata. Business personnel can set parameter validation rules by dragging and dropping operations on this interface, as detailed below.

[0069] In some embodiments of this application, generating rule language text in response to a rule configuration instruction triggered by the front-end interactive interface includes: determining the user identifier corresponding to the currently logged-in user account; obtaining the back-end field corresponding to the user identifier in the database and displaying the back-end field in a tree structure in the front-end interactive interface, wherein each form control in the tree structure corresponds to a back-end field; monitoring cursor movement data of the cursor dragging form controls and / or condition blocks in the front-end interactive interface, and generating a hierarchical structure based on the cursor movement data, wherein different condition blocks correspond to different logical operation relationships, and the hierarchical structure is used to represent the logical judgment rules corresponding to the back-end fields; and generating rule language text based on the hierarchical structure.

[0070] like Figure 5 As shown, the front-end interactive interface includes a tenant-isolated information display. This display allows for the presentation of backend field paths (e.g., user.address.city) in a tree structure on the front end. Each control is associated with a unique field identifier and includes a tenant ID (i.e., the user identifier corresponding to the aforementioned user account) attribute, ensuring that field metadata is loaded according to tenant isolation. Simultaneously, when retrieving backend field information from the database, this embodiment introduces a tenant-isolated loading mechanism. Based on the tenant context (e.g., the currently logged-in tenant ID), the corresponding tenant's field structure is loaded from the metadata repository, avoiding data overlap among multiple tenants.

[0071] On the other hand, the front-end interactive interface also includes an enhanced DRL rule visual definer. This definer provides drag-and-drop nested conditional block operations, automatically generates hierarchical structures with parentheses (such as (A || B) && C), and supports multi-level if-else logic. Furthermore, this visual definer also supports dynamic parameter binding, allowing form controls to be bound via field selectors, and dragging fields to automatically generate variable references such as {user.age}. It provides a drop-down selection of system parameter libraries (such as $sysVar.currentTime), supports nested object fields (such as {user.address.zipcode}) and system variable references, and also supports drag-and-drop configuration of logical operators such as &&, ||, and !, as well as set operators such as in and not in, allowing for intuitive construction of complex conditions. In addition, rule headers can be generated by selecting the tenant ID from the drop-down menu (such as tenantId: "T002"), and business personnel can input validation failure prompt text (supporting dynamic parameter templates, such as "Age ${user.age} does not meet the requirements").

[0072] Specifically, when business personnel configure validation rules, the system continuously monitors cursor movement data on the front-end interactive interface, especially data changes when dragging form controls and condition blocks. Based on this cursor movement data, it automatically generates a hierarchical structure of conditions. Different condition blocks are interconnected through logical operations to form a clearly defined set of logical judgment rules. Based on this dynamically generated hierarchical structure, the system can accurately identify the logical relationships and field references between conditions, and then translate them into the corresponding rule language text.

[0073] It should be noted that the enhanced DRL rule structure in this embodiment is based on the standard DRL extension, integrating features such as multi-tenant isolation, dynamic parameters, and nested conditions. It supports multi-level nested conditions, dynamic parameter referencing, combinational logic operations, and tenant isolation declarations. Its complete structure is as follows: Figure 6 As shown in the table below, the specific characteristics of the enhanced DRL rules are as follows.

[0074]

[0075] By introducing the tenantId declaration in the DRL rule header, tenant-level rule isolation is achieved. Furthermore, the extended DRL syntax supports multi-level nested conditions, dynamic parameters (field variables + system variables), and set operations, solving the problem of insufficient expressive power of traditional DRL in parameter validation scenarios, thereby meeting the complex validation needs of enterprises.

[0076] For example, suppose in the product information verification scenario of an e-commerce SaaS platform, the e-commerce platform supports 100+ tenants (merchants), and each tenant needs to independently configure product information verification rules (such as price range, inventory limits, category attributes, etc.), and the rules need to support the visual configuration and dynamic updates of operations personnel.

[0077] Among them, tenant T001 (clothing merchant) needs to configure the following verification rules: 1) The price of the product must be between 50 and 1000 yuan; 2) The stock quantity must be ≥10, and when the category is "pre-sale products" (category="pre_sale"), the stock quantity can be relaxed to ≥5; 3) The product name must include the brand name and the length must be ≤50 characters; 4) The rules of tenant T001 only apply to its own products.

[0078] The environment preparation and core configuration are as follows: The technology stack dependencies include: Backend: Spring Boot 2.7.x, Drools 7.74.0.Final, ANTLR 4.13.1, ASM 9.3; Frontend: Vue 3 + Element Plus (drag and drop components); Database: MySQL (storage tenant rule configuration); Core configuration files include: Drools rule engine configuration (drools-config.xml) and Spring Boot configuration class (DroolsConfig.java), etc.

[0079] Taking the example of an operations staff member configuring product validation rules for tenant T001 through a drag-and-drop interface, and the system automatically generating an enhanced DRL text, the specific operation steps are as follows:

[0080] 1. Select tenant: Select "T001" in the tenant drop-down list, and the system will automatically add tenantId: "T001" to the rule header;

[0081] 2. Configure field mapping: Associate front-end form controls with back-end fields (such as price → product price input box, stock → inventory input box);

[0082] 3. Drag and drop condition blocks:

[0083] 3.1 Drag the "Value Range" condition block and set {price} >= 50 && {price} <= 1000. The prompt text will say "Price must be between 50 and 1000 yuan".

[0084] 3.2 Drag and drop the "Combined Conditions" block to nest the settings:

[0085] 3.2.1 Outer condition: When {category} != "pre_sale", {stock} >= 10 (hint: "General merchandise inventory must be ≥10");

[0086] 3.2.2 Inner condition: When {category} == "pre_sale", {stock} >= 5 (Note: "Pre-sale inventory must be ≥ 5");

[0087] 3.3 Drag and drop the "String Validation" block, set {name} matches ".*{brand}.*" (dynamically referencing the brand field) and {name}.length <= 50, prompting "Product name must include brand name and length ≤ 50";

[0088] The final generated DRL rule text (i.e., the rule language text mentioned above) is as follows: Figure 7 As shown.

[0089] This application's embodiments design a drag-and-drop interface that automatically converts business personnel's operations (such as nested condition combinations and parameter bindings) into enhanced DRL text, breaking through the barrier of "technical personnel writing rules," lowering the threshold for business personnel participation, and solving the problem of high communication costs between business and technology in traditional solutions. In this way, the visual operations of business personnel can be transformed into accurate validation rule definitions in real time, not only simplifying the complexity of rule configuration but also enabling instant preview and generation of validation rules, greatly improving efficiency and reducing the possibility of errors.

[0090] After obtaining the rule language text, the enhanced DRL rule parsing and mapping module can be used to convert the front-end defined rules into executable Spring Validation validation logic. Specifically, in this embodiment, a four-layer parsing architecture of [DRL text] -> [ANTLR lexical / syntactic analysis] -> [Abstract Syntax Tree (AST)] -> [Rule mapping algorithm] -> [Spring annotation] can be used to convert the rule language text into target annotations. The rule language text can be converted into the corresponding abstract syntax tree first, as follows.

[0091] In some embodiments of this application, performing syntactic analysis on regular language text to obtain an abstract syntax tree includes: performing text cleaning on the regular language text, and dividing the cleaned regular language text into at least one text segment based on preset target characters, wherein the text cleaning is used to remove invalid characters from the regular language text, and each text segment corresponds to a verification rule; performing word segmentation on the text segment according to preset syntactic rules to obtain word segmentation results, wherein the preset syntactic rules are used to define the structure of the regular language; and using a syntax analyzer to perform syntactic analysis on the word segmentation results to obtain an abstract syntax tree.

[0092] like Figure 5 As shown, the DRL text (i.e. the rule language text mentioned above) can be preprocessed first, including: 1) Text cleaning: remove comments and whitespace characters from the rule text, and extract metadata such as tenant ID and rule name; 2) Rule splitting: split the multi-rule text according to preset target characters (e.g., rule keyword and end identifier), and process each validation rule independently.

[0093] After preprocessing, the ANTLR lexical and syntax analyzer is further utilized. Based on the lexical rule definition, keywords (tenantId, rule, when, etc.), operators (&&, in, matches, etc.), identifiers (field variables, system variables), and literals (strings, numbers) are defined through DRLLexer.g4 to achieve word segmentation of the rule text. Furthermore, based on the syntax rule definition, the rule structure (such as tenantId: [ID]; rule ... when ... then... end) is defined through DRLParser.g4 to parse nested conditions, dynamic parameter references, and combinational logic, generating a structured abstract syntax tree (AST).

[0094] For example, a code example of parsing the above DRL text using a custom DRL syntax file (DRLParser.g4) to generate an abstract syntax tree (AST) is shown below. Figure 8 As shown.

[0095] The complete DRLLexer.g4 file is as follows: Figure 9 As shown.

[0096] After obtaining the abstract syntax tree, target annotations can be further generated based on the abstract syntax tree, as follows.

[0097] In some embodiments of this application, generating a target annotation based on an abstract syntax tree includes: traversing the abstract syntax tree, extracting key information from the abstract syntax tree, and constructing an intermediate representation result based on the key information, wherein the key information includes at least one of the following: conditional expression, logical relationship, and validation prompt information; mapping the intermediate representation result to an annotation corresponding to the condition type based on the condition type to obtain the target annotation.

[0098] Specifically, an AST accessor can be used: implement the ParseTreeVisitor interface of ANTLR, traverse the AST nodes, extract conditional expressions (such as {user.age} < 18), logical relationships (such as &&, ||), and validation prompts (i.e., the key information mentioned above); then, by constructing ConditionNodes (including SimpleConditionNodes and CompositeConditionNodes), nested logic can be expressed through the node hierarchy, while the tenant ID and prompt text can be associated to obtain intermediate representation results.

[0099] For example, a code example of traversing the AST using DRLConditionVisitor to construct a ConditionNode (intermediate representation) is shown below. Figure 10 As shown.

[0100] Furthermore, mapper registration can be performed to establish a mapping relationship between DRL conditions and Spring Validation annotations (e.g., {field} < value maps to @Min, matches maps to @Pattern), and custom mapper extensions are supported. Based on the condition type corresponding to the intermediate representation result, the intermediate representation result can be mapped to the annotation corresponding to the condition type. For example, SimpleConditionNode can be directly mapped to the basic annotation (e.g., @Max); custom validator annotations can be generated for CompositeConditionNode (e.g., A || B) (e.g., @AssertTrue binds to CustomOrValidator), carrying the condition expression and prompt text.

[0101] For example, here's a code example of converting a ConditionNode to a SpringValidation annotation using AnnotationGenerator: Figure 11 As shown.

[0102] After obtaining the target annotation, the dynamic binding and validation execution module can be used to dynamically bind the parsed validation rules to the backend fields and perform tenant isolation parameter validation, including binding the target annotation to the target class, as follows.

[0103] In some embodiments of this application, binding a target annotation to a target class includes: generating a bytecode file containing the target annotation; inserting the bytecode file into the bytecode structure of the field corresponding to the target annotation in the target class during the target class loading process; and updating the mapping relationship between the field and the target annotation in the cache.

[0104] like Figure 12 As shown, a bytecode file containing validation annotations can be dynamically generated based on the parsed AnnotationNode. Then, using a class loader hook and a custom class loader, the generated annotation bytecode is inserted into the bytecode structure of the corresponding field when the target Java class (such as the User entity) is loaded, achieving non-intrusive binding. Simultaneously, mapping caching is implemented to maintain a field-annotation association cache; when rules are updated, only the annotations for the changed fields are regenerated, improving binding efficiency.

[0105] For example, a code example of dynamically binding generated annotations to fields of the target class (Product) using ASM bytecode technology is shown below. Figure 13 As shown.

[0106] This application proposes a parsing process of "DRL text preprocessing → ANTLR lexical / syntactic analysis → AST intermediate representation → Spring annotation mapping". Combined with ASM bytecode generation technology, it realizes the dynamic conversion and binding of complex rules to SpringValidation annotations, solving the pain point that traditional static annotations cannot support dynamic rules.

[0107] Then, a validator can be used to validate the parameter validation object according to the validation rules, as follows.

[0108] In some embodiments of this application, using a validator to validate a parameter validation object according to validation rules includes: determining the user identifier corresponding to the parameter validation object; determining the target annotation corresponding to the user identifier; and calling a validator corresponding to the annotation type to validate the parameter validation object based on the annotation type corresponding to the target annotation.

[0109] Specifically, during validation, tenant isolation validation can be implemented. By using a custom ConstraintValidator, the current tenant ID (user identifier) ​​is extracted from the context during validation, the corresponding tenant's rules (matching the tenantId field) are loaded, and only tenant-specific validation logic is executed. Simultaneously, validation supports nested objects and dynamic parameter handling: it supports recursive parsing of nested object fields (such as user.address.zipcode) and real-time calculation of system variables (such as $sysVar.currentYear) and dynamic parameters (such as ${user.age}). Furthermore, validation also supports Spring Validation integration: by extending Spring Validation's Validator interface, custom validators can be incorporated into the validation process, executing complex logic (such as combined conditional judgments) according to bound annotations, and returning results containing error codes and templated prompts.

[0110] For example, a code example of executing validation logic through a custom ConstraintValidator and loading the corresponding rules in conjunction with the tenant context is shown below. Figure 14 As shown.

[0111] In addition, in this embodiment of the application, the rule change can be dynamically applied through the rule hot update module without restarting the application, as detailed below.

[0112] In some embodiments of this application, the method further includes: monitoring whether the rule language text has been updated; if the rule language text has been updated, regenerating the target annotation based on the updated rule language text, and binding the newly generated target annotation to the target class; and refreshing the validator's cache to ensure that the new validation rules take effect.

[0113] Specifically, Drools' KieScanner can be used to monitor DRL file changes (such as rule modifications for tenant T002) in real time, i.e., to monitor whether the rule language text has been updated. If the rule language text has been updated, the DRL file is recompiled, the rule parsing module is called to generate a new AnnotationNode, and the annotation bytecode of the target class is reset using ASM technology, refreshing the field-annotation mapping cache and the Spring Validation validator cache. After the update is completed, the new rule can be immediately applied to subsequent parameter validation, while the old rule automatically becomes invalid.

[0114] For example, when tenant T001 modifies the pricing rules (e.g., adjusts them to 50-1500 yuan), the system can automatically perform a hot update, as follows: 1) KieScanner monitors changes: KieScanner scans the DRL file every 30 seconds, triggering recompilation upon detecting modifications; 2) Re-parsing and binding: Regenerates new annotations and updates the bytecode of the Product class via ASM; 3) Refreshes the Spring cache: Clears the Spring Validation validator cache to ensure the new rules take effect. A code example for the rule hot update is shown below. Figure 15 As shown.

[0115] Through the collaboration of the aforementioned modules, this embodiment of the application enables the visual definition of parameter validation rules, tenant isolation, decoupling from business logic, and dynamic updates. It solves the problems in related technologies where modifications to validation logic require development and deployment, and the inability to support customized rules for multiple tenants. For the illustrated case, tenant isolation validation is implemented, meaning that the rules for tenant T001 only apply to their products, while the validation of products for tenant T002 remains unaffected. Dynamic update validation is also implemented; after modifying the price rules, the new rules take effect within 10 minutes without requiring an application restart. Simultaneously, complex validation is supported, successfully supporting scenarios such as nested conditions (regular / pre-sale product inventory) and dynamic parameter referencing (product names including brands). Rule maintenance efficiency is improved by 400%, and code volume is reduced by 50% (no need to manually write validation logic).

[0116] This application's solution separates business rules from validation code using the Drools rule engine, decoupling business rules and validation logic. This enables independent rule maintenance, reducing the amount of code development related to validation logic modifications by 80% and lowering maintenance costs. It employs an enhanced DRL structure with tenantId declarations in the rule header, achieving physical isolation of validation rules in a multi-tenant environment and resolving the issue of rule cross-contamination in multi-tenant systems. A drag-and-drop interface allows business personnel to define validation rules based on DroolsDRL, enabling direct participation in rule configuration, reducing communication costs between technology and business, and lowering the rule error rate due to misunderstandings. It supports hot rule updates, allowing new rules to take effect without restarting the application, reducing business change response time from "days" (traditional development and deployment) to "minutes," meeting the high agility requirements of industries such as finance and e-commerce. Through the enhanced DRL structure, it supports complex validation scenarios such as multi-level nested conditions, dynamic parameter references, and combined logic, meeting the full lifecycle needs of enterprise-level systems from simple to complex validation scenarios and avoiding redundant construction.

[0117] In practical project applications, the solution proposed in this application has improved the efficiency of maintaining verification rules by 400%, shortened the rule change response time from 2 days to 10 minutes, and reduced the amount of verification-related code by 50%, significantly improving the maintainability of the system and the speed of business response.

[0118] The proposed solution has the following possible application scenarios:

[0119] 1) Multi-tenant SaaS platform: such as e-commerce SaaS (different merchants have different verification rules for product information) and CRM SaaS (different enterprises have isolated verification logic for customer data), which realizes "one platform with multiple rules" management through tenant-level rule isolation;

[0120] 2) Fintech systems: such as credit approval systems (risk control rules are frequently adjusted) and payment systems (parameter verification rules for different channels are dynamically updated), which can quickly respond to changes in regulatory policies through hot update mechanisms;

[0121] 3) Enterprise-level form systems: such as OA approval forms and ERP data entry forms. Business personnel can configure multi-level nested conditions through a visual interface (such as "department = sales and years of service > 3 years to apply for a certain permission") without the need for technical personnel intervention;

[0122] 4) Complex data structure validation scenarios: such as order systems (containing nested objects such as user information, product details, logistics addresses, etc.), supporting deep field validation such as {order.items[0].price} > 1000 and dynamic parameter calculation (such as $sysVar.currentDate - {order.createDate} > 30).

[0123] According to an embodiment of this application, an embodiment of a parameter verification device is also provided. Figure 16 This is a schematic diagram of a parameter verification device provided according to an embodiment of this application. Figure 16 As shown, the device includes:

[0124] The rule text generation module 160 is used to generate rule language text in response to rule configuration instructions triggered by the front-end interactive interface. The front-end interactive interface displays visual configuration options for parameter validation rules, and the rule configuration instructions are triggered by the user dragging and dropping configuration options.

[0125] The syntax tree construction module 162 is used to perform syntax analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the validation logic in the rule language text;

[0126] The target annotation generation module 164 is used to generate target annotations based on the abstract syntax tree and bind the target annotations to the target class. The target annotations are used to define the validation rules that the fields of the target class need to follow, so that the target class can be validated by the validator at runtime.

[0127] The parameter verification execution module 166 is used to verify the parameter verification object according to the verification rules using a verifier.

[0128] Optionally, in response to a rule configuration command triggered by the front-end interactive interface, generating rule language text includes: determining the user identifier corresponding to the currently logged-in user account; obtaining the back-end field corresponding to the user identifier from the database and displaying the back-end field in a tree structure in the front-end interactive interface, wherein each form control in the tree structure corresponds to a back-end field; monitoring cursor movement data of the cursor dragging operations on form controls and / or condition blocks in the front-end interactive interface, and generating a hierarchical structure based on the cursor movement data, wherein different condition blocks correspond to different logical operation relationships, and the hierarchical structure is used to represent the logical judgment rules corresponding to the back-end fields; and generating rule language text based on the hierarchical structure.

[0129] Optionally, performing syntactic analysis on the rule-based language text to obtain an abstract syntax tree includes: performing text cleaning on the rule-based language text, and dividing the cleaned text into at least one text segment based on preset target characters, wherein the text cleaning is used to remove invalid characters from the rule-based language text, and each text segment corresponds to a validation rule; performing word segmentation on the text segment according to preset syntactic rules to obtain word segmentation results, wherein the preset syntactic rules are used to define the structure of the rule-based language; and using a syntax analyzer to perform syntactic analysis on the word segmentation results to obtain an abstract syntax tree.

[0130] Optionally, generating the target annotation based on the abstract syntax tree includes: traversing the abstract syntax tree, extracting key information from the abstract syntax tree, and constructing an intermediate representation result based on the key information, wherein the key information includes at least one of the following: conditional expression, logical relationship, and validation prompt information; mapping the intermediate representation result to the annotation corresponding to the condition type based on the condition type to obtain the target annotation.

[0131] Optionally, binding the target annotation to the target class includes: generating a bytecode file containing the target annotation; inserting the bytecode file into the bytecode structure of the field corresponding to the target annotation in the target class during the target class loading process; and updating the mapping relationship between the field and the target annotation in the cache.

[0132] Optionally, the parameter validation device is also used to: monitor whether the rule language text has been updated; if the rule language text has been updated, regenerate the target annotation based on the updated rule language text and bind the newly generated target annotation to the target class; and refresh the validator's cache to ensure that the new validation rules take effect.

[0133] Optionally, a validator is used to validate the parameter validation object according to the validation rules, including: determining the user identifier corresponding to the parameter validation object; determining the target annotation corresponding to the user identifier; and calling the validator corresponding to the annotation type to validate the parameter validation object based on the annotation type corresponding to the target annotation.

[0134] It should be noted that each module in the above parameter verification device can be a program module (for example, a set of program instructions to implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0135] It should be noted that the parameter verification device provided in this embodiment can be used to perform... Figure 2The parameter verification method shown above is also applicable to the embodiments of this application, and will not be repeated here.

[0136] This application embodiment also provides a non-volatile storage medium, which includes a stored computer program. The device containing the non-volatile storage medium executes the following parameter verification method by running the computer program: responding to a rule configuration command triggered by a front-end interactive interface, generating rule language text, wherein the front-end interactive interface displays visual configuration options for parameter verification rules, and the rule configuration command is triggered by the user dragging and dropping configuration options; performing syntactic analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the verification logic in the rule language text; generating target annotations based on the abstract syntax tree, and binding the target annotations to a target class, wherein the target annotations are used to define the verification rules that the fields of the target class must follow, so that the target class can be verified by a validator at runtime; and using a validator to verify the parameter verification object according to the verification rules.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the parameter verification method described in various embodiments of this application: responding to a rule configuration instruction triggered by a front-end interactive interface, generating rule language text, wherein the front-end interactive interface displays visual configuration options for parameter verification rules, and the rule configuration instruction is triggered by the user dragging and dropping configuration options; performing syntactic analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the verification logic in the rule language text; generating target annotations based on the abstract syntax tree, and binding the target annotations to the target class, wherein the target annotations are used to define the verification rules that the fields of the target class need to follow, so that the target class can be verified by a validator at runtime; and using a validator to verify the parameter verification object according to the verification rules.

[0138] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0139] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0141] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0143] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0144] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of parameter verification, characterized by, The method comprises the following steps: In response to a rule configuration instruction triggered by a front-end interactive interface, a rule language text is generated, wherein the front-end interactive interface displays visual configuration options of parameter verification rules, and the rule configuration instruction is triggered by a user dragging the configuration options; Syntax analysis is performed on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree represents the verification logic in the rule language text; According to the abstract syntax tree, a target annotation is generated, and the target annotation is bound to a target class, wherein the target annotation defines the verification rules that the fields of the target class need to comply with, so that the fields are verified by a verifier during the runtime of the target class; The verifier is used to verify the parameter verification object according to the verification rules.

2. The parameter verification method of claim 1, wherein, In response to a rule configuration instruction triggered by a front-end interactive interface, a rule language text is generated, which includes: Determine the user identifier corresponding to the currently logged-in user account; Obtain the backend fields corresponding to the user identifier in the database, and display the backend fields in a tree structure in the front-end interactive interface, wherein each form control in the tree structure corresponds to a backend field; Monitor the cursor movement data of the cursor on the front-end interactive interface for the drag operation of the cursor on the form controls and / or condition blocks in the front-end interactive interface, and generate a hierarchical structure according to the cursor movement data, wherein different condition blocks correspond to different logical operation relationships, and the hierarchical structure represents the logical judgment rules corresponding to the backend fields; According to the hierarchical structure, the rule language text is generated.

3. The parameter verification method of claim 1, wherein, Syntax analysis is performed on the rule language text to obtain an abstract syntax tree, which includes: Text cleaning processing is performed on the rule language text, and the rule language text after the text cleaning processing is divided according to a preset target character to obtain at least one text segment, wherein the text cleaning processing is used to remove invalid characters in the rule language text, and each text segment obtained by the division corresponds to a verification rule; According to a preset grammar rule, the text segments are subjected to word segmentation processing to obtain a word segmentation result, wherein the preset grammar rule defines the structure of the rule language; Using a grammar analyzer, the word segmentation result is subjected to syntax analysis to obtain the abstract syntax tree.

4. The parameter verification method according to claim 3, characterized in that, According to the abstract syntax tree, a target annotation is generated, which includes: By traversing the abstract syntax tree, key information in the abstract syntax tree is extracted, and an intermediate representation result is constructed according to the key information, wherein the key information includes at least one of the following: a conditional expression, a logical relationship, and verification prompt information; According to the condition type corresponding to the intermediate representation result, the intermediate representation result is mapped to an annotation corresponding to the condition type to obtain the target annotation.

5. The parameter verification method of claim 1, wherein, The target annotation is bound to a target class, which includes: A bytecode file containing the target annotation is generated; In the process of loading the target class, the bytecode file is inserted into the bytecode structure of the field corresponding to the target annotation in the target class; Update the mapping relationship between the field and the target annotation in the cache.

6. The parameter verification method according to claim 5, wherein The method further comprises: monitoring whether the rule language text is updated; in the case of detecting that the rule language text has been updated, re-generating the target annotation based on the updated rule language text, and binding the newly generated target annotation to the target class; refreshing the cache of the checker to ensure that the new verification rule takes effect.

7. The parameter verification method of claim 1, wherein, The parameter verification method comprises: determining a user identifier corresponding to the parameter verification object; determining the target annotation corresponding to the user identifier; according to the annotation type corresponding to the target annotation, calling the checker corresponding to the annotation type to verify the parameter verification object.

8. A parameter verification apparatus, characterized by comprising: The method comprises: a rule text generation module configured to generate a rule language text in response to a rule configuration instruction triggered by a front-end interactive interface, wherein the front-end interactive interface displays a visual configuration option of a parameter verification rule, and the rule configuration instruction is triggered by a user dragging the configuration option; a syntax tree construction module configured to perform syntax analysis on the rule language text to obtain an abstract syntax tree, wherein the abstract syntax tree is used to represent the verification logic in the rule language text; a target annotation generation module configured to generate a target annotation according to the abstract syntax tree, and bind the target annotation to a target class, wherein the target annotation is used to define the verification rule required to be followed by the field of the target class, so as to be verified by a checker when the target class is running; a parameter verification execution module configured to use the checker to verify a parameter verification object according to the verification rule.

9. An electronic device, comprising: The method comprises: a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program is configured to perform the parameter verification method of any one of claims 1 to 7 when running.

10. A non-volatile storage medium, comprising: The non-volatile storage medium comprises a stored computer program, wherein the device in which the non-volatile storage medium is located performs the parameter verification method of any one of claims 1 to 7 by running the computer program.

11. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the parameter verification method of any one of claims 1 to 7.

Images