Data checking method, device and equipment and storage medium

Abstract

The application discloses a data verification method and device, equipment and a storage medium, and relates to the technical field of data processing, and can meet the business verification demand of a government affair service platform. The method comprises the following steps: receiving a data verification request; the data verification request carries a to-be-verified data packet and a verification code of the to-be-verified data packet; a target rule string corresponding to the verification code of the to-be-verified data packet is determined from at least one candidate rule string; at least one verification rule is contained in one candidate rule string; the to-be-verified data packet is processed based on the verification parameter identifier and the algorithm identifier corresponding to each target verification rule in the target rule string, so that a data verification result of the to-be-verified data packet is obtained; the verification parameter identifier corresponding to the target verification rule is used for representing a group of verification data to be verified by the target verification rule; and the algorithm identifier corresponding to the target verification rule is used for representing a verification algorithm when the target verification rule is executed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data verification method, apparatus, device, and storage medium. Background Technology

[0002] Currently, when government service platforms receive data from other platforms, they need to verify the quality of the reported data. Specifically, this involves verifying the accuracy, completeness, consistency, and stability of the reported data. For example, this can include verifying the type and length of the field content, as well as the relationships between different fields.

[0003] Existing rule engines for data validation are mostly heavyweight, complex to integrate, and lack flexibility and scalability. However, government service platforms have high business complexity, with diverse and complex data types to be validated and numerous validation items. Therefore, existing rule engines cannot meet the business validation needs of government service platforms, and there is an urgent need to propose a more flexible data validation solution. Summary of the Invention

[0004] This application provides a data verification method, apparatus, device, and storage medium. This solution is highly flexible and can meet the business verification needs of government service platforms.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, this application provides a data verification method, comprising: receiving a data verification request; the data verification request carrying a data packet to be verified and a verification code of the data packet to be verified; determining a target rule string corresponding to the verification code of the data packet to be verified from at least one candidate rule string; a candidate rule string containing at least one verification rule; processing the data packet to be verified based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string to obtain a data verification result of the data packet to be verified; the verification parameter identifier corresponding to the target verification rule is used to characterize a set of verification data to be verified by the target verification rule; the algorithm identifier corresponding to the target verification rule is used to characterize the verification algorithm when the target verification rule performs verification; the verification data belongs to the data packet to be verified.

[0007] In the technical solution provided in this application, developers can integrate multiple verification rules from various commonly used verification items in the business scenario of the government service platform into a single candidate rule string, based on the platform's business needs. Then, they can create a correspondence between the verification codes of each verification item and the candidate rule strings, and pre-configure verification algorithms for each candidate rule string. In practical applications, upon receiving a data verification request from the government service platform, the target rule string corresponding to the verification code of the data packet to be verified can be determined from at least one pre-defined candidate rule string, based on the data packet to be verified and its verification code carried in the request. Then, the data packet to be verified can be processed based on the verification parameter identifiers and algorithm identifiers corresponding to each target verification rule in the target rule string to obtain the data verification result. It can be seen that the technical solution provided in this application supports developers in deploying verification items according to the business scenario needs of the government service platform, and the verification rules and verification algorithms can be deployed separately, meaning the code for the verification rules and the code for the verification algorithms are independent of each other. This allows developers to rewrite the verification rule code according to the business scenario needs of the government service platform, offering high flexibility and meeting the business verification requirements of the platform.

[0008] Optionally, in one possible design approach, the aforementioned "processing the data packet to be checked based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string to obtain the data verification result of the data packet to be checked" may include:

[0009] Based on the rule category identifiers corresponding to each target verification rule, each custom rule and each MVEL rule within each target verification rule is determined; one target verification rule corresponds to one rule category identifier; based on the verification parameter identifiers and algorithm identifiers corresponding to each custom rule, the data packet to be verified is processed to obtain each first verification sub-result corresponding to each custom rule; furthermore, based on the verification parameter identifiers corresponding to each MVEL rule, the data packet to be verified is processed to obtain each second verification sub-result corresponding to each MVEL rule; one custom rule corresponds to at least one verification parameter identifier and one algorithm identifier; one MVEL rule corresponds to at least one verification parameter identifier; based on each first verification sub-result and each second verification sub-result, the data verification result is determined.

[0010] Optionally, in another possible design approach, the above-mentioned "processing the data packet to be checked based on the verification parameter identifiers corresponding to each custom rule and the algorithm identifiers corresponding to each custom rule to obtain the first verification sub-results corresponding to each custom rule" may include:

[0011] Each custom rule is parsed based on preset parsing rules to obtain the corresponding verification parameter identifiers and algorithm identifiers. Based on the verification parameter identifiers, each set of verification data corresponding to each custom rule is determined from the data packet to be verified, and each verification algorithm corresponding to each custom rule is determined based on the algorithm identifiers. Each verification parameter identifier corresponds to a set of verification data, and each algorithm identifier corresponds to a verification algorithm. According to each custom rule and each verification algorithm corresponding to each custom rule, each set of verification data corresponding to each custom rule is processed to obtain each first verification sub-result.

