Data verification method and electronic equipment

Abstract

The invention discloses a data verification method and electronic equipment, and relates to the technical field of electric digital data processing, metadata can be scanned to identify a target entry point of the metadata, and a plurality of associated verification items of to-be-verified data corresponding to the target entry point can be determined through annotations of the target entry point and corresponding target verification rules, so that the verification efficiency of the to-be-verified data is improved. And verifying the to-be-verified data by using the target verification rule and the plurality of associated verification items, thereby solving the technical problems that in related technologies, association between business logics cannot be perceived, a static verification technology is difficult to meet dynamic business logic requirements, and thus the user experience is affected, reducing the complexity of computer readable instructions, and improving the user experience. According to the method and the device, a plurality of associated verification items needing to be verified are dynamically determined, so that a very complex business verification scene is processed, and the technical effect of efficient and reliable data verification is achieved.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to data verification methods and electronic devices. Background Technology

[0002] In related technologies, when developing interfaces using Spring, Spring Validation is typically used to validate the received data. This achieves a certain degree of decoupling between business logic and data validation rules. However, the validation rules for each field are hard-coded into the program. When modifying or adding validation rules, the program must be repackaged and deployed to take effect. Validation rules are entangled with core business logic, making unified management difficult and obscuring the relationships between business logic elements. Static validation techniques are insufficient to meet the needs of dynamic business logic, thus impacting user experience and urgently requiring improvement. Summary of the Invention

[0003] This application provides a data verification method and electronic device to at least solve the technical problems in related technologies, such as verification rules being entangled with core business logic, making unified management difficult, failing to perceive the relationship between business logic, and making it difficult to meet the needs of dynamic business logic using static verification technology, thereby affecting the user experience.

[0004] This application provides a data verification method, including: scanning the metadata when the target program is loaded and started to identify the target entry point of the metadata; identifying the annotation of the target entry point in the metadata and obtaining the target verification rule corresponding to the target entry point; determining whether the target verification rule meets the preset expression rule condition; if it meets the preset expression rule condition, determining multiple associated verification items of the data to be verified corresponding to the target entry point based on the target verification rule, so as to verify the data to be verified by using the target verification rule and the multiple associated verification items.

[0005] This application also provides a data verification device, comprising: a scanning module for scanning metadata when a target program is loaded and started to identify target entry points in the metadata; an identification module for identifying annotations of the target entry points in the metadata and obtaining target verification rules corresponding to the target entry points; and a verification module for determining whether the target verification rules meet preset expression rule conditions. If the preset expression rule conditions are met, multiple associated verification items of the data to be verified corresponding to the target entry points are determined based on the target verification rules, so as to verify the data to be verified using the target verification rules and multiple associated verification items.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described data verification methods when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described data verification methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described data verification methods.

[0009] This application enables the scanning of metadata at program startup, centrally identifying and loading all annotation-defined rules. This provides a foundation for unified management of validation rules, increases scalability and maintainability, identifies target entry points in metadata, and dynamically weaves validation logic into target methods or fields non-intrusively through entry points and runtime scanning. By using the annotations of the target entry points and the corresponding target validation rules, multiple associated validation items of the data to be validated corresponding to the target entry point can be determined. The data to be validated is then validated using the target validation rules and multiple associated validation items, dynamically determining a set of associated fields to achieve complex logic validation. This solves the technical problems in related technologies where validation rules are entangled with core business logic, making unified management difficult and the relationships between business logics undetectable. Static validation techniques are also difficult to meet the needs of dynamic business logic, thus affecting user experience. This application reduces the complexity of computer-readable instructions, dynamically determines multiple associated validation items that need to be validated, handles very complex business validation scenarios, and achieves efficient and reliable data validation. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of a data verification method provided according to an embodiment of this application; Figure 2 This is a flowchart of a data verification method provided according to an embodiment of this application; Figure 3 This is a schematic diagram of a data verification device provided according to an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] Understandably, when developing APIs using Spring, Spring Validation is typically used to validate the received data. This decouples business logic from data validation rules to some extent. However, the validation rules for each field are hard-coded into the program, and any modifications or additions to the validation rules require repackaging and redeploying the program for them to take effect.

[0016] Furthermore, Spring Validation can only validate properties passed through APIs, and cannot achieve more flexible data validation. In the following scenario, when a front-end API modifies an object, it needs to first retrieve the object's saved data values ​​and then evaluate the saved data properties. Modification is only allowed if the properties meet specified conditions. In this scenario, Spring Validation cannot meet the requirements.

[0017] While other dynamic validation frameworks have achieved dynamic configuration of rules, they have not achieved persistence and visualization of validation data.

[0018] For example, when developing APIs using Spring, Spring Validation is typically used to validate the transmitted data. This involves using Spring-defined annotations such as @NotNull, @NotEmpty, @Size, and @Range to validate the attribute values ​​passed from the front end, thus achieving initial data validation. See below: public class Team { @NotNull(message = "ID cannot be empty") private Long id; @NotNull(message = "Name cannot be empty") @Size(max = 200, message = "Length cannot exceed 200") private String name; } While some technologies exist that can decouple data validation rules from the application, allowing for flexible adjustments to these rules as business scenarios change, certain drawbacks remain: validation rules are hard-coded into computer-readable instructions, requiring recompilation and deployment when rules are modified or added to other fields, impacting system availability; all validation rules are scattered across various objects, lacking unified management; validation can only be performed on object attributes passed from the front end, not on object attributes retrieved from the database or other locations; and complex validation cannot be implemented.

[0019] To address the aforementioned technical issues, this application's embodiments consider the challenges of rule validation encountered in daily development. Taking into account the situation where each method needs to validate existing data or data transmitted from the front end before implementing specific functions, but relying solely on Spring Validation cannot handle more complex and varied scenarios, a data validation method is proposed based on this.

[0020] like Figure 1 The embodiments of this application provide a data verification method, including the following steps: In step S101, the metadata at the time the target program is loaded and started is scanned to identify the target entry point of the metadata.

[0021] The target program can be an application under development that needs to have validation functionality added, such as a backend service program: a web application based on Spring Boot, etc.

[0022] This application embodiment allows the framework to scan the classpath, instantiate beans, and process various metadata information during the initialization of the Spring container and loading of bean definitions when the target program is loaded and started—that is, when the application (such as a JAR or WAR file) is started by a container (such as Tomcat) or Java command line. Metadata can refer to data describing data, that is, data describing the structure of the program itself.

[0023] This application embodiment can understand the structure of the program by scanning and reading these metadata, thereby knowing which class and method should execute additional logic (such as validation), and thus obtaining the corresponding target entry point. The target entry point defines at which execution point of the program to perform lateral intervention.

[0024] Optionally, in one embodiment of this application, scanning the metadata when the target program is loaded and started to identify the target entry point of the metadata includes: scanning at least one aspect of the metadata that meets the preset annotation identification conditions; and using the annotation identification method preset in the at least one aspect to identify the target entry point.

[0025] In actual execution, the embodiments of this application can pre-encapsulate aspect classes such as ValidAspect for validation rules, as well as aspect advice methods and pointcut methods, etc. When the target program starts, the aspect is scanned and identified, and the target pointcut in the metadata is identified through the annotation identification method pre-encapsulated in the aspect.

[0026] In this embodiment, the verification logic can be encapsulated in an aspect, completely separated from the computer-readable instructions of the core business. Developers only need to use annotation marking methods and write aspect rules to implement complex interception logic, instead of using intrusive computer-readable instructions. This also enables unified management of verification rules. When verification rules need to be updated or modified, there is no need to stop the system. Verification rules can be modified through hot updates.

[0027] Optionally, in one embodiment of this application, after scanning at least one aspect that meets the preset annotation recognition conditions in the metadata, the method further includes: storing at least one of the verification rule identifier, identifiable parameter location information, and identifiable parameter data type in the annotation recognition method into a preset database table, so as to match the corresponding aspect from the preset database table based on the annotation of the target entry point.

[0028] This application embodiment can scan and identify all relevant aspects and pointcuts during the startup phase, then structure this information and persist it to a preset database table. The stored information includes the parameter positions, parameter data types, and identification names of validation rules in the pointcut reading method.

[0029] For example, when the program runs and reaches a target point of attack, this embodiment of the application can view the annotation information on that point of attack and then use this information to query the previously initialized database table. By matching, the corresponding record is found, thereby determining which aspect should perform the validation and which parameter should be validated (based on parameter location information and parameter data type).