[0012] Optionally, in another possible design approach, the aforementioned "processing the data packet to be checked based on the check parameter identifiers corresponding to each MVEL rule to obtain the second check sub-results corresponding to each MVEL rule" may include:

[0013] Each MVEL rule is parsed based on the preset parsing rules to obtain the corresponding verification parameter identifiers for each MVEL rule; based on the verification parameter identifiers for each MVEL rule, each set of verification data corresponding to each MVEL rule is determined from the data packet to be checked; one set of verification data corresponds to one verification parameter identifier; based on each MVEL rule, the MVEL expression parser is called to process each set of verification data corresponding to each MVEL rule to obtain each second verification sub-result.

[0014] Optionally, in another possible design approach, the candidate rule string is a string with a preset format, which supports calling the MVEL expression parser; based on the results of each first and second checksum, the data validation results are determined, including:

[0015] In the target rule string, the algorithm identifiers corresponding to each custom rule are replaced with the results of each first checksum, and the algorithm identifiers corresponding to each MVEL rule are replaced with the results of each second checksum, to obtain the replaced target rule string; the MVEL expression parser is called to process the replaced target rule string to obtain the data verification results.

[0016] Optionally, in another possible design, the data verification method provided in this application may also include:

[0017] Receive a rule configuration request; the rule configuration request carries a first rule string configured by the user, and a target algorithm identifier of the target verification algorithm selected by the user from at least one candidate verification algorithm that corresponds to the first rule string; determine a second rule string based on the first rule string and the target algorithm identifier; process the second rule string based on a preset conversion rule to obtain a third rule string in a preset format; the third rule string in the preset format supports calling the MVEL expression parser; add the third rule string to at least one candidate rule string.

[0018] Optionally, in another possible design, the data verification method provided in this application may also include:

[0019] Receive a rule binding request; the rule binding request carries a first candidate rule string selected by the user from at least one candidate rule string and a verification code to be bound; create a mapping relationship between the first candidate rule string and the verification code to be bound.

[0020] Secondly, this application provides a data verification device, including: a receiving module, a determining module, and a processing module;

[0021] The receiving module is used to receive data verification requests; the data verification request carries the data packet to be verified and the verification code of the data packet to be verified.

[0022] The determination module is used to determine the target rule string corresponding to the verification code of the data packet to be inspected from at least one candidate rule string; a candidate rule string contains at least one verification rule;

[0023] The processing module is used to process the data packet to be checked based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string, and obtain the data verification result of the data packet to be checked; the verification parameter identifier corresponding to the target verification rule is used to represent a set of verification data to be verified by the target verification rule; the algorithm identifier corresponding to the target verification rule is used to represent the verification algorithm when the target verification rule performs verification; the verification data belongs to the data packet to be checked.

[0024] Optionally, in one possible design, the processing module is specifically used for:

[0025] Based on the rule category identifiers corresponding to each target verification rule, each custom rule and each MVEL rule within each target verification rule is determined; one target verification rule corresponds to one rule category identifier; based on the verification parameter identifiers and algorithm identifiers corresponding to each custom rule, the data packet to be verified is processed to obtain each first verification sub-result corresponding to each custom rule; furthermore, based on the verification parameter identifiers corresponding to each MVEL rule, the data packet to be verified is processed to obtain each second verification sub-result corresponding to each MVEL rule; one custom rule corresponds to at least one verification parameter identifier and one algorithm identifier; one MVEL rule corresponds to at least one verification parameter identifier; based on each first verification sub-result and each second verification sub-result, the data verification result is determined.

[0026] Alternatively, in another possible design, the processing module is further used for:

[0027] Each custom rule is parsed based on preset parsing rules to obtain the corresponding verification parameter identifiers and algorithm identifiers. Based on the verification parameter identifiers, each set of verification data corresponding to each custom rule is determined from the data packet to be verified, and each verification algorithm corresponding to each custom rule is determined based on the algorithm identifiers. Each verification parameter identifier corresponds to a set of verification data, and each algorithm identifier corresponds to a verification algorithm. According to each custom rule and each verification algorithm corresponding to each custom rule, each set of verification data corresponding to each custom rule is processed to obtain each first verification sub-result.

[0028] Alternatively, in another possible design, the processing module is further used for:

[0029] Each MVEL rule is parsed based on the preset parsing rules to obtain the corresponding verification parameter identifiers for each MVEL rule; based on the verification parameter identifiers for each MVEL rule, each set of verification data corresponding to each MVEL rule is determined from the data packet to be checked; one set of verification data corresponds to one verification parameter identifier; based on each MVEL rule, the MVEL expression parser is called to process each set of verification data corresponding to each MVEL rule to obtain each second verification sub-result.

[0030] Optionally, in another possible design approach, the candidate rule string is a string with a preset format, which supports calling the MVEL expression parser; the processing module is further used for:

[0031] In the target rule string, the algorithm identifiers corresponding to each custom rule are replaced with the results of each first checksum, and the algorithm identifiers corresponding to each MVEL rule are replaced with the results of each second checksum, to obtain the replaced target rule string; the MVEL expression parser is called to process the replaced target rule string to obtain the data verification results.

[0032] Optionally, in another possible design, the receiving module is also used to receive a rule configuration request; the rule configuration request carries a first rule string configured by the user, and a target algorithm identifier of the target verification algorithm corresponding to the first rule string selected by the user from at least one candidate verification algorithm.

[0033] The determination module is also used to determine the second rule string based on the first rule string and the target algorithm identifier;

[0034] The processing module is also used to process the second rule string based on the preset conversion rules to obtain the third rule string in the preset format; the third rule string in the preset format supports calling the MVEL expression parser; and the third rule string is added to at least one candidate rule string.

[0035] Optionally, in another possible design, the data verification device provided in this application may further include: a creation module;

[0036] The receiving module is also used to receive rule binding requests; the rule binding request carries a first candidate rule string selected by the user from at least one candidate rule string and a verification code to be bound;

[0037] Create a module to establish the mapping between the first candidate rule string and the verification code to be bound.

[0038] Thirdly, this application provides a data verification device, including a memory, a processor, a bus, and a communication interface; the memory is used to store computer execution instructions, and the processor is connected to the memory via the bus; when the data verification device is running, the processor executes the computer execution instructions stored in the memory, so that the data verification device performs the data verification method provided in the first aspect above.

[0039] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the data verification method provided in the first aspect.

[0040] Fifthly, this application provides a computer program product including computer instructions that, when executed on a computer, cause the computer to perform the data verification method provided in the first aspect.

[0041] It should be noted that the aforementioned computer instructions may be stored, in whole or in part, on a computer-readable storage medium. This computer-readable storage medium may be packaged together with the processor of the data verification device, or it may be packaged separately from the processor of the data verification device; this application does not impose any limitations on this.

[0042] The descriptions of the second, third, fourth, and fifth aspects in this application can be referenced to the detailed description of the first aspect; and the beneficial effects of the descriptions of the second, third, fourth, and fifth aspects can be referenced to the analysis of the beneficial effects of the first aspect, which will not be repeated here.

[0043] In this application, the names of the aforementioned devices or functional modules are not limited, and in actual implementation, these devices or functional modules may appear under other names. As long as the function of each device or functional module is similar to that of this application, they all fall within the scope of the claims of this application and their equivalents.

[0044] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description

[0045] Figure 1 A flowchart illustrating a data verification method provided in an embodiment of this application;

[0046] Figure 2 A flowchart illustrating another data verification method provided in this application embodiment;

[0047] Figure 3 A flowchart illustrating another data verification method provided in this application embodiment;

[0048] Figure 4 This is a schematic diagram of the structure of a data verification device provided in an embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the structure of a data verification device provided in an embodiment of this application. Detailed Implementation

[0050] The data verification method, apparatus, device, and storage medium provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0051] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0052] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0053] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0054] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0055] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0056] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0057] Existing rule engines for data validation are mostly heavyweight, complex to integrate, and lack flexibility and scalability. However, government service platforms have high business complexity, with diverse and complex data types to be validated and numerous validation items. Therefore, existing rule engines cannot meet the business validation needs of government service platforms, and there is an urgent need to propose a more flexible data validation solution.

[0058] To address the problems existing in the prior art, this application provides a data verification method that allows developers to deploy verification items according to the business scenario requirements of the government service platform. Furthermore, verification rules and verification algorithms can be deployed separately, meaning the code for the verification rules and the code for the verification algorithm are independent of each other. This allows developers to rewrite the verification rule code according to the business scenario requirements of the government service platform, offering high flexibility and meeting the business verification needs of the platform.

[0059] The data verification method provided in this application embodiment can be executed by the data verification device provided in this application embodiment. The device can be implemented by software and / or hardware and integrated into the data verification equipment that executes this method.

[0060] The data verification method provided in this application will be described below with reference to the accompanying drawings.

[0061] Reference Figure 1 The data verification method provided in this application includes S101-S103:

[0062] S101, Receive data verification request.

[0063] The data verification request carries the data packet to be verified and the verification code of the data packet to be verified.

[0064] The data verification method provided in this application can be applied to verifying reported data received by a government service platform. In other words, the data verification request can be initiated by the government service platform to the data verification device. For example, after receiving reported data from another platform, the government service platform can determine the data packet to be verified based on the reported data, determine the verification code of the data packet to be verified based on the business scenario, and then initiate a data verification request carrying the data packet to be verified and its verification code to the data verification device.

[0065] The verification code of the data packet to be verified can be a code that is determined in advance for the verification item through some encoding methods. Different business scenarios correspond to different verification items, and the verification codes of different verification items are different.

[0066] In one possible implementation, the government service platform can access the data verification device through the controller interface. After determining the data verification result, the data verification device can also return the data verification result to the government service platform through the controller.