[0030] This application's embodiments completely decouple validation rules from computer-readable instructions. Operations or business personnel can dynamically enable, disable, or modify the mapping relationship between validation rules and aspects by modifying records in the database table without restarting the application. All validation rule mapping relationships can be viewed and managed in a unified database interface, providing significant operational convenience. At runtime, validation behavior is determined based on database query results, enabling it to adapt to extremely complex and ever-changing business scenarios. For example, by switching validation rule identifiers in the database, the same annotation can point to different validation aspect logic in different environments or conditions.

[0031] Optionally, in one embodiment of this application, the method further includes: receiving a verification rule update instruction; obtaining a new verification rule based on the verification rule update instruction; and updating the rule parsing engine in the corresponding aspect using the new verification rule.

[0032] Furthermore, embodiments of this application can receive verification rule update instructions from maintenance personnel to add verification rules and update the parsing engine such as ValidParser that parses SpEL expression rules, so as to ensure the normal use of verification rules.

[0033] In this embodiment, only a new record needs to be inserted into the database (and the corresponding aspect class needs to be deployed), without modifying any existing computer-readable instructions of the business or the computer-readable instructions of the aspect configuration, so as to ensure business continuity and business efficiency.

[0034] In step S102, the annotation of the target entry point is identified in the metadata, and the target verification rule corresponding to the target entry point is obtained.

[0035] Annotations are a special interface in Java used to provide metadata for computer-readable instructions. They can be prefixed with the @ symbol (e.g., @ValidPoint, @ValidParam).

[0036] In this embodiment of the application, annotations can be predefined, and then the annotations can be affixed to the entry points that require complex verification.

[0037] In actual execution, users can view the scanned data information using the web front-end page, specify the verification rules according to the function to be implemented by the caller, and thus obtain the target verification rules. The target verification rules are the specific information carried by the annotation. When the annotation is scanned, the rules defined therein will be retrieved and executed accordingly.

[0038] Optionally, in one embodiment of this application, the method further includes: pushing data information corresponding to metadata to a front-end page; receiving a verification rule switch instruction input by the user based on the front-end page; and obtaining a target verification rule based on the verification rule switch instruction.

[0039] In actual implementation, this application embodiment can display the data information described by the metadata to the user to show the corresponding business data. The front-end page (such as a form built with React / Vue) can dynamically render the corresponding form elements, tags, and initial validation rule prompts based on this metadata.

[0040] After displaying the initial rules defined by metadata, the front-end page can provide interaction to the user, allowing the user to temporarily adjust these validation rules.

[0041] After receiving the instructions from the user, the backend service will combine and calculate the preset metadata rules with the user's personalized instructions to determine the target verification rules.

[0042] The embodiments of this application can be adapted to personalized needs, facilitate user operation, improve user experience, facilitate unified management of verification rules, and achieve more efficient data verification.

[0043] Optionally, in one embodiment of this application, after identifying the annotation of the target entry point in the metadata, the method further includes: identifying a business class identification method that meets the preset business annotation marking conditions among multiple annotation identification methods; extracting the identification method to be called from the business identification methods based on the annotation of the target entry point; and updating at least one of the identification information, signature information, target information in the corresponding target entry point annotation, verification information, and mapping relationship between the identification method to be called and multiple identifiable parameters to a preset database table.

[0044] As one possible approach, this application embodiment can, after finding the target entry point with annotations, further analyze which of the multiple annotation recognition methods are truly related to the core business logic, i.e., which can be used to parse the target entry point in the metadata, to obtain the recognition method to be called.

[0045] This application embodiment can write detailed information about the identification method to be invoked into a preset database table. This information may include: identification information, signature information, target information, verification information, and mapping relationships (defining the correspondence between the identification method to be invoked and the method parameters to be processed), etc.

[0046] For example, in this embodiment of the application, methods such as Java Agent or ASM bytecode parsing can be used to find out which callers in the Service class have called methods marked with @ValidPoint (these methods that call @ValidPoint methods are called calling methods). The class of the calling method, the method name, the method signature, the relevant information specified in the @ValidPoint annotation, and whether it is validated are recorded in the database table valid_meta. At the same time, the one-to-many relationship between the calling method and the parameters is updated in the valid_meta_param table.

[0047] This application embodiment can persist all mapping relationships and metadata of the processing logic itself to the database. This completely decouples changes to business rules from the deployment of computer-readable instructions. By querying the database, this application embodiment can not only know "verification is required," but also precisely know "which method of which class should be called to perform the verification," achieving very fine-grained dynamic behavior dispatch.

[0048] Optionally, in one embodiment of this application, after identifying the annotation of the target entry point in the metadata, the method further includes: identifying the annotation type of the target entry point; if the annotation type is a parameter reading type, then reading the parameter data corresponding to the target entry point in the metadata; if the annotation type is a business logic type, then using the target verification rules to verify the data to be verified corresponding to the target entry point.

[0049] This application embodiment can classify the identified annotations, wherein parameter reading type annotations are used to extract or transform data, and business logic type annotations are used to perform specific business rule verification.

[0050] For annotations of parameter reading type, this application embodiment can obtain parameters such as user information, so as to make corresponding calls when multiple business logic type annotations need to be validated.

[0051] For annotations of business logic types, this application embodiment can use target validation rules to execute corresponding validation logic on the data to be validated.

[0052] The embodiments of this application can decompose a complex verification task into multiple sequentially executed, single-responsibility steps. This makes the verification logic clearer.

[0053] In step S103, it is determined whether the target verification rule meets the preset expression rule condition. If the preset expression rule condition is met, then based on the target verification rule, multiple associated verification items of the data to be verified corresponding to the target entry point are determined, so as to use the target verification rule and multiple associated verification items to verify the data to be verified.

[0054] First, the embodiments of this application can determine the target verification rules, such as whether the target verification rules can be correctly parsed and whether the target verification rules are enabled or disabled. Under the condition of satisfying the preset expression rule conditions, the embodiments of this application can combine the actual business object to be verified, i.e. the data to be verified, to determine one or more specific fields and their rules that need to be verified under specific conditions, and perform specific verification logic on these items.

[0055] For example, when the expression condition (age > 18) is met, the associated validation item might be the idCard field (which needs to be 18 characters long and conform to the validation rules). When the condition is not met, the associated validation item becomes the email field (which needs to conform to the email address format).

[0056] Optionally, in one embodiment of this application, if the target verification rule meets the preset expression rule conditions, the method further includes: calling the corresponding historical data in a preset database table based on the annotation of the target entry point and the target verification rule; comparing the historical data with the data to be verified corresponding to the target entry point to obtain a comparison result; and using the comparison result to verify the data to be verified.

[0057] In some embodiments, this application can retrieve corresponding historical data from a preset database table based on the annotations of the currently executing target entry point and specific target verification rules. The historical data is then compared with the currently processed data to be verified to obtain a comparison result, which is used to determine whether the status change of the verification data meets business expectations.

[0058] For example, when operations and maintenance personnel need to modify a project, the historical data corresponding to the project is obtained, including the identification information of the user who created the project. Only when the identification information of the user who created the project corresponds to the identification information of the operations and maintenance personnel who are currently modifying the project is the operations and maintenance personnel allowed to perform the project modification action.

[0059] In addition, during the verification process, historical data can be compared to confirm whether there are any business logic problems. For example, if the result of this verification is that the order has been shipped, while the result stored in the historical data is that the order has been canceled, this indicates that there is a logical error, and the data to be verified will fail the verification.

[0060] The embodiments of this application can verify the continuity of business rules, safeguard business logic, and prevent illegal or fraudulent data tampering, thus greatly improving the security of the system.

[0061] Optionally, in one embodiment of this application, the method further includes: identifying the verification result of the data to be verified; if the verification result is a verification failure, generating an error reminder, and matching the corresponding input reminder based on the verification result.

[0062] In some embodiments, when there is an error in the entered data, i.e. the verification fails, the error message of the verification rule is obtained, sent and returned to the front-end page so that the user or maintenance personnel can modify the data according to the reminder.

[0063] Combination Figure 2 As shown, the working principle of the data verification method of this application embodiment will be described in detail with reference to one embodiment.

[0064] like Figure 2 As shown, embodiments of this application may include the following steps: Step S201, Metadata Definition: Annotations, Table Structure, SpEL Parsing Engine.

[0065] This application embodiment can write annotations for marking pointcuts in the aspect-oriented programming process, such as @ValidPoint (business logic type annotation); annotations for marking parameters when reading dynamically available parameters, such as @ValidParam (parameter reading type annotation); aspect classes that encapsulate validation rules, such as ValidAspect, and the aspect advice methods and pointcut methods contained therein, etc.