[0067] S102. Determine the target rule string corresponding to the verification code of the data packet to be inspected from at least one candidate rule string.

[0068] Each candidate rule string contains at least one verification rule. For a verification project, the data packet to be verified may contain multiple fields, each of which may require verification according to a specific rule, and there may even be a need for joint verification of the fields. Therefore, each verification project can have multiple verification rules. It is possible to integrate multiple verification rules from various verification projects into a single candidate rule string based on business scenario requirements, for use by the data verification device.

[0069] Each candidate rule string can be stored in the data verification device or in a dedicated database. For example, after receiving a data verification request, the data verification device can access the database and retrieve each candidate rule string through the Data Access Object (DAO).

[0070] S103. Based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string, process the data packet to be verified to obtain the data verification result of the data packet to be verified.

[0071] Among them, the verification parameter identifier corresponding to the target verification rule is used to represent a set of verification data to be verified by the target verification rule; the algorithm identifier corresponding to the target verification rule is used to represent the verification algorithm when the target verification rule performs verification; the verification data belongs to the data packet to be verified.

[0072] After determining the target rule string, the data verification device can iterate through all target verification rules in the target rule string, and use the verification algorithm corresponding to the current target verification rule to process a set of verification data in the data packet to be verified that corresponds to the current target verification rule, thereby obtaining the verification sub-result of the current target verification rule. After iterating through all target verification rules, the data verification result of the data packet to be verified is determined based on the verification sub-results of all target verification rules.

[0073] In this embodiment, the verification rules may include verification conditions for the verification data, such as reference thresholds. The verification algorithm, on the other hand, is the strategy algorithm used during the verification process, such as regular expression matching. In other words, verification rules and verification algorithms are two different concepts.

[0074] Optionally, processing the data packet to be checked based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string to obtain the data verification result of the data packet to be checked may include: determining each custom rule and each MVFLEX Expression Language (MVEL) rule in each target verification rule based on each rule category identifier corresponding to each target verification rule; processing the data packet to be checked based on each verification parameter identifier and each algorithm identifier corresponding to each custom rule to obtain each first verification sub-result corresponding to each custom rule; and processing the data packet to be checked based on each verification parameter identifier corresponding to each MVEL rule to obtain each second verification sub-result corresponding to each MVEL rule; and determining the data verification result based on each first verification sub-result and each second verification sub-result.

[0075] Each target validation rule corresponds to a rule category identifier. The rule category identifier is a label attached to the target validation rule string when it is created, based on whether the target validation rule belongs to a custom rule or an MVEL rule. A custom rule corresponds to at least one validation parameter identifier and one algorithm identifier; an MVEL rule corresponds to at least one validation parameter identifier.

[0076] For example, the data verification device can decompose the target rule string according to the character concatenation format of each verification rule in the target rule string. For instance, if the verification rules in the target rule string are concatenated using preset interval symbols, the target rule string can be decomposed into individual target verification rules based on the preset interval symbols.

[0077] The verification rules in this embodiment may include MVEL rules, which can be directly parsed by the MVEL expression parser to obtain the corresponding second verification sub-result. However, the MVEL expression parser only supports running simple rules, such as regular expression matching, true && false, etc. To adapt to the business scenario requirements of the government service platform, the verification rules in this embodiment may also include some custom complex rules (such as the verification rules for the unified social credit code). These custom rules can be executed by the corresponding configured verification algorithm to obtain the corresponding first verification sub-result.

[0078] Optionally, based on the verification parameter identifiers and algorithm identifiers corresponding to each custom rule, the data packet to be inspected is processed to obtain the first verification sub-results corresponding to each custom rule. This may include: parsing each custom rule based on preset parsing rules to obtain the verification parameter identifiers and algorithm identifiers corresponding to each custom rule; determining each set of verification data corresponding to each custom rule from the data packet to be inspected based on the verification parameter identifiers corresponding to each custom rule, and determining each verification algorithm corresponding to each custom rule based on the algorithm identifiers corresponding to each custom rule; and processing each set of verification data corresponding to each custom rule according to each custom rule and the verification algorithm corresponding to each custom rule to obtain the first verification sub-results.

[0079] Among them, one type of verification parameter identifier corresponds to a set of verification data, one type of algorithm identifier corresponds to a verification algorithm, and the preset parsing rule can be a parsing rule determined in advance according to the rule format of the verification rule.

[0080] This application uses the strategy pattern to add corresponding verification algorithms to custom rules. This can make up for the defect that the MVEL expression parser cannot parse complex rules, ensure the scalability of verification rules, and is suitable for the business verification needs of government service platforms.

[0081] Optionally, based on the verification parameter identifiers corresponding to each MVEL rule, the data packet to be checked is processed to obtain the second verification sub-results corresponding to each MVEL rule. This may include: parsing each MVEL rule based on preset parsing rules to obtain the verification parameter identifiers corresponding to each MVEL rule; determining each set of verification data corresponding to each MVEL rule from the data packet to be checked based on the verification parameter identifiers corresponding to each MVEL rule; and calling the MVEL expression parser to process each set of verification data corresponding to each MVEL rule based on each MVEL rule to obtain the second verification sub-results.

[0082] One type of verification parameter identifier corresponds to a set of verification data.

[0083] In this embodiment, to improve the verification speed while meeting business verification requirements, the strategy pattern is not used for MVEL rules that can be directly executed by the MVEL expression parser. That is, no dedicated verification algorithm is configured; the second verification sub-result is obtained by directly calling the MVEL expression parser. By classifying and processing the two types of verification rules using different methods, the verification speed can be improved.

[0084] Optionally, the candidate rule string is a string in a preset format, which supports calling the MVEL expression parser. Based on the results of each first checksum and each second checksum, the data verification result is determined, which may include: replacing each algorithm identifier corresponding to each custom rule with each first checksum result in the target rule string, and replacing each algorithm identifier corresponding to each MVEL rule with each second checksum result to obtain the replaced target rule string; calling the MVEL expression parser to process the replaced target rule string to obtain the data verification result.

[0085] For example, after processing a set of verification data according to the target verification rules, the data verification device can obtain a Boolean string, which can then replace the first or second verification sub-result. Similarly, after processing all the target verification rules, the target rule string becomes a simple rule that can be executed by the MVEL expression parser. At this point, the MVEL expression parser can be called to process this simple rule to obtain the final data verification result.

[0086] In this embodiment, although the candidate rule string may contain custom rules, the final verification of each validation sub-result is still based on simple rules for a single candidate rule string. Therefore, developers must construct the candidate rule string according to a pre-defined preset format so that the MVEL expression parser can be directly called to obtain the data validation results.

[0087] Optionally, the data verification method improved in this application embodiment may further include: receiving a rule configuration request; determining a second rule string based on a first rule string and a target algorithm identifier; processing the second rule string based on a preset conversion rule to obtain a third rule string in a preset format; and adding the third rule string to at least one candidate rule string.

[0088] The third rule string in the preset format supports calling the MVEL expression parser; the rule configuration request carries the first rule string configured by the user, and the target algorithm identifier of the target verification algorithm corresponding to the first rule string, which is selected by the user from at least one candidate verification algorithm.

[0089] Preset conversion rules can be predetermined conversion rules. In one possible implementation, the rule configuration request can be a request triggered by a series of operations performed by the developer through the application configuration interface provided on user terminals such as mobile phones and computers.

[0090] The technical solution provided in this application does not use any dependencies other than Java (a computer language) and MVEL, and is lightweight and easy to integrate. It can support developers to quickly add candidate rule strings according to changes in the business needs of the government platform.

[0091] For example, to add a mobile phone number verification, the following steps can be taken. First, a `PhoneRule` class can be created that inherits from the abstract class `RuleBaseStrategy` and implements the `exec` method, which selects the corresponding target verification algorithm for the mobile phone number verification. Then, the verification rules for the mobile phone number can be written in the `exec` method, returning a Boolean result, which adds the first rule string for the mobile phone number verification. Next, a new verification can be added to the static block `STRATEGY_MAP` in the `RuleContext` class, which binds the target algorithm identifier and the first rule string. Specifically, after binding the target algorithm identifier and the first rule string, developers can trigger a rule configuration request on the user terminal. After receiving the rule configuration request, the data verification device can combine the first rule string and the target algorithm identifier to obtain a second rule string. Then, based on preset conversion rules, the syntax and semantics of the second rule string can be processed to convert it into a third rule string in a unified format, which is then added to at least one existing candidate rule string.

[0092] For example, the user terminal can load a pre-defined rule editor. When a developer finishes writing a validation rule, the user terminal can display multiple validation algorithms for the developer to choose from, and can add an algorithm identifier to the validation rule based on the developer's selection. In one possible implementation, the user terminal can use "&&" or "||" to concatenate multiple validation rules written by the user, ultimately forming a complete second rule string which is sent to the data validation device. The data validation device then processes the string to obtain a third rule string and saves it. Alternatively, in another possible implementation, the data validation device can also use "&&" or "||" to concatenate multiple validation rules written by the user transmitted by the user terminal.

[0093] Optionally, the data verification method provided in this application embodiment further includes: receiving a rule binding request; and creating a mapping relationship between a first candidate rule string and a verification code to be bound. The rule binding request carries a first candidate rule string selected by the user from at least one candidate rule string and a verification code to be bound.

[0094] In this embodiment, developers can add a first candidate rule string to the verification code to be bound to the verification project from a pre-configured pool of candidate rule strings according to business scenario requirements, which can further improve the flexibility of configuration.