[0066] This application embodiment can be used to write a scanning class, such as ValidScanner, that identifies the annotations of pointcut annotation methods in all Service classes when the program starts.

[0067] In this application embodiment, database tables for scan results, such as valid_meta, valid_param, valid_rule, valid_meta_param, and valid_meta_rule, can be defined to store the corresponding data respectively.

[0068] This application embodiment can be used to write a front-end page that needs to display the database scan results.

[0069] The embodiments of this application can be used to write a parsing engine such as ValidParser to parse SpEL expression rules.

[0070] Step S202, program starts: parsing metadata such as annotations, aspects, and pointcuts.

[0071] The embodiments of this application can dynamically extract basic metadata information when the program is loaded and started.

[0072] This application embodiment can scan methods marked with @ValidPoint in a specified Service class, read information such as parameter position, parameter data type, and identification name of validation rule in the pointcut method, and record it in the database table valid_param.

[0073] Step S203, Data Persistence: Persist the parsed metadata.

[0074] In this embodiment, methods such as Java Agent or ASM bytecode parsing can be used to find which callers in the Service class have called methods marked with @ValidPoint (these methods that call @ValidPoint methods are called calling methods). The class of the calling method, the method name, the method signature, the relevant information specified in the @ValidPoint annotation, and whether it is validated are recorded in the database table valid_meta. At the same time, the one-to-many relationship between the calling method and the parameters is updated in the valid_meta_param table.

[0075] Step S204, Rule Definition: Define the validation rules using SpEL expressions.

[0076] Users can view the data information scanned in step S202 using the web front-end page and specify the verification rules according to the function to be implemented by the caller.

[0077] Step S205, Rule Persistence: After the parsing engine verifies that the rule is correct, it persists the rule.

[0078] The validation rules support setting one or more rules, and each rule can specify an error message for validation failure. The validation rules are saved to the `valid_rule` table in the database, and the one-to-many relationship between the calling method and the validation rules is updated in the `valid_meta_rule` table. Validation rules should conform to SpEL expression rules. During saving, the system checks whether the rules can be correctly parsed to ensure proper use later. The page displays which variable names can be used in this validation rule.

[0079] If the verification rules change later, you only need to reset the verification rules and save them; there is no need to restart the application.

[0080] Step S206, Interface Request: Call the specified method.

[0081] In this embodiment of the application, a switch can be specified for each verification rule to indicate whether the verification should be started. The rule will only take effect when verification is enabled in step S203 and a specific verification rule is also enabled.

[0082] Step S207, Rule Validation: The parsing engine validates the rules to determine if they pass.

[0083] Once the validation rules are defined, users access the interface to execute the calling method. When the calling method reaches the method annotated with @ValidPoint, it is intercepted by the AOP aspect and the actual rule validation is executed.

[0084] After AOP aspect interception, the Advice method can find the record information in the valid_meta database of the calling method through the calling thread stack information or other means, and obtain one or more dynamically specified validation rules.

[0085] The obtained verification rules are parsed one by one into executable Java computer-readable instructions using the SpEL parser, and then the verification is performed.

[0086] Step S208: Throw an exception and return.

[0087] If the validation fails, the error message of the validation rule is retrieved, displayed, and returned to the front-end page.

[0088] Step S209: Continue executing subsequent computer-readable instructions.

[0089] If the verification passes, the computer-readable instructions for subsequent logic will continue to be executed.

[0090] Based on the above steps, the following embodiments illustrate the practical application of the data verification method of this application.

[0091] The embodiments of this application describe the verification process when maintenance personnel modify projects.

[0092] The system backend development uses the Spring Boot framework. For ease of understanding, the following scenario is assumed: Project information needs to be recorded during project development. 1. Project information: POJO objects are represented using the Project class; 2. The Service operation class name corresponding to Project is ProjectService; 3. ProjectService contains two methods: updateProject, which is used to modify project information, and discardProject, which is used to discard a project. 4. The POJO object of a logged-in user is represented by the User class.

[0093] public class Project { private Long id; / / Project ID private String name; / / Project name private String status; / / Project status private Long createBy; / / Creator ID } public class User { private Long id; / / User ID private String name; / / Username } The following steps are required: 1. Before actually updating the data in `updateProject`, to ensure security, the following conditions must be met: 1.1 The modified login user must be the creator of the project (pro.createBy==user.id); 1.2 The status of the saved old project must be Running (oldPro.status==”Running”); 1.3 The status of a new project cannot be "Waiting" (newPro.status!=”Waiting”).

[0094] The above judgment can be simplified into one (oldPro.createBy==user.id&&oldPro.status==”Running”&&newPro.status!=”Waiting”).

[0095] 2. Before discarding a project, to ensure safety, the following conditions must be met: 2.1 Deprecated login users must be the creators of the project (pro.createBy==user.id); 2.2 The status of a saved project must be Finished (pro.status==”Finished”).

[0096] The above judgment can be simplified into one (pro.createBy==user.id&&pro.status==”Finished”).

[0097] If the above functionality is implemented in a conventional verification method, it can be represented as follows: @Service public class ProjectService { public boolean updateProject(Project newPro){ Project oldPro = getProjectById(newPro.getId()); User login = getLoginUser(); if (!(oldPro.getCreateBy().equals(login.getId())&&oldPro.getStatus().equals("Running")&&!newPro.getStatus().equals("Waiting"))){ throw new RuntimeException("Unable to update or lack of permission"); } ... } public boolean discardProject(long proId){ Project pro = getProjectById(proId); User login = getLoginUser(); if (!(pro.getCreateBy().equals(login.getId())&&pro.getStatus().equals("Finished "))){ throw new RuntimeException("Cannot deprecate or do not have permission"); } ... } } After using this invention, the updateProject and discardProject methods can be modified to the following format: public class TestProjectService { public boolean updateProject(Project newPro){ Project oldPro = getProjectById(newPro.getId()); User login = getLoginUser(); commonService.joinPoint(oldPro, newPro, login); ... } public boolean discardProject(Long proId){ Project pro = getProjectById(proId); User login = getLoginUser(); commonService.joinPoint(oldPro, null, login); ... } } As can be seen from the above computer-readable instructions, the verification rules for each method are no longer hardcoded into the computer-readable instructions. Instead, the access point method is called uniformly, and the verification rules are deferred to the later stage and written by the front end.

[0098] Furthermore, the annotations and access points are explained as follows: @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface ValidPoint { String message(); / / Description of the access point functionality of the method annotated with this annotation } @Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) public @interface ValidParam { String name(); / / The name of the parameter used when defining custom validation rules String message(); / / Description of the purpose of the annotated parameter boolean required(); / / The access point used; whether the marked parameter must be passed. Cannot be null. } Considering that the access point is only used as the entry point captured by AOP and validation rules should not be hardcoded, and considering that Spring AOP is based on dynamic proxy (JDK Proxy or CGLIB), calling one method from one method in the same class will not trigger AOP aspect logic, a special class is defined. This class is only used to define the access points in different services.

[0099] public class CommonService { @ValidPoint(message = "Validation project rule access point") public void joinPoint(@ValidParam(required = true, name = "oldPro", message = "Project original value") Project oldPro, @ValidParam(required = false, name = "newPro", message = "Project New Value")Project newPro, @ValidParam(required = true, name = "user", message = "Login User")User user) { } } As shown in the computer-readable instructions above, information such as the message of `@ValidPoint` and the complete method signatures of `updateProject` and `discardProject` methods are recorded in the `valid_meta` table to inform the front-end of the purpose of this access point method. Information such as `required`, `name`, `message`, and parameter type of `@ValidParam` are recorded in the `valid_param` table. Available attributes when writing SpEL expressions on the front end include `oldPro`, `newPro`, and `user` (determined by the `name` value). `message` is used to indicate the purpose of this attribute when writing expressions. `newPro` can be omitted when calling the annotated method (omitting a value means passing null). For parameters with `required` set to `true`, a null check will be added by default during actual validation and parsing.

[0100] After the program starts successfully and scans and records the metadata information of the validation rules into the table using methods such as AOP annotations, reflection, and ASM, users can write validation rules for different methods through the front-end page.

[0101] The validation rules for the updateProject method are regular, and the error message errMsg after validation failure is as follows: regular: oldPro.createBy==user.id and oldPro.status=="Running"andnewPro.status!="Waiting" errMsg: "Unable to update or lack of permission" The validation rules for the discardProject method are regular, and the error message errMsg after validation failure is as follows: regular:oldPro.createBy==user.id and oldPro.status==" Finished" errMsg: "Unable to discard or lack of permission" The above can decompose each regular rule into multiple regular rules and provide errMsg information for each regular rule, which will not be described further here.