[0095] In summary, the data verification method provided in this application allows developers to integrate multiple verification rules from commonly used verification items into a single candidate rule string based on the business scenario requirements of the government service platform. Then, a correspondence is created between the verification codes of each verification item and each candidate rule string, and a verification algorithm is pre-configured for each candidate rule string. In practical applications, upon receiving a data verification request from the government service platform, the target rule string corresponding to the verification code of the data packet to be verified is determined from at least one pre-defined candidate rule string based on the data packet to be verified and its verification code carried in the data verification request. Then, the data packet to be verified is processed based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string to obtain the data verification result. It can be seen that this application embodiment supports developers in deploying verification items according to the business scenario requirements of the government service platform, and the verification rules and verification algorithms can be deployed separately, meaning the code for the verification rules and the code for the verification algorithms are independent of each other. This allows developers to rewrite the code for the verification rules according to the business scenario requirements of the government service platform, providing high flexibility and meeting the business verification needs of the government service platform.

[0096] Optional, such as Figure 2 As shown, this application embodiment also provides a data verification method, which may include S201-S206:

[0097] S201, Receive data verification request.

[0098] S202. From at least one candidate rule string, determine the target rule string corresponding to the verification code of the data packet to be inspected.

[0099] S203. Based on the rule category identifiers corresponding to each target verification rule, determine each custom rule and each MVEL rule in each target verification rule.

[0100] S204. Based on the verification parameter identifiers and algorithm identifiers corresponding to each custom rule, the data packet to be checked is processed to obtain the first verification sub-results corresponding to each custom rule; and based on the verification parameter identifiers corresponding to each MVEL rule, the data packet to be checked is processed to obtain the second verification sub-results corresponding to each MVEL rule.

[0101] S205. In the target rule string, replace the algorithm identifiers corresponding to each custom rule with the results of each first checksum, and replace the algorithm identifiers corresponding to each MVEL rule with the results of each second checksum, to obtain the target rule string after replacement.

[0102] S206. Call the MVEL expression parser to process the replaced target rule string and obtain the data verification result.

[0103] Optional, such as Figure 3 As shown, this application embodiment also provides a data verification method, which may include S301-S309:

[0104] S301. Receive a rule configuration request carrying a first rule string and a target algorithm identifier.

[0105] S302. Determine the second rule string based on the first rule string and the target algorithm identifier.

[0106] S303. Process the second rule string based on the preset conversion rules to obtain the target rule string in the preset format.

[0107] S304. Add the target rule string to at least one candidate rule string.

[0108] S305. Receive a rule binding request carrying the target rule string and the target verification code.

[0109] S306. Create a mapping relationship between the target rule string and the target verification code.

[0110] S307. Receive a data verification request carrying a data packet to be verified and the target verification code of the data packet to be verified.

[0111] S308. Determine the target rule string corresponding to the target verification code from at least one candidate rule string.

[0112] S309. Based on the verification parameter identifier and algorithm identifier corresponding to each verification rule in the target rule string, process the data packet to be verified to obtain the data verification result of the data packet to be verified.

[0113] like Figure 4 As shown in the figure, this application embodiment also provides a data verification device, which may include: a receiving module 11, a determining module 21 and a processing module 31.

[0114] In this embodiment, the receiving module 11 executes S101, the determining module 21 executes S102, and the processing module 31 executes S103.

[0115] Specifically, the receiving module 11 is used to receive a data verification request; the data verification request carries a data packet to be verified and a verification code of the data packet to be verified.

[0116] The determining module 21 is used to determine the target rule string corresponding to the verification code of the data packet to be inspected from at least one candidate rule string; a candidate rule string contains at least one verification rule;

[0117] The processing module 31 is used to process the data packet to be checked based on the verification parameter identifier and algorithm identifier corresponding to each target verification rule in the target rule string, and obtain the data verification result of the data packet to be checked; the verification parameter identifier corresponding to the target verification rule is used to characterize a set of verification data to be verified by the target verification rule; the algorithm identifier corresponding to the target verification rule is used to characterize the verification algorithm when the target verification rule performs verification; the verification data belongs to the data packet to be checked.

[0118] Optionally, in one possible design, processing module 31 is specifically used for:

[0119] Based on the rule category identifiers corresponding to each target verification rule, each custom rule and each MVEL rule within each target verification rule is determined; one target verification rule corresponds to one rule category identifier; based on the verification parameter identifiers and algorithm identifiers corresponding to each custom rule, the data packet to be verified is processed to obtain each first verification sub-result corresponding to each custom rule; furthermore, based on the verification parameter identifiers corresponding to each MVEL rule, the data packet to be verified is processed to obtain each second verification sub-result corresponding to each MVEL rule; one custom rule corresponds to at least one verification parameter identifier and one algorithm identifier; one MVEL rule corresponds to at least one verification parameter identifier; based on each first verification sub-result and each second verification sub-result, the data verification result is determined.

[0120] Optionally, in another possible design, the processing module 31 is further used for:

[0121] Each custom rule is parsed based on preset parsing rules to obtain the corresponding verification parameter identifiers and algorithm identifiers. Based on the verification parameter identifiers, each set of verification data corresponding to each custom rule is determined from the data packet to be verified, and each verification algorithm corresponding to each custom rule is determined based on the algorithm identifiers. Each verification parameter identifier corresponds to a set of verification data, and each algorithm identifier corresponds to a verification algorithm. According to each custom rule and each verification algorithm corresponding to each custom rule, each set of verification data corresponding to each custom rule is processed to obtain each first verification sub-result.