[0102] When a user calls the project modification interface, the `updateProject` method is executed. Upon reaching `commonService.joinPoint`, it is intercepted by the AOP aspect, and the pointcut method is executed. The pointcut method resolves the calling method to `updateProject` in real-time, retrieves the corresponding validation rule `regular` and its `errMsg` value from the database, and then calls the SpEL parsing engine to parse `regular` into executable, computer-readable Java instructions and perform validation. If validation succeeds, subsequent computer-readable instructions within the `updateProject` method continue execution; if validation fails, the `errMsg` error message is returned. A similar validation process is performed when calling the `discardProject` discard interface.

[0103] If you need to modify the validation rules of the updateProject / discardProject methods in the future (such as no longer validating the status of new values), you can directly modify the rule expression through the front-end page and update the database. The new validation rules will be automatically called for validation the next time the relevant interface is executed.

[0104] In summary, the embodiments of this application can achieve complete decoupling between business rules and computer-readable instruction logic by using custom annotations to mark validation entry points and combining them with the SpEL expression engine to parse externally configured validation rules. The system includes core functions such as dynamic parameter binding, hot rule updates, and metadata persistence, effectively solving the problems of hard coding and poor scalability in traditional validation methods, and significantly improving system maintenance efficiency and rule configuration flexibility.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0106] like Figure 3 As shown, embodiments of this application also provide a data verification device 10, including: a scanning module 100, a first identification module 200, and a first verification module 300.

[0107] Specifically, the scanning module 100 is used to scan the metadata when the target program is loaded and started, in order to identify the target entry point of the metadata.

[0108] The first identification module 200 is used to identify the annotation of the target entry point in the metadata and obtain the target verification rule corresponding to the target entry point.

[0109] The first verification module 300 is used to determine whether the target verification rule meets the preset expression rule conditions. If it meets the preset expression rule conditions, it determines multiple associated verification items of the data to be verified corresponding to the target entry point based on the target verification rule, so as to verify the data to be verified by using the target verification rule and multiple associated verification items.

[0110] Optionally, in one embodiment of this application, the scanning module 100 includes a scanning unit and an identification unit.

[0111] The scanning unit is used to scan at least one aspect of the metadata that meets the preset annotation recognition conditions.

[0112] The identification unit is used to identify the target entry point by using a pre-set annotation identification method in at least one section.

[0113] Optionally, in one embodiment of this application, the scanning module 100 further includes a storage unit.

[0114] The storage unit is used to store at least one of the following in the annotation recognition method: the verification rule identifier, the identifiable parameter location information, and the identifiable parameter data type, into a preset database table, so as to match the corresponding aspect from the preset database table based on the annotation of the target entry point.

[0115] Optionally, in one embodiment of this application, the data verification device 10 further includes: a second identification module, an extraction module, and a first update module.

[0116] The second identification module is used to identify the business class identification method that meets the preset business annotation marking conditions among multiple annotation identification methods.

[0117] The extraction module is used to extract the identification method to be invoked from the business identification method based on the annotation of the target entry point.

[0118] The first update module is used to update at least one of the following to a preset database table: the identification information, signature information, target information in the corresponding target entry point annotation, verification information, and the mapping relationship between the identification method to be called and multiple identifiable parameters.

[0119] Optionally, in one embodiment of this application, the data verification device 10 further includes: a calling module, a comparison module, and a second verification module.

[0120] The calling module is used to call the corresponding historical data in the preset database table based on the annotation of the target entry point and the target validation rules.

[0121] The comparison module is used to compare historical data with the data to be verified corresponding to the target entry point to obtain the comparison results.

[0122] The second verification module is used to verify the data to be verified using the comparison results.

[0123] Optionally, in one embodiment of this application, the data verification device 10 further includes: a first receiving module and a second updating module.

[0124] The first receiving module is used to receive verification rule update instructions.

[0125] The second update module is used to obtain new validation rules based on the validation rule update instruction, and to update the rule parsing engine in the corresponding aspect using the new validation rules.

[0126] Optionally, in one embodiment of this application, the data verification device 10 further includes: a third identification module, a reading module, and a third verification module.