[0122] Optionally, in another possible design, the processing module 31 is further used for:

[0123] Each MVEL rule is parsed based on the preset parsing rules to obtain the corresponding verification parameter identifiers for each MVEL rule; based on the verification parameter identifiers for each MVEL rule, each set of verification data corresponding to each MVEL rule is determined from the data packet to be checked; one set of verification data corresponds to one verification parameter identifier; based on each MVEL rule, the MVEL expression parser is called to process each set of verification data corresponding to each MVEL rule to obtain each second verification sub-result.

[0124] Optionally, in another possible design approach, the candidate rule string is a string with a preset format, which supports calling the MVEL expression parser; the processing module 31 is further used for:

[0125] In the target rule string, the algorithm identifiers corresponding to each custom rule are replaced with the results of each first checksum, and the algorithm identifiers corresponding to each MVEL rule are replaced with the results of each second checksum, to obtain the replaced target rule string; the MVEL expression parser is called to process the replaced target rule string to obtain the data verification results.

[0126] Optionally, in another possible design, the receiving module 11 is also used to receive a rule configuration request; the rule configuration request carries a first rule string configured by the user, and a target algorithm identifier of the target verification algorithm corresponding to the first rule string selected by the user from at least one candidate verification algorithm.

[0127] The determining module 21 is also used to determine the second rule string based on the first rule string and the target algorithm identifier;

[0128] The processing module 31 is also used to process the second rule string based on the preset conversion rules to obtain a third rule string in the preset format; the third rule string in the preset format supports calling the MVEL expression parser; and the third rule string is added to at least one candidate rule string.

[0129] Optionally, in another possible design, the data verification device provided in this application may further include: a creation module;

[0130] The receiving module 11 is also used to receive a rule binding request; the rule binding request carries a first candidate rule string selected by the user from at least one candidate rule string and a verification code to be bound;

[0131] Create a module to establish the mapping between the first candidate rule string and the verification code to be bound.

[0132] Optionally, the data verification device may also include a storage module for storing the program code of the data verification device, etc.

[0133] like Figure 5 As shown, this application embodiment also provides a data verification device, including a memory 41 and a processor (e.g., ...). Figure 5 The processor includes 42-1 and 42-2, bus 43 and communication interface 44; memory 41 is used to store computer execution instructions, and the processor and memory 41 are connected through bus 43; when the data verification device is running, the processor executes the computer execution instructions stored in memory 41 so that the data verification device performs the data verification method provided in the above embodiments.

[0134] In a specific implementation, as one example, the processor may include one or more central processing units (CPUs), for example... Figure 5 CPU0 and CPU1 are shown in the diagram. As one embodiment, the data verification device may include multiple processors, such as... Figure 5 The processors 42-1 and 42-2 are shown in the diagram. Each of these processors (CPUs) can be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0135] The memory 41 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 41 may exist independently and be connected to the processor via bus 43. The memory 41 may also be integrated with the processor.

[0136] In a specific implementation, memory 41 is used to store the data in this application and the computer execution instructions corresponding to the software program of this application. The processor can run or execute the software program stored in memory 41, and call the data stored in memory 41, as well as various functions of the data verification device.

[0137] Communication interface 44 uses any transceiver-like device for communicating with other devices or communication networks, such as control systems, radio access networks (RAN), wireless local area networks (WLANs), etc. Communication interface 44 may include a receiving unit to implement receiving functions and a transmitting unit to implement transmitting functions.

[0138] Bus 43 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This bus 43 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0139] As an example, combined Figure 4 The receiving module in the data verification device performs the same functions as... Figure 5 The receiving unit in the data verification device performs the same function as the receiving unit in the data verification device. Figure 5 The processor in the data verification device performs the same function. When the data verification device includes a storage module, the storage module performs the same function as... Figure 5 The memory in them performs the same function.

[0140] The explanation of the relevant content in this embodiment can be found in the above method embodiment, and will not be repeated here.

[0141] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0142] This application also provides a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the data verification method provided in the above embodiments.

[0143] The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, RAM, ROM, an erasable programmable read-only memory (EPROM), a register, a hard disk, an optical fiber, a CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination thereof, or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an application-specific integrated circuit (ASIC). In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0144] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data checking method, characterized by, The method comprises the following steps: receiving a data verification request; the data verification request carries a to-be-verified data packet and a verification code of the to-be-verified data packet; determining a target rule string corresponding to the verification code of the to-be-verified data packet from at least one candidate rule string; one candidate rule string comprises at least one verification rule; processing the to-be-verified data packet based on a verification parameter identifier and an algorithm identifier corresponding to each target verification rule in the target rule string, to obtain a data verification result of the to-be-verified data packet; the verification parameter identifier corresponding to a target verification rule is used to represent a group of verification data to be verified by the target verification rule; the algorithm identifier corresponding to a target verification rule is used to represent a verification algorithm used by the target verification rule when performing verification; the verification data belongs to the to-be-verified data packet; the processing of the to-be-verified data packet based on the verification parameter identifier and the algorithm identifier corresponding to each target verification rule in the target rule string to obtain the data verification result of the to-be-verified data packet comprises the following steps: determining each self-defined rule and each MVEL rule in the target verification rule based on each rule category identifier corresponding to the target verification rule; one target verification rule corresponds to one rule category identifier; processing the to-be-verified data packet based on each verification parameter identifier corresponding to each self-defined rule and each algorithm identifier corresponding to each self-defined rule to obtain each first verification sub-result corresponding to each self-defined rule; and processing the to-be-verified data packet based on each verification parameter identifier corresponding to each MVEL rule to obtain each second verification sub-result corresponding to each MVEL rule; one self-defined rule corresponds to at least one verification parameter identifier and at least one algorithm identifier; one MVEL rule corresponds to at least one verification parameter identifier; determining the data verification result based on the first verification sub-result and the second verification sub-result.

2. The data check method of claim 1, wherein, the processing of the to-be-verified data packet based on each verification parameter identifier corresponding to each self-defined rule and each algorithm identifier corresponding to each self-defined rule to obtain each first verification sub-result corresponding to each self-defined rule comprises the following steps: analyzing each self-defined rule based on a preset analysis rule to obtain each verification parameter identifier corresponding to each self-defined rule and each algorithm identifier corresponding to each self-defined rule; determining each group of verification data corresponding to each self-defined rule from the to-be-verified data packet based on each verification parameter identifier corresponding to each self-defined rule, and determining each verification algorithm corresponding to each self-defined rule based on each algorithm identifier corresponding to each self-defined rule; one verification parameter identifier corresponds to one group of verification data, and one algorithm identifier corresponds to one verification algorithm; processing each group of verification data corresponding to each self-defined rule based on each self-defined rule and each verification algorithm corresponding to each self-defined rule to obtain each first verification sub-result.

3. The data check method of claim 1, wherein, The method further comprises: receiving a rule configuration request; the rule configuration request carries a first rule string configured by a user and a target algorithm identifier of a target verification algorithm corresponding to the first rule string selected by the user from at least one candidate verification algorithm; determining a second rule string based on the first rule string and the target algorithm identifier; processing the second rule string based on a preset conversion rule to obtain a third rule string in a preset format; the third rule string in the preset format supports calling an MVEL expression parser; 4. The data checking method according to any one of claims 2-3, characterized in that, adding the third rule string to the at least one candidate rule string. The method further comprises: receiving a rule binding request; the rule binding request carries a first candidate rule string selected by a user from the at least one candidate rule string and a verification code to be bound; creating a mapping relationship between the first candidate rule string and the verification code to be bound.

5. The data check method of claim 1, wherein, The method further comprises: a receiving module configured to receive a data verification request; the data verification request carries a to-be-verified data packet and a verification code of the to-be-verified data packet; a determining module configured to determine, from at least one candidate rule string, a target rule string corresponding to the verification code of the to-be-verified data packet; one candidate rule string includes at least one verification rule; 6. The data check method of claim 1, wherein, a processing module configured to process the to-be-verified data packet based on verification parameter identifiers and algorithm identifiers corresponding to each target verification rule in the target rule string, to obtain a data verification result of the to-be-verified data packet; a verification parameter identifier corresponding to a target verification rule is used to represent a group of verification data to be verified by the target verification rule; ​ 7. A data checking apparatus, characterized by comprising: ​ ​ ​ ​ ​ ​ ​ An algorithm identifier corresponding to the target verification rule, used to represent a verification algorithm used when the target verification rule performs verification; and the verification data belongs to the data packet to be verified. The processing module is specifically configured to: Based on the rule category identifiers corresponding to the target verification rules, the self-defined rules and the MVEL rules in the target verification rules are determined; one target verification rule corresponds to one rule category identifier; based on the verification parameter identifiers corresponding to the self-defined rules and the algorithm identifiers corresponding to the self-defined rules, the data packet to be verified is processed to obtain first verification sub-results corresponding to the self-defined rules; and based on the verification parameter identifiers corresponding to the MVEL rules, the data packet to be verified is processed to obtain second verification sub-results corresponding to the MVEL rules; one self-defined rule corresponds to at least one verification parameter identifier and one algorithm identifier; one MVEL rule corresponds to at least one verification parameter identifier; and based on the first verification sub-results and the second verification sub-results, a data verification result is determined.

8. A data checking device, characterized by The data verification device comprises a memory, a processor, a bus and a communication interface; the memory is used to store computer execution instructions; the processor is connected with the memory through the bus; When the data verification device is running, the processor executes the computer execution instructions stored in the memory, so that the data verification device performs the data verification method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, and when the computer executes the instructions, the computer performs the data verification method according to any one of claims 1-6.

Images