[0127] The third identification module is used to identify the annotation type of the target entry point.

[0128] The read module is used to read the parameter data corresponding to the target point in the metadata when the annotation type is parameter read type.

[0129] The third verification module is used to verify the data to be verified corresponding to the target entry point when the annotation type is a business logic type, using the target verification rules.

[0130] Optionally, in one embodiment of this application, the data verification device 10 further includes a fourth identification module and an alert module.

[0131] The fourth identification module is used to identify the verification result of the data to be verified.

[0132] The reminder module is used to generate an error reminder when the verification result is a verification failure, and to match the corresponding input reminder based on the verification result.

[0133] Optionally, in one embodiment of this application, the data verification device 10 further includes: a push module, a second receiving module, and an acquisition module.

[0134] The push module is used to push data information corresponding to metadata to the front-end page.

[0135] The second receiving module is used to receive the user's verification rule switching command based on the front-end page input.

[0136] The acquisition module is used to obtain the target verification rule based on the verification rule switch command.

[0137] For a description of the features in the embodiment corresponding to the data verification device, please refer to the relevant description of the embodiment corresponding to the data verification method, which will not be repeated here.

[0138] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described data verification method embodiments.

[0139] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described data verification method embodiments when running.

[0140] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0141] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described data verification method embodiments.

[0142] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described data verification method embodiments.

[0143] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0144] The data verification method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A data verification method, characterized in that, Includes the following steps: Scan the metadata of the target program at startup to identify the target entry point of the metadata; Identify the annotation of the target entry point in the metadata and obtain the target validation rule corresponding to the target entry point; Determine whether the target verification rule meets the preset expression rule condition. If it does, then based on the target verification rule, determine multiple associated verification items of the data to be verified corresponding to the target entry point, so as to verify the data to be verified using the target verification rule and the multiple associated verification items.

2. The method according to claim 1, characterized in that, The scanning of metadata during the loading and startup of the target program to identify target entry points for the metadata includes: Scan at least one aspect of the metadata that meets the preset annotation recognition conditions; The target entry point is identified using a pre-defined annotation recognition method in at least one of the cut surfaces.

3. The method according to claim 2, characterized in that, After scanning at least one aspect in the metadata that satisfies the preset annotation recognition conditions, the process further includes: At least one of the verification rule identifier, identifiable parameter location information, and identifiable parameter data type in the annotation recognition method is stored in a preset database table, so as to match the corresponding aspect from the preset database table based on the annotation of the target entry point.

4. The method according to claim 2, characterized in that, After identifying the annotation of the target entry point in the metadata, the method further includes: Identify business class identification methods that meet preset business annotation marking conditions among multiple annotation identification methods; Based on the annotations of the target entry point, extract the identification method to be invoked from the business identification method; Update at least one of the identification information, signature information, target information in the corresponding target entry point annotation, verification information, and mapping relationship between the identification method to be invoked and multiple identifiable parameters to the preset database table.

5. The method according to claim 2, characterized in that, If the target validation rule satisfies the preset expression rule condition, the method further includes: Based on the annotation of the target entry point and the target verification rules, the corresponding historical data is retrieved from the preset database table; By comparing the historical data with the data to be verified corresponding to the target entry point, the comparison results are obtained; The comparison results are used to verify the data to be verified.

6. The method according to claim 2, characterized in that, Also includes: Receive verification rule update instructions; New verification rules are obtained based on the verification rule update instruction, and the rule parsing engine in the corresponding aspect is updated using the new verification rules.

7. The method according to claim 1, characterized in that, After identifying the annotation of the target entry point in the metadata, the method further includes: Identify the annotation type of the target entry point; If the annotation type is a parameter reading type, then read the parameter data corresponding to the target entry point in the metadata; If the annotation type is a business logic type, then the target validation rules are used to validate the data to be validated corresponding to the target entry point.

8. The method according to claim 1, characterized in that, Also includes: Identify the verification result of the data to be verified; If the verification result is a verification failure, an error message is generated, and a corresponding input reminder is matched based on the verification result.

9. The method according to claim 1, characterized in that, Also includes: Push the data information corresponding to the metadata to the front-end page; Receive the user's instruction to switch the verification rules based on the front-end page; The target verification rule is obtained based on the verification rule switch instruction.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the data verification method as described in any one of claims 1 to 9 when executing the computer program.

Images