A data checking method and a computing device

Abstract

The embodiment of the application provides a data verification method and a computing device, relates to the technical field of computing devices, and solves the problem that the consistency of business data verification in the front end and the back end cannot be guaranteed. The method comprises the following steps: in response to a received data verification request, obtaining a business type of metadata of a business object related to the data verification request; obtaining a target data verification rule matched with the business type of the metadata from a pre-constructed data verification rule library; the data verification rule library comprises a plurality of data verification rules and an applicable business type of each data verification rule; each data verification rule comprises at least one atomic rule; the atomic rule is used for indicating independently encapsulated data verification logic; the applicable business type of the target data verification rule satisfies a business type matching condition with the business type of the metadata; and according to the target data verification rule, front-end business data and back-end business data requested to be verified by the data verification request are verified.

Description

Technical Field

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

[0002] Currently, core business systems widely cover business scenarios in multiple fields such as finance and e-commerce, including order management, customer information maintenance, and product data entry. During business operations, data verification of business objects is a core element in ensuring business continuity and data quality. For example, order amounts on e-commerce platforms must meet positive constraints and match the unit price and quantity of the goods. Similarly, customer identification numbers in financial scenarios must conform to corresponding coding rules; these attribute rules directly affect transaction compliance and data availability.

[0003] To ensure data quality, a separate front-end and back-end verification model is typically used to validate business data. Specifically, the client (front-end) can validate its own business data using built-in data validation logic and send the validated data to the server after successful validation. The server (back-end), upon receiving the business data from the client, can then perform further data validation, such as integrity and validity checks, based on its built-in data validation logic.

[0004] However, deploying separate data validation logic on the front end and back end not only results in high maintenance costs, but may also lead to inconsistencies in the data validation results between the front end and back end, thus failing to effectively guarantee the consistency of business data validation during the flow process. Summary of the Invention

[0005] This application provides a data verification method and computing device, which solves the problem of not being able to guarantee the consistency of business data verification between the front end and the back end.

[0006] In a first aspect, embodiments of this application provide a data verification method, which includes: responding to a received data verification request, obtaining the business type of the metadata of the business object involved in the data verification request; obtaining a target data verification rule matching the business type of the metadata from a pre-built data verification rule library; the data verification rule library includes multiple data verification rules and the applicable business type of each data verification rule; the multiple data verification rules include a target data verification rule; each data verification rule includes at least one atomic rule; the atomic rule is used to represent independently encapsulated data verification logic; the applicable business type of the target data verification rule and the business type of the metadata satisfy the business type matching condition; and verifying the front-end business data and back-end business data requested for verification by the data verification request according to the target data verification rule; the front-end business data and back-end business data have the same business meaning but are located on different ends.

[0007] As can be seen from the above, after receiving a data verification request, the embodiments of this application can generate target data verification rules according to the data verification rule library, and use the same set of target data verification rules to verify front-end business data and back-end business data with the same business meaning but located on different ends. This allows the client and server to perform data verification on business data based on the same data verification rules, avoiding the problem of inconsistent verification of business data during the flow process caused by deploying separate data verification logic on the front-end and back-end respectively.

[0008] Secondly, by obtaining the business type of the metadata of the business objects involved in the data verification request, and matching the applicable business type with the business type of the metadata from a pre-built data verification rule library, target data verification rules that meet the business type matching conditions are obtained, thus enabling precise association between data verification rules and business types. Since the business type of the metadata can characterize the business semantics and attribute features of the business object, the target data verification rules obtained based on business type matching can adapt to the actual verification needs of the business object, thereby improving the accuracy of rule configuration.

[0009] Furthermore, since each data validation rule includes at least one atomic rule, and each atomic rule is an independently encapsulated data validation logic unit, the data validation rules are reusable and composable. When validating similar attributes of different business objects, existing atomic rules can be directly reused, thereby reducing the cost of redundant development and maintenance of validation rules.

[0010] In some embodiments, the business matching conditions include: the business scenario similarity between the applicable business type of the data verification rule and the business scenario of the metadata is greater than a preset scenario similarity, and / or, the semantic similarity between the semantic features of the applicable business type of the data verification rule and the semantic features of the business type of the metadata is greater than a preset semantic similarity.

[0011] In this embodiment, by introducing business scenario similarity and semantic feature similarity as matching conditions, it is possible to match appropriate data verification rules even when there are differences in the description of business types but similar actual meanings. This improves the flexibility and accuracy of rule matching and avoids the problem of rule omissions caused by inconsistent business type naming or different description methods.

[0012] In some embodiments, obtaining target data verification rules that match the business type of metadata from a pre-built data verification rule library includes: determining the data verification rules in the data verification rule library that meet the business matching conditions of the business type of metadata as candidate data verification rules; and determining the data verification rules that meet the popularity conditions among the candidate data verification rules as target data verification rules.

[0013] In this embodiment, by first determining candidate data verification rules and then selecting rules that meet the popularity criteria as target data verification rules, high-quality rules that are widely used and popular in business practice can be selected from multiple potentially applicable rules. This makes the final determined rules closer to actual business needs and improves the accuracy and practicality of rule matching.

[0014] In some embodiments, the popularity condition includes at least one of the following: the rule usage frequency is greater than the preset frequency, the rule usage growth rate is greater than the preset growth rate, and the rule reuse rate under different business objects is greater than the preset reuse rate.

[0015] In this embodiment, the popularity of rules is measured by using multi-dimensional indicators such as rule usage frequency, rule usage growth rate, and rule reuse rate under different business objects. This can comprehensively reflect the activity level, popularity, and general value of rules, so that the selected target rules are not only frequently used at present, but also have growth potential and wide applicability, further improving the rationality of rule selection.

[0016] In some embodiments, the candidate data verification rules include a first set of sub-rules and a second set of sub-rules; the candidate data verification rules in the first set of sub-rules are combined rules composed of multiple atomic rules; the candidate data verification rules in the second set of sub-rules are single atomic rules.

[0017] In this embodiment, by dividing the candidate data verification rules into two categories, namely combined rules consisting of multiple atomic rules and single atomic rules, it is convenient to set different filtering strategies or display methods according to the rule type. This allows users to quickly locate the required type of rule, either by directly selecting existing combined rules or by creating their own atomic rules, thereby improving the flexibility of rule configuration and user experience.

[0018] In some embodiments, when there are multiple candidate data verification rules, the method further includes: obtaining popularity information and / or user preference information for each candidate data verification rule; sorting and displaying the multiple candidate data verification rules according to the popularity information and / or user preference information for each candidate data verification rule; and, in response to a selection operation in the sorted and displayed multiple candidate data verification rules, determining the candidate data verification rule selected by the selection operation as the target data verification rule.

[0019] In this embodiment, multiple candidate rules are sorted and displayed by acquiring popularity information and / or user preference information of candidate data verification rules, and the rule pointed to by the user's selection operation is determined as the target data verification rule. This can prioritize the presentation of rules that best meet business needs and user preferences, reduce the workload of users searching and filtering among many rules, and improve the efficiency and personalization of rule configuration.

[0020] In some embodiments, when there are multiple target data verification rules, the front-end business data and back-end business data requested for verification by the data verification request are verified according to the target data verification rules, including: arranging the data verification order of multiple target data verification rules according to the data verification logic of each target data verification rule in the multiple target data verification rules; and verifying the front-end business data and back-end business data according to the arranged multiple target data verification rules.

[0021] In this embodiment, by sequentially arranging multiple target data verification rules, logical conflicts or duplicate verifications can be avoided, thereby improving the correctness and efficiency of multiple rules working together and enhancing the logic and execution efficiency of the verification process.

[0022] In some embodiments, the front-end business data and back-end business data are validated according to a plurality of orchestrated target data validation rules, including: performing logical mutual exclusion verification on the plurality of orchestrated target data validation rules according to a preset logical mutual exclusion condition; and validating the front-end business data and back-end business data according to the plurality of orchestrated target data validation rules if the logical mutual exclusion verification of the plurality of orchestrated target data validation rules passes.

[0023] In this embodiment, by performing logical mutual exclusion verification on multiple target data verification rules after arrangement before execution of verification, logical contradictions between rules can be detected and eliminated in a timely manner, preventing errors in verification results or business anomalies due to rule conflicts, thereby improving the reliability and accuracy of the verification process.

[0024] In some embodiments, the front-end business data and back-end business data requested for verification by the data verification request are verified according to the target data verification rules, including: generating a data verification file in a target format according to the target data verification rules; adding the data verification file to the data verification request; and sending data verification requests carrying the data verification file to the client storing the front-end business data and the server storing the back-end business data, respectively, to request the client to call a data verifier adapted to the target format to verify the front-end business data, and to request the server to call a data verifier adapted to the target format to verify the back-end business data.

[0025] In this embodiment, by generating a data verification file in the target format according to the target data verification rules and sending it to the client and server respectively, the front end and the back end can perform verification based on the same file to ensure the consistency of the verification logic. At the same time, by adapting to data verifiers on different ends, cross-device execution of rules is realized, simplifying the complexity of rule deployment and synchronization.

[0026] In a second aspect, embodiments of this application provide a computing device including a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the methods provided in the first aspect and its possible embodiments described above.

[0027] Thirdly, embodiments of this application provide a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in a computing device, they cause the computing device to implement the methods provided in the first aspect and its possible embodiments.

[0028] Fourthly, embodiments of this application provide a computer program product that, when run on a computing device, causes the computing device to execute the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0029] The beneficial effects of the second to fourth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0030] Figure 1 This application provides a schematic diagram of the system architecture of a data verification system. Figure 2 A schematic diagram of the logical hierarchy architecture of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating a data verification method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a data verification rule base provided in an embodiment of this application; Figure 5 A flowchart illustrating another data verification method provided in this application embodiment; Figure 6 A flowchart illustrating another data verification method provided in this application embodiment; Figure 7 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0032] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0033] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0034] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. 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 terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0035] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" 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 "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0036] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0037] As described in the background section, data validation is a fundamental step in ensuring business compliance and data quality in business systems such as finance, e-commerce, and enterprise services. To guarantee data quality, business systems typically need to validate business data. However, in actual system architectures, data undergoes a complete flow from front-end collection to back-end processing. The front-end, as the entry point for user interaction, plays a role in providing real-time feedback and improving user experience; the back-end, as the core of business logic, is responsible for the final processing and persistent storage of data. Because the front-end validation logic is completely exposed on the client side, there is a risk of it being bypassed or tampered with. Therefore, the back-end cannot directly trust that the front-end has performed validation and must re-validate the received data for legality.

[0038] This creates a need for dual validation on both the front-end and back-end: on the one hand, the front-end needs to provide real-time validation as user input occurs, helping users quickly identify and correct errors and reducing invalid request submissions. On the other hand, the back-end needs to perform final validation before data is entered into the database, intercepting any potentially abnormal data. This dual validation between the front-end and back-end improves user experience while ensuring the integrity and compliance of business data.

[0039] Taking the product listing process on an e-commerce platform as an example, merchants fill in product information on the client side (such as a browser or mobile application). This product information includes multiple business attributes, such as product name, price, inventory quantity, and specifications such as color.

[0040] When merchants enter product names, the client can validate the input in real time, such as checking if the product name is empty or exceeds the length limit. When merchants enter prices, the client can validate whether the input value is a valid numeric format and whether it is greater than zero. When merchants select product colors, the client can validate whether the selected color is within the preset color options range. These front-end validation logics are embedded in the client's page code, aiming to provide merchants with immediate input feedback and reduce the submission of erroneous data.

[0041] After the merchant completes all the information, they click the submit button. The client then performs another round of overall validation on all the entered product information. Once the validation passes, the product information data is packaged into a business request and sent to the server.

[0042] After receiving the business request, the server parses out the product information data. Since the server cannot trust that the client has already performed validation, it needs to re-validate the received product information data for integrity and validity based on another set of internal validation logic. For example, the server checks again whether the product name is empty, whether the price is a valid numeric format and greater than zero, and whether the color is within the allowed range. Only if the server's validation also passes will the product information be written to the database or enter the subsequent business processing flow. If the server's validation fails, it returns a validation failure error message to the client.

[0043] However, deploying separate data validation logic on the front end and back end not only results in high maintenance costs, but may also lead to inconsistencies in the data validation results between the front end and back end, thus failing to effectively guarantee the consistency of business data validation during the flow process.

[0044] Based on this, embodiments of this application provide a data verification method that, in response to a received data verification request, obtains the business type of the metadata of the business object involved in the data verification request, and obtains a target data verification rule that matches the business type of the metadata from a pre-built data verification rule library.

[0045] The data validation rule base includes multiple data validation rules and the applicable business types for each rule. Each data validation rule includes a target data validation rule, and each data validation rule includes at least one atomic rule. This atomic rule represents independently encapsulated data validation logic. The applicable business type of the target data validation rule matches the business type of the metadata, satisfying the business type matching condition.

[0046] Subsequently, based on the target data verification rules, the front-end business data and back-end business data requested for verification in the data verification request (the front-end business data and back-end business data have the same business meaning but are located on different ends) can be verified.

[0047] As can be seen from the above, after receiving a data verification request, the embodiments of this application can generate target data verification rules according to the data verification rule library, and use the same set of target data verification rules to verify front-end business data and back-end business data with the same business meaning but located on different ends. This allows the client and server to perform data verification on business data based on the same data verification rules, avoiding the problem of inconsistent verification of business data during the flow process caused by deploying separate data verification logic on the front-end and back-end respectively.

[0048] Secondly, by obtaining the business type of the metadata of the business objects involved in the data verification request, and matching the applicable business type with the business type of the metadata from a pre-built data verification rule library, target data verification rules that meet the business type matching conditions are obtained, thus enabling precise association between data verification rules and business types. Since the business type of the metadata can characterize the business semantics and attribute features of the business object, the target data verification rules obtained based on business type matching can adapt to the actual verification needs of the business object, thereby improving the accuracy of rule configuration.

[0049] Furthermore, since each data validation rule includes at least one atomic rule, and each atomic rule is an independently encapsulated data validation logic unit, the data validation rules are reusable and composable. When validating similar attributes of different business objects, existing atomic rules can be directly reused, thereby reducing the cost of redundant development and maintenance of validation rules.

[0050] The system architecture of the embodiments of this application will be described below as an example.

[0051] This application provides a system architecture for a data verification system, such as... Figure 1 As shown, the data verification system may include: computing device 101, client 102 and server 103.

[0052] The computing device 101 is communicatively connected to the client 102 and the server 103.

[0053] The computing device 101 is used to execute the data verification method provided in the embodiments of this application, including generating target data verification rules and sending the target data verification rules to the client 102 and the server 103, etc.

[0054] The client 102 is used to collect front-end business data and verify the front-end business data according to the target data verification rules sent by the computing device 101.

[0055] Server 103 is used to receive business data (here, backend business data) sent by client 102 and to verify the backend business data according to the target data verification rules sent by computing device 101.

[0056] This application does not impose any restrictions on the specific form of the computing device 101. For example, the computing device 101 can be a server. The server can be a single server, or a server cluster composed of multiple servers. In some embodiments, the server cluster can also be a distributed cluster, which is not limited in this application. Furthermore, the computing device 101 and the data source device 102 can specifically be terminal devices. The terminal device can be referred to as: terminal, user equipment (UE), terminal device, access terminal, user unit, user station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or user equipment, etc. Specifically, the terminal device can be a mobile phone, augmented reality (AR) device, virtual reality (VR) device, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc.

[0057] It should be pointed out that, Figure 1 The system architecture shown does not constitute a limitation on the data verification system, except... Figure 1 In addition to the devices shown, the data verification system may include more or fewer devices than illustrated, or a combination of certain devices, or different device arrangements.

[0058] For example, the computing device 101 and the client 102 described above can be integrated into the same device. As another example, the computing device 101 and the server 103 described above can be integrated into the same device.

[0059] When computing device 101 and client 102 or server 103 are integrated into the same device, the communication method between computing device 101 and client 102 or server 103 is the communication between modules within the device. For ease of description, this application embodiment uses electronic device 101 and client 102 and server 103 as multiple independent devices for illustration.

[0060] When a computing device executes the data verification method provided in the embodiments of this application, it can divide the internal structure of the computing device into multiple levels and multiple logical modules according to the method execution logic. For example, as shown below... Figure 2 As shown, the computing device 101 may include: an interaction layer, a rule configuration layer, a core engine layer, a data storage layer, and an adaptation layer.

[0061] The interaction layer includes a visual operation interface, which provides an interface for users to input data verification requests and displays the configuration process and verification results of data verification rules.

[0062] The rule configuration layer includes an atomic rule management module and a combined rule generation module. The atomic rule management module is used to create, modify, and delete atomic rules; the combined rule generation module is used to combine multiple atomic rules in response to the selection operation of multiple atomic rules to generate a data validation rule containing multiple atomic rules.

[0063] The core engine layer comprises a language processing engine, an intelligent recommendation engine, a compliance verification engine, and a unified verification engine. The language processing engine performs semantic parsing of the natural language descriptions carried in data verification requests to determine the business type of the metadata. The intelligent recommendation engine matches candidate data verification rules from the data storage layer based on the business type of the metadata and then ranks and recommends these rules. The compliance verification engine performs logical mutual exclusion verification on the data verification rules. The unified verification engine generates a data verification file based on the target data verification rules and sends the file to the client and server via an adaptation layer.

[0064] The data storage layer includes a business ontology metadata database, an atomic rule base, and a composite rule base. The business ontology metadata database stores the metadata of business objects, including the business type of each object. The atomic rule base stores multiple atomic rules and the applicable business types for each atomic rule. The composite rule base stores data validation rules generated by combining multiple atomic rules.

[0065] The adaptation layer includes a front-end / back-end adaptation module and a hot update module. The front-end / back-end adaptation module converts the data verification files generated by the unified verification engine into a format recognizable by both the client and server. The hot update module dynamically pushes the data verification files to the client and server, enabling both the client and server to verify front-end and back-end business data based on the same set of data verification rules.

[0066] The specific implementation process of the functions of each of the above modules can be found in the following description, and will not be repeated here.

[0067] It should be pointed out that, Figure 2 The hierarchical and modular architecture shown does not constitute a limitation on the internal structure of computing device 101, except... Figure 2 In addition to the individual levels and modules shown, a computing device may include more or fewer levels and modules than illustrated, or combine certain levels and modules, or have different arrangements of levels and modules.

[0068] The data verification method provided in the embodiments of this application will be described in detail below.

[0069] like Figure 3 The diagram shown is a flowchart illustrating a data verification method provided in an embodiment of this application. Figure 3 The method shown can be applied to computing devices. This data verification method includes: S301. The computing device responds to the received data verification request by obtaining the business type of the metadata of the business object involved in the data verification request.

[0070] In one possible implementation, the aforementioned data verification request can be triggered by the client (such as a product publishing page used by a merchant) when data verification is required, or by operations performed by business personnel on a visual interface provided by a computing device. The data verification request carries information about the requested business object, such as a business object identifier or a business attribute identifier.

[0071] After receiving a data verification request, the computing device parses the request to obtain information about the business objects involved, and then retrieves the metadata corresponding to the business object from the pre-built business ontology metadata database.

[0072] The business ontology metadata database pre-stores metadata models for each business entity object within the business domain. These metadata models are used to abstractly describe the business semantics of business objects and their attributes. The metadata for each business object or business attribute includes business type information. For example, the business type can represent the business category to which the business object belongs (such as product category, order information, etc.) or the data type of the business object's attribute (such as string type, numeric type, enumeration type, etc.).

[0073] In some embodiments, the computing device may pre-establish metadata for each business entity object within the business domain before receiving a data verification request.

[0074] Computing devices can abstract business objects within a business domain, determine the business attributes contained in each business object, as well as the data type, constraint scope, and business semantics of each business attribute.

[0075] For example, in the e-commerce field, the business object of a stock keeping unit (SKU) includes business attributes such as color, size, and inventory quantity. Among them, the data type of the color attribute is an enumeration type, and the range of enumeration values ​​is a preset set of color options; the data type of the inventory quantity attribute is an integer type, and the constraint range is greater than or equal to zero.

[0076] The computing device can construct the above abstract results into structured metadata. This metadata is based on business objects, recording descriptive information for each business object and its attributes. Each business attribute in the metadata corresponds to a metadata record, which includes at least: attribute identifier, attribute name, business type, data type, constraints, and business semantic tags.

[0077] The business type is used to characterize the business category or data characteristic to which the attribute belongs. For example, the business type of the color attribute can be labeled as a specification attribute or an enumerated specification. The data type is used to characterize the data format characteristics of the attribute, such as string, integer, floating-point number, enumeration, date, etc. The constraints are used to characterize the basic limitations of the attribute, such as string length range, numerical value range, enumeration value set, etc. The business semantic label is used to characterize the meaning of the attribute in a business scenario, such as financial fields, personal information, etc.

[0078] The computing device can store the completed metadata in the computing device's business ontology metadata database. This business ontology metadata database can be implemented using a graph database to establish the association between business objects and business attributes, and between business attributes themselves, so as to facilitate subsequent fast querying and expansion.

[0079] In some embodiments, the data verification request may carry a verification rule requirement described in natural language. The computing device can use natural language processing technology to parse the metadata of the business objects involved in the data verification request from the natural language description.

[0080] Specifically, the computing device can preprocess the input for the verification rules described in natural language. The device receives text information entered by the user through a visual interface, or receives voice information input by the user and converts the voice into text. Subsequently, the device performs format standardization processing on the text content, automatically filtering out non-core characters such as line breaks, emoticons, and special punctuation, generating standardized text to be parsed.

[0081] Next, the computing device performs semantic understanding on the text to be parsed to obtain the semantic understanding result. This semantic understanding result includes the metadata of the business objects involved in the data verification request.

[0082] In one feasible approach, the semantic understanding process includes redundant information cleaning, core information extraction, and ambiguity resolution.

[0083] Redundant information cleaning refers to the process by which computing devices remove redundant content such as modifiers and interjections from the text to be parsed that do not affect the core semantics, such as "I want" or "please configure it," while retaining the key business descriptions.

[0084] Core information extraction refers to the semantic parsing of cleaned text by computing devices to extract core information in the form of a triplet: subject-constraint-logical relationship. Here, the subject represents the business object or attribute that needs to be validated, such as color; the constraint represents the validation requirements imposed on the subject, such as only being red, blue, or green; and the logical relationship represents the combination relationship between multiple constraints, such as AND, OR, etc.

[0085] Ambiguity resolution refers to the process by which computing devices resolve ambiguities in the extracted results that may contain multiple meanings. The computing device can pre-build an ambiguous terminology database, recording business terms that are prone to ambiguity and their possible meanings. When the extracted information matches the ambiguous terminology database, the computing device pushes a confirmation option to the user, allowing the user to select the correct meaning. For parsing results that do not match the ambiguous terminology database but have low confidence, the computing device can also prompt the user through the interface to confirm or supplement information, ensuring the accuracy of semantic interpretation.

[0086] S302. The computing device obtains the target data verification rule that matches the business type of the metadata from the pre-built data verification rule library.

[0087] The data validation rule base includes multiple data validation rules and the applicable business types for each rule. The multiple data validation rules include target data validation rules. Each data validation rule includes at least one atomic rule. Atomic rules represent independently encapsulated data validation logic. The applicable business type of the target data validation rule and the business type of the metadata satisfy the business type matching condition.

[0088] The data validation rule base is pre-built, storing multiple data validation rules and the applicable business types for each rule. The applicable business type characterizes which business categories or data types the data validation rule can be applied to, such as string types, numeric types, enumeration types, date types, etc., or more granular business semantic types such as product specification attributes, order amount fields, customer identity information, etc.

[0089] Each data validation rule includes at least one atomic rule. An atomic rule is an independently encapsulated unit of data validation logic. Each atomic rule encapsulates a general data validation logic, such as non-empty validation, numeric range validation, string length validation, enumeration value validation, regular expression matching validation, date format validation, etc.

[0090] Each atomic rule has clearly defined input parameters and output results, and can be called independently or combined with other atomic rules. The encapsulated form of atomic rules allows them to be reused in different business scenarios. For example, the atomic rule for NOT NULL validation can be used for both product name and customer name fields.

[0091] Data validation rules can be single atomic rules or combinations of multiple atomic rules. When a data validation rule includes multiple atomic rules, these atomic rules are arranged in a preset logical order to jointly complete a complex business validation requirement. For example, an order amount validation rule can be composed of multiple atomic rules such as non-empty validation, numeric type validation, greater than zero validation, and matching validation with the product's unit price * quantity.

[0092] The computing device can match the business type of the metadata with the applicable business type of each data verification rule in the data verification rule base to determine the target data verification rule that meets the business matching conditions.

[0093] In some embodiments, the above-mentioned business matching conditions include: the business scenario similarity between the applicable business type of the data verification rule and the business scenario of the metadata is greater than a preset scenario similarity, and / or, the semantic similarity between the semantic features of the applicable business type of the data verification rule and the semantic features of the business type of the metadata is greater than a preset semantic similarity.

[0094] For the process of matching business scenario similarity, the business type of metadata can be categorized into a specific business scenario. For example, the order amount attribute belongs to the transaction settlement scenario, the customer mobile phone number attribute belongs to the customer contact information scenario, and the product color attribute belongs to the product specification scenario. Similarly, the applicable business types of data validation rules can also be categorized into one or more business scenarios. For example, numerical range validation rules can belong to the amount validation scenario and the quantity validation scenario, and mobile phone number format validation rules belong to the contact information validation scenario.

[0095] The computing device can pre-build a business scenario tagging system, assigning one or more business scenario tags to each business type and each data verification rule. Business scenario tags can be hierarchical; for example, a transaction scenario may include sub-scenarios such as order scenarios, payment scenarios, and refund scenarios. The computing device obtains the set of business scenario tags to which a data verification rule belongs based on the business type of the metadata, and obtains the set of business scenario tags to which the data verification rule belongs based on the applicable business type. Then, it calculates the scenario similarity between the two sets.

[0096] In one feasible approach, scene similarity can be calculated by: calculating the percentage of identical scene tags in two sets, or calculating similarity based on the hierarchical distance between scene tags. If the calculated scene similarity is greater than a preset scene similarity threshold, such as 0.7, then the data validation rule is determined to meet the business matching conditions.

[0097] For example, suppose the business type of the metadata is order payment amount, and its applicable business scenario tags include transaction scenario and amount verification scenario. There is a numerical range verification rule in the data verification rule base, whose applicable business type belongs to the business scenario tags of amount verification scenario and quantity verification scenario. The computing device calculates the similarity between the two scenario tag sets and finds that the common scenario tag is the amount verification scenario, with a high similarity exceeding a preset threshold. Therefore, this numerical range verification rule is determined as the rule that meets the business matching conditions.

[0098] For the semantic feature similarity matching process, the business type of metadata can contain semantic feature information. For example, the business type of customer age implies semantic features such as numerical type, non-negative integer, and personal information. The applicable business type of data validation rules can also contain semantic feature information. For example, the greater than threshold validation rule implies semantic features such as numerical type and comparison operation.

[0099] Computing devices can pre-construct a semantic feature vector space, mapping each business type and each data verification rule to a semantic feature vector. Semantic feature extraction can be achieved through natural language processing (NLP) techniques, such as word vector encoding of business type names or generating feature vectors based on predefined semantic labels.

[0100] The computing device generates a first semantic feature vector based on the business type of the metadata, and a second semantic feature vector based on the applicable business type of the data verification rule. Then, it calculates the semantic similarity between the two vectors, such as cosine similarity. If the calculated semantic similarity is greater than a preset semantic similarity threshold, such as 0.8, then the data verification rule is determined to meet the business matching conditions.

[0101] For example, suppose the business type of the metadata is membership level, and its semantic feature vector includes features such as numerical, enumerable, and user attributes. There is an enumerable value validation rule in the data validation rule base, whose semantic feature vector includes features such as enumerable and value range validation. The computing device calculates the cosine similarity between the two vectors to be 0.85, which exceeds the preset threshold of 0.8. Therefore, this enumerable value validation rule is determined to be a rule that meets the business matching conditions.

[0102] In some embodiments, the computing device may also combine the two matching methods described above.

[0103] Specifically, the business matching condition can be set to satisfy at least one of the following: business scenario similarity greater than preset scenario similarity or semantic similarity greater than preset semantic similarity; or both conditions can be satisfied.

[0104] For example, when matching validation rules for critical business fields, it's possible to require both similarities to exceed a threshold to improve matching accuracy. For more general fields, it's acceptable to allow only one of them to be satisfied, thus broadening the rule's coverage.

[0105] By introducing business scenario similarity and semantic feature similarity as matching conditions, computing devices can still match appropriate data verification rules even when there are differences in the description of business types but similar actual meanings. This improves the flexibility and accuracy of rule matching and avoids the problem of rule omissions caused by inconsistent business type naming or different description methods.

[0106] In some embodiments, when a computing device matches a target data verification rule based on service matching conditions, it may also perform the matching using at least one of the following matching methods: Method 1: Precise Type Matching. This method directly compares the business type of the metadata with the applicable business type of the data validation rule. If they match or have an inclusion relationship, the data validation rule is determined to meet the business type matching condition. For example, if the business type of the metadata is an enumeration type, then a data validation rule applicable to an enumeration type is determined to be a match.

[0107] Method 2: Hierarchical matching. The business types of metadata can include multiple levels of information, such as a business category layer (e.g., product information) and a data type layer (e.g., string type). The computing device first matches a coarse-grained set of rules based on the business category layer, and then filters out fine-grained rules based on the data type layer. For example, it first matches rules for product information, and then filters out rules applicable to string types.

[0108] Using the matching method described above, the computing device filters one or more data verification rules from the data verification rule base that meet the business type matching conditions, as candidate data verification rules. If there are multiple candidate data verification rules, the computing device can further determine one or more as target data verification rules based on information such as rule priority, historical usage frequency, and user preferences. The specific process is described below and will not be repeated here.

[0109] The determination of the target data verification rule can be a combination rule containing multiple atomic rules or a single atomic rule, depending on the complexity of the verification requirements corresponding to the business type of the metadata.

[0110] For example, for a color attribute whose business type is an enumeration, the matched target data validation rule can be a single atomic rule enumeration value validation. For complex validation requirements where the business type is order amount, the matched target data validation rule can be a combined rule composed of multiple atomic rules.

[0111] Through the above methods, the computing device achieves precise matching between data verification rules and business object attribute types, enabling the obtained target data verification rules to adapt to the actual verification requirements of business objects, thus laying the foundation for subsequent consistency verification of front-end and back-end business data.

[0112] For example, such as Figure 4 As shown, the data validation rule base is pre-built, and its structure can adopt a layered design, including an atomic rule base, a combined rule base, and a business object reference layer, so as to facilitate rule management, reuse, and dynamic configuration.

[0113] The atomic rule library stores multiple reusable basic atomic rules. Each atomic rule is an independently encapsulated data validation logic unit, possessing a unique identifier, rule name, applicable business type, and corresponding validation logic implementation. The applicable business type of an atomic rule characterizes which data types or business scenarios the rule can be applied to. For example... Figure 4 As shown, the atomic rule base includes, but is not limited to, the following basic verification rules: Required field validation, rule identifier (ID) is R001, applicable business type is all types, used to validate whether the field has a value.

[0114] Non-empty validation, rule identifier R002, applicable to all business types, used to validate whether a field is an empty string or a null value.

[0115] Among them, the required field validation and the non-empty field validation are the basic validation classes.

[0116] Mobile number format validation, rule identifier R003, applicable business type is string type, used to validate whether the field conforms to the mobile number format specification.

[0117] Email format validation, rule identifier R004, applicable business type is string type, used to validate whether the field conforms to the email format specification.

[0118] ID card format validation, rule identifier R005, applicable business type is string type, used to validate whether the field conforms to the ID card number format specification.

[0119] Among them, mobile phone number format verification, email format verification, and ID card format verification are classified as format verification.

[0120] Numeric range validation, rule identifier R006, applicable business type is numeric type, used to validate whether the field value is within the specified minimum and maximum value range.

[0121] The "Greater Than Threshold" check, rule identifier R007, applies to numeric data types and is used to check whether a field value is greater than a specified threshold.

[0122] Among them, the numerical range check and the greater than threshold check are numerical check categories.

[0123] The combination rule library stores combination rules dynamically generated from multiple atomic rules. Combination rules are further encapsulations and reuses of atomic rules to meet complex validation requirements in specific business scenarios. Each combination rule includes a combination of multiple atomic rules and the logical orchestration relationships between these atomic rules. Combination rules also have applicable business types, characterizing which business attributes the combination rule can be applied to. For example... Figure 4 As shown, the rule base for combining rules includes, but is not limited to, the following examples: The personal customer contact number combination rule, identified as D1, consists of a mandatory field validation R001 and a mobile phone number format validation R003, and is applicable to the contact number attribute business type.

[0124] The sales order amount combination rule, identified as D2, is composed of a mandatory validation R001 and a value range validation R006 (with parameters set to 1-1,000,000). It is applicable to business types with order amount attributes.

[0125] The enterprise customer information combination rule, identified as D3, is composed of mandatory field validation R001, email format validation R004, and mobile phone number format validation R003. It is applicable to multiple attributes such as email and contact phone number for various business types.

[0126] The business object reference layer records the reference relationships between actual business objects and data validation rules. Each business object has a unique metadata identifier, which associates the business object with the applicable data validation rules. For example... Figure 4 As shown, the business object reference layer includes, but is not limited to, the following examples: The individual customer business object has a metadata identifier of CUST001 and a reference rule identifier of D1, indicating that the relevant attributes of the individual customer are subject to the individual customer contact number combination rule.

[0127] The sales order business object has the metadata identifier ORDER001 and the reference rule identifier D2, indicating that the relevant attributes of the sales order are subject to the sales order amount combination rule.

[0128] The enterprise customer business object has a metadata identifier of COMP001 and a reference rule identifier of D3, indicating that the relevant attributes of the enterprise customer are subject to the enterprise customer information combination rule.

[0129] Based on the above hierarchical structure, the specific process by which the computing device obtains the target data verification rules that match the service type of the metadata is as follows: First, the computing device queries the rule identifier referenced by the target business object from the business object reference layer based on the target business object's metadata identifier. For example, if the target business object is a sales order with metadata identifier ORDER001, the referenced rule identifier found will be D2.

[0130] Secondly, the computing device retrieves the corresponding combination rule from the combination rule base based on the queried rule identifier. If the rule identifier corresponds to a combination rule, it retrieves the multiple atomic rules contained in that combination rule and their logical arrangement relationship. For example, rule identifier D2 corresponds to a sales order amount combination rule, which contains atomic rules R002 (non-empty check) and R006 (numerical range check), and the parameter of R006 is set to a minimum value of 1 and a maximum value of 1 million.

[0131] If the rule identifier found in the query corresponds to an atomic rule, then the atomic rule is directly retrieved from the atomic rule library. For example, if the target business object is a scenario that requires separate configuration of mobile phone number format validation, then atomic rule R003 may be directly referenced.

[0132] In this way, the computing device obtains the target data validation rule that matches the business type of the metadata from the data validation rule base. This target data validation rule can be a single atomic rule or a combination of multiple atomic rules, depending on the rule configuration predefined in the business object reference layer.

[0133] This layered data validation rule library uses atomic rules to reuse basic validation logic, combined rules to dynamically configure complex validation requirements, and a business object reference layer to flexibly associate rules with specific business objects, thereby improving the maintainability and scalability of data validation rules.

[0134] S303. The computing device verifies the front-end business data and back-end business data requested for verification in the data verification request according to the target data verification rules.

[0135] The front-end business data and the back-end business data have the same business meaning, but they are located on different endpoints.

[0136] In some embodiments, the method by which a computing device verifies the front-end business data and back-end business data requested for verification in a data verification request according to a target data verification rule specifically includes: the computing device generating a data verification file in a target format according to the target data verification rule, adding the data verification file to the data verification request, and sending a data verification request carrying the data verification file to the client storing the front-end business data and the server storing the back-end business data, respectively, to request the client to call a data verifier adapted to the target format to verify the front-end business data, and to request the server to call a data verifier adapted to the target format to verify the back-end business data.

[0137] In one possible approach, the target format for the data validation file can be Shapes Constraint Language (SHACL) format, which can describe various constraints on business data independently of a specific programming language, including whether fields are required, data types, value ranges, formatting rules, etc.

[0138] In one feasible approach, before sending data verification requests carrying data verification files to the client storing front-end business data and the server storing back-end business data, respectively, the computing device can also perform format conversion on the data verification file according to the adaptation requirements of the client and the server.

[0139] For example, on the client side, the computing device can convert the data validation file into a lightweight format that the client can recognize, such as a JSON-formatted rule description file, which contains field names, validation rule types, rule parameters, and error messages.

[0140] On the server side, computing devices can directly use SHACL format data verification files, or convert them to a format that can be loaded by the server-side unified verification engine. The computing devices dynamically push the data verification files to the client and server via a hot update mechanism, enabling both clients and servers to obtain the latest verification rules promptly without restarting the service.

[0141] After receiving a data verification request carrying a data verification file, the client calls a data verifier adapted to the target format to verify the front-end business data.

[0142] Specifically, the client can parse the data validation file, extract the data validation rules, and perform validation in real time when the user inputs or modifies front-end business data. If the front-end business data fails validation, the client immediately displays an error message and blocks data submission; if the front-end business data passes validation, the client allows the data to be submitted to the server.

[0143] After receiving a data verification request carrying a data verification file, the server calls a data verifier adapted to the target format to verify the backend business data.

[0144] Specifically, the server can load the data validation file into the unified validation engine. When it receives backend business data submitted by the client, it calls the unified validation engine to validate the backend business data according to the validation rules in the data validation file. If the backend business data fails validation, the server returns a validation failure error message to the client and refuses to write the data to the database or proceed to subsequent business processes; if the backend business data passes validation, the server allows the data to proceed to the next step of processing.

[0145] In this way, the client and server validate the front-end and back-end business data respectively based on the same data validation file generated by the target data validation rules. Since the target data validation rules originate from the same source, the compliance judgment results for the same business data by the front-end and back-end are consistent, thus achieving consistency in front-end and back-end data validation. Even if the front-end validation is bypassed or tampered with, the back-end validation can still ensure the compliance and integrity of business data during the flow process.

[0146] The process of determining the target data verification rules in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0147] In some embodiments, such as Figure 5 As shown, the method by which a computing device obtains target data verification rules that match the business type of metadata from a pre-built data verification rule base specifically includes: S501. The computing device identifies the data verification rules in the data verification rule library that meet the business matching conditions with the business type of the metadata as candidate data verification rules.

[0148] During the matching process, the computing device can traverse all data verification rules in the data verification rule base and extract the data verification rules whose applicable business type and the business type of the metadata meet any of the above business matching conditions, as candidate data verification rules. Candidate data verification rules can include single atomic rules or combined rules composed of multiple atomic rules, depending on the rule configuration in the rule base.

[0149] In this way, the computing device selects one or more candidate data verification rules from the data verification rule library that match the business type of the metadata, providing a basis for subsequently determining the final target data verification rule from the candidate data verification rules.

[0150] S502. The computing device determines the data verification rules that meet the heat conditions among the candidate data verification rules as the target data verification rules.

[0151] There may be multiple candidate data validation rules. To select the best-performing and most relevant data validation rules from these candidates, the computing device can introduce a popularity criterion as a selection factor. The popularity criterion characterizes the popularity, activity level, and general value of the data validation rule in business applications. The computing device then identifies one or more rules from the candidate data validation rules that meet the preset popularity criteria as the final target data validation rules.

[0152] In some embodiments, the popularity condition includes at least one of the following: the rule usage frequency is greater than the preset frequency, the rule usage growth rate is greater than the preset growth rate, and the rule reuse rate under different business objects is greater than the preset reuse rate.

[0153] Rule usage frequency refers to the number of times a data validation rule is invoked within a preset time period. This metric reflects the rule's activity level and practical application value. The computing device can count the number of times each data validation rule has been invoked for data validation in a recent period (e.g., the past 30 days) from system logs. A higher invocation count indicates that the rule is used frequently, and its stability and versatility have been verified. The computing device compares the rule usage frequency with a preset frequency threshold. If the rule usage frequency exceeds the preset threshold, the rule is deemed to meet the usage frequency requirement. The preset frequency can be dynamically adjusted based on business scale and historical data, for example, set to 1.5 times the average invocation count of all rules.

[0154] The rule usage growth rate refers to the trend of the frequency of use of data validation rules over a continuous time period. This indicator reflects whether the popularity of a rule is increasing and is of significant reference value for newly launched rules or seasonal business rules. The computing device can count the usage frequency of a rule in the current period (e.g., the last 7 days) and compare it with the usage frequency in the previous period (e.g., the 7 days before that) to calculate the growth rate. The growth rate can be calculated as (current period usage frequency - previous period usage frequency) / previous period usage frequency. If the rule usage growth rate is greater than a preset growth rate threshold, the rule is considered to meet the usage growth rate condition. The growth rate threshold can be set to a positive value, such as 0.2, indicating that rules with a usage frequency increase of more than 20% are considered popular rising rules. For newly launched rules, if the usage frequency in the previous period was zero, they can be handled separately, such as directly marking them as meeting the growth rate condition or assigning an initial popularity value.

[0155] Rule reuse rate refers to the number of times the same data validation rule is applied to different business objects or different business attributes. This metric reflects the rule's versatility and reusability. For example, an atomic rule for "non-empty validation" can be applied to different attributes of multiple different business objects, such as product name, customer name, and order remarks, resulting in a high reuse rate. Conversely, some combined rules designed for specific scenarios may only be referenced by a few business objects, leading to a lower reuse rate. The computing device can count the number of business objects or business attributes associated with each data validation rule and compare this number to a preset reuse rate threshold. If the rule reuse rate is greater than the preset threshold, the rule is deemed to meet the reuse rate condition. The reuse rate threshold can be set according to the rule type; for example, a higher threshold can be set for atomic rules, while a relatively lower threshold can be set for combined rules.

[0156] In some embodiments, the above three heat conditions can be used individually, that is, as long as any one of them is met, the rule can be determined as the target data verification rule.

[0157] In other embodiments, the computing device may combine multiple popularity conditions to improve the accuracy of screening. For example, it may require rules to simultaneously meet the usage frequency condition and the reuse rate condition, or it may perform a weighted comprehensive score on the three popularity conditions and determine the rules with a comprehensive score greater than a preset threshold as the target data verification rules.

[0158] By introducing popularity criteria, computing devices can filter out high-quality rules from candidate data validation rules that are widely used in business practice, have increasing popularity, and have high reusability. This makes the final target data validation rules more closely aligned with actual business needs, improving the accuracy and practicality of rule matching. Statistics on popularity criteria can be updated regularly to reflect dynamic changes in rule popularity, ensuring the timeliness of the filtering results.

[0159] In some embodiments, the candidate data validation rules include a first set of sub-rules and a second set of sub-rules. The candidate data validation rules in the first set of sub-rules are combined rules consisting of multiple atomic rules. The candidate data validation rules in the second set of sub-rules are single atomic rules.

[0160] In some embodiments, after the computing device matches the business type of the metadata with the applicable business type of the data verification rules, the selected candidate data verification rules may have different levels of complexity and structure. To facilitate subsequent rule selection, sorting, and recommendation, the computing device can classify the candidate data verification rules according to their structure, forming a first sub-rule set and a second sub-rule set.

[0161] In other words, the candidate data validation rules include a first set of rules and a second set of rules. The candidate data validation rules in the first set of rules are combination rules composed of multiple atomic rules. The candidate data validation rules in the second set of rules are single atomic rules.

[0162] The candidate data verification rules in the first sub-rule set are composite rules, which are data verification rules composed of multiple atomic rules combined according to specific logical relationships. Composite rules are typically used to meet complex business verification needs, requiring the combined action of verification logic from multiple dimensions to complete the integrity verification of business data.

[0163] Each combination rule contains at least two atomic rules. For example, combining... Figure 4 The sales order-amount combination rule can include a combination of non-empty check atomic rules (R002), numeric type check atomic rules (R006), and greater than threshold check atomic rules (R007).

[0164] Multiple atomic rules in a combined rule are arranged in a preset logical order to determine the execution sequence of each atomic rule. For example, for the validation of a monetary field, the non-empty validation is usually performed first, followed by the numeric type validation, and finally the numeric range validation or threshold comparison validation.

[0165] Atomic rules within a composite rule may have parameter dependencies; a later-executed atomic rule may need to use the validation result of a previously executed atomic rule as its input parameter. For example, in a composite rule that matches the product price * quantity, the product price and quantity values ​​need to be obtained first, their product calculated, and then compared with the order amount.

[0166] Combination rules typically correspond to specific business scenarios or business objects and have explicit business semantics. For example, a "personal customer - contact number" combination rule is explicitly used to validate the contact number field of an individual customer; its business semantics is to verify the validity of the contact information. Combination rules are directly associated with specific business objects or business attributes in the business object reference layer.

[0167] In one feasible approach, the combination rules in the first sub-rule set can be obtained from a combination rule library. The combination rule library pre-stores various combination rules dynamically generated by atomic rules. Each combination rule has a unique rule identifier, applicable business type, a list of included atomic rules, the arrangement order of the atomic rules, and parameter configuration information.

[0168] The candidate data validation rules in the second sub-rule set are atomic rules, which are single, independently encapsulated data validation logic units. Atomic rules are typically used to meet basic, single-dimensional validation needs. They can be flexibly combined or applied individually to simple validation scenarios.

[0169] Each atomic rule encapsulates only one general data validation logic, such as non-empty validation, numerical range validation, enumeration value validation, regular expression matching validation, etc.

[0170] Atomic rules can be defined by the applicable business type. For example, a mobile number format validation atomic rule applies to all attributes whose business type is string and whose business semantics are "mobile number". Therefore, it can be reused for multiple different business attributes such as customer mobile number, contact mobile number, and emergency contact mobile number.

[0171] Atomic rules typically support parameterized configuration to adapt to specific validation requirements in different business scenarios. For example, atomic rules for numerical range validation can be configured with minimum and maximum value parameters; atomic rules for regular expression matching validation can be configured with specific regular expression strings; and atomic rules for enumeration value validation can be configured with the set of allowed enumeration values.

[0172] Atomic rules are the basic units for constructing composite rules. The process of generating composite rules is essentially about selecting multiple atomic rules from the atomic rule base and then logically arranging and configuring their parameters.

[0173] In one feasible approach, the atomic rules in the second sub-rule set can be obtained from an atomic rule library. The atomic rule library pre-stores multiple basic atomic rules, each with a unique rule identifier, rule name, applicable business type, validation logic implementation, and configurable parameter definitions.

[0174] The computing device divides candidate data verification rules into a first set of rules and a second set of rules. When filtering target data verification rules based on popularity criteria, different popularity thresholds or filtering strategies can be set for combined rules and atomic rules respectively. For example, for combined rules, their reusability and scenario adaptability can be given more emphasis, while for atomic rules, their usage frequency and versatility can be given more emphasis.

[0175] Secondly, when presenting candidate data validation rules to users, combined rules and atomic rules can be presented separately, or the display order can be adjusted according to the rule type. For example, combined rules that are highly compatible with the current business scenario can be displayed first, followed by optional atomic rules for users to combine themselves.

[0176] Furthermore, users with extensive business experience can directly select ready-made combination rules from the first sub-rule set to quickly complete rule configuration; users who need to customize rules can select atomic rules from the second sub-rule set to create rules that meet specific needs.

[0177] Through the above classification method, computing devices can manage candidate data verification rules more precisely, which facilitates subsequent rule filtering, sorting and recommendation, and user selection.

[0178] In some embodiments, a computing device may obtain candidate data verification rules through the following triggering methods: Method 1: Proactive Scene Selection Trigger. The computing device can provide users with a business scene selection entry point through a visual interface in the interaction layer. Users (such as business personnel) can proactively select the target business object and the specific business scene, such as selecting a product specification configuration scene or a major promotional activity verification scene on the product publishing interface. Responding to the user's selection, the computing device queries the data storage layer for historically frequently associated verification rules within that scene, including commonly used atomic rules, combination rules, and business attributes associated with that scene. The retrieved rules serve as candidate data verification rules for subsequent filtering and recommendation.

[0179] Method Two: Natural Language Semantic Triggering. The computing device receives natural language description information input by the user, such as the user entering "I want to set validation rules for order amounts during a major promotion." The computing device performs semantic parsing on the natural language description information, extracting core scenario tags and associated attributes. Scenario tags include "major promotion," "sales promotion," and "daily transactions," while associated attributes include "order amount" and "product price." Based on the extracted scenario tags, the computing device automatically matches a preset business scenario library to determine the business scenario to which the current configuration belongs; simultaneously, it matches the corresponding business objects and business attributes based on the associated attributes. Based on the matched business scenario and attributes, candidate data validation rules for that scenario are retrieved from the data storage layer.

[0180] Through the two triggering methods mentioned above, the computing device can accurately locate the user's current business scenario and configuration intent, providing accurate contextual information for subsequent rule filtering, popularity calculation, and personalized recommendations.

[0181] In some embodiments, the computing device can directly determine the target data verification rule from the candidate data verification rules based on the popularity condition. Alternatively, when there are many candidate data verification rules or user participation in the decision-making process is required, the computing device can also determine the target data verification rule based on user selection through the following steps S503-S505. In this case, such as... Figure 5 As shown, when there are multiple candidate data validation rules, the method also includes: S503. The computing device acquires the popularity information and / or user preference information of each candidate data verification rule among multiple candidate data verification rules.

[0182] When there are multiple candidate data verification rules, in order to select the target data verification rule that best meets the current business scenario and user needs from multiple candidate data verification rules, the computing device needs to obtain the popularity information and / or user preference information of each candidate data verification rule as the basis for subsequent sorting, filtering or recommendation.

[0183] Popularity information is used to characterize the popularity, activity level, and general value of data validation rules in business applications. Computing devices can statistically analyze and calculate various popularity metrics from system logs, rule call records, and rule association data, specifically including at least one of the following: rule usage frequency, rule usage growth rate, and rule reuse rate across different business objects. Popularity information can be obtained through real-time calculation or through periodic pre-calculation and storage in a rule base. Computing devices can read pre-calculated popularity information from popularity statistics tables in the data storage layer or from extended fields in the rule base to improve query efficiency.

[0184] User preference information is used to characterize the degree of preference of the current user or user group for specific data validation rules. User preference information can be obtained based on the user's explicit operational behavior and implicit operational habits, specifically including at least one of the following methods: Historical Selection Records: The computing device records the target data validation rules selected by the current user from the candidate data validation rule list during the historical rule configuration process. By analyzing the user's historical selection records, it is possible to identify the user's preferred rule types, rule combinations, or specific rule identifiers. For example, if a user selects the enumeration value validation atomic rule multiple times in product attribute configurations, it can be inferred that the user has a preference for enumeration value validation rules.

[0185] User Roles and Business Domains: The computing device obtains the current user's role information (e.g., operations personnel, developers, business experts) and their responsible business domain (e.g., product management, order management, customer management). Users with different roles and domains may have different preferences for data validation rules. For example, product operations personnel may prefer validation rules related to product specifications, while order management personnel may prefer validation rules related to monetary calculations.

[0186] User group preferences with similar roles: Computing devices can statistically analyze the rule selection preferences of user groups with the same roles or business areas as the current user. For example, for new users or users with limited historical records, recommendations can be made by referring to the preference information of user groups with similar roles. The statistical analysis of group preferences can be based on collaborative filtering algorithms to identify other users similar to the current user and analyze their rule selection patterns.

[0187] Rule evaluation feedback: Computing devices can collect explicit feedback from users on rules they have used, such as liking, disliking, saving, and marking as frequently used rules. This explicit feedback information can be directly incorporated into user preference information.

[0188] Configuration duration and adjustment frequency: Computing devices can record user behavior when configuring rules, such as the time a user spends on a particular rule, the number of times rule parameters are adjusted, and whether the recommended rule is ultimately adopted. These implicit behavioral characteristics can indirectly reflect the user's preference for the rules.

[0189] In some embodiments, the computing device may acquire popularity information separately to objectively reflect the overall popularity of the rule; or it may acquire user preference information separately for personalized rule recommendations.

[0190] In other embodiments, the computing device can simultaneously acquire popularity information and user preference information, and combine the two for comprehensive evaluation. For example, popularity information and user preference information can be quantitatively scored separately, and then weighted and summed according to preset weights to obtain a comprehensive score for each candidate data verification rule.

[0191] By acquiring popularity information and / or user preference information of candidate data verification rules, the computing device provides rich decision-making basis for subsequent rule sorting, filtering and recommendation, and can more accurately determine the target data verification rule that is most suitable for the current business scenario and user needs from multiple candidate data verification rules.

[0192] S504. The computing device sorts and displays multiple candidate data verification rules based on the popularity information and / or user preference information of each candidate data verification rule.

[0193] After obtaining the popularity information and / or user preference information of each candidate data verification rule, the computing device sorts the multiple candidate data verification rules according to this information and displays the sorted list of candidate data verification rules to the user so that the user can select the appropriate target data verification rule from them.

[0194] Computing devices can be designed with various sorting rules to suit different application scenarios and configuration requirements. Sorting rules can be set based solely on popularity information, user preference information, or a combination of both for comprehensive sorting. Specifically, sorting rules include at least one of the following methods: Ranking based on popularity information: The computing device sorts each candidate data verification rule according to its popularity information. Popularity information may include one or more of the following: rule usage frequency, rule usage growth rate, and rule reuse rate. When the popularity information includes multiple indicators, the computing device can perform a weighted calculation on each indicator to obtain a comprehensive popularity score for each candidate data verification rule, and then sort the candidate data verification rules in descending order of comprehensive popularity score.

[0195] For example, weights of 0.4, 0.3, and 0.3 can be assigned to usage frequency, growth rate, and reuse rate, respectively. After calculating the weighted score for each rule, they are sorted. Rules with higher overall popularity scores indicate that they are widely used and popular in business practice, and therefore are displayed first.

[0196] Ranking based on user preference information: The computing device sorts the candidate data according to the degree of matching between each candidate data validation rule and the current user preference information. User preference information may include the user's historical selection records, user roles and business domains, and preferences of user groups with the same role. The computing device can calculate a matching score between each candidate data validation rule and the user's preferences based on the user preference information.

[0197] For example, rules frequently selected in a user's history are given higher matching scores; rules related to the user's business area receive additional matching scores. Rules with higher matching scores indicate that they better meet the user's personalized needs and are therefore displayed first.

[0198] Ranking based on comprehensive scores: The computing device integrates popularity information and user preference information to calculate a comprehensive score for each candidate data validation rule. The comprehensive score can be calculated by weighted summation of popularity score and preference matching score.

[0199] For example, the weight of popularity information can be set to 0.5, and the weight of user preference information can be set to 0.5. After calculating the comprehensive score of each candidate data validation rule, they can be sorted in descending order. The weights can be dynamically adjusted according to the actual application scenario. For example, for new users (with less historical preference information), the weight of popularity information can be appropriately increased, and for old users (with rich historical preference information), the weight of user preference information can be appropriately increased.

[0200] The computing device displays the sorted candidate data validation rules to the user in a list or other visual format. During the display, the candidate data validation rules can also be grouped according to their composition (i.e., whether they belong to the first or second sub-rule set) to help users more clearly identify different types of rules.

[0201] In one feasible approach, the computing device can divide candidate data validation rules into groups of combined rules and groups of atomic rules for separate display. The combined rule group displays rules composed of multiple atomic rules, while the atomic rule group displays individual atomic rules. This grouped display helps users quickly locate the rule type they need.

[0202] In another possible approach, the computing device can visually present the order of rules in the display list using methods such as sorting numbers, highlighting, or special identifiers. For example, rules that appear earlier in the list can be highlighted using bold font or a different background color.

[0203] Each displayed candidate data validation rule should include at least the rule name, rule identifier, and applicable business type. For combined rules, a list of its constituent atomic rules can also be displayed; for atomic rules, their parameter configuration options can be displayed. Furthermore, rule popularity metrics (such as usage frequency and reuse rate) or user preference matching information can be displayed to provide users with a reference for selection.

[0204] In another possible approach, while displaying the list, the computing device can provide filtering and search functions, allowing users to further narrow down their selection based on criteria such as rule name, rule type, and applicable business type, thereby improving the efficiency of rule search.

[0205] Through the aforementioned sorting and display mechanism, computing devices can prioritize presenting data validation rules that best meet business needs and user preferences to users, reducing the workload of searching and filtering through massive amounts of rules and improving the efficiency of rule configuration and user experience. At the same time, grouping combined rules and atomic rules provides users with flexible rule selection methods; they can directly use existing combined rules or create their own atomic rules to meet personalized needs.

[0206] S505. In response to a selection operation among multiple candidate data verification rules displayed in a sorted manner, the computing device determines the candidate data verification rule selected by the selection operation as the target data verification rule.

[0207] After displaying multiple sorted candidate data verification rules to the user, the computing device needs to receive and respond to the user's selection operation, and determine the rule actually selected by the user as the final target data verification rule for subsequent verification of front-end business data and back-end business data.

[0208] Optionally, the above selection operation may include at least one of the following: clicking to select, checking the box, dragging to select, and double-clicking to confirm.

[0209] In one feasible approach, if a user selects a combined rule from the first set of sub-rules, such as a personal customer-contact number combination rule, the computing device can directly determine this combined rule as the target data verification rule. This combined rule itself already contains combinations and logical arrangements of multiple atomic rules and can be directly used for subsequent verification file generation.

[0210] In another possible implementation, if the user selects an atomic rule from the second set of sub-rules, such as a non-empty verification atomic rule, the computing device directly identifies that atomic rule as the target data verification rule. This atomic rule is suitable for simple, single-dimensional verification scenarios.

[0211] In another possible implementation, if the user selects multiple atomic rules from the second set of sub-rules, such as simultaneously selecting three atomic rules: non-empty verification, mobile phone number format verification, and enumeration value verification, the computing device can logically arrange the selected atomic rules according to the user's arrangement order or the logical relationship specified by the user, generate a new combined rule, and then determine the newly generated combined rule as the target data verification rule.

[0212] For example, if a user prioritizes NOT NULL checks, followed by phone number format checks, and then enumeration value checks, the computing device will arrange the three atomic rules in this order to generate a combination rule applicable to the phone number field.

[0213] In another possible implementation, if the user selects both combination rules and atomic rules—for example, selecting a sales order-amount combination rule and additionally selecting a greater-than-threshold verification atomic rule—the computing device can merge and orchestrate the combination rule and atomic rules to generate a new combination rule, which is then designated as the target data verification rule. During the merging and orchestration process, it is necessary to check for logical conflicts between rules and adjust them according to a preset conflict handling mechanism.

[0214] After completing the rule selection, users can officially confirm the selected rule as the target data verification rule by clicking the Confirm, Next, or Apply buttons.

[0215] For certain data validation rules that require parameter configuration, the computing device can also provide a parameter configuration interface after the user selects the rule, allowing the user to set the specific parameters of the rule.

[0216] For example, for atomic rules that validate numerical ranges, users can configure minimum and maximum value parameters. For atomic rules that validate enumerated values, users can configure the set of allowed enumerated values. For atomic rules that validate regular expression matching, users can enter or select a preset regular expression template.

[0217] After the user completes the parameter configuration, the computing device will determine the rule with the specific parameter configuration as the target data verification rule and use these parameters in the subsequent verification file generation.

[0218] Through the above mechanism, the computing device can flexibly respond to the user's selection of candidate data verification rules, determine the rule actually selected by the user as the target data verification rule, and provide accurate rule basis for subsequent data verification.

[0219] The following detailed description, with reference to the accompanying drawings, illustrates the process of verifying the target data verification rules in the embodiments of this application.

[0220] In some embodiments, such as Figure 6 As shown, when there are multiple target data verification rules, the method by which the computing device verifies the front-end business data and back-end business data requested for verification in the data verification request according to the target data verification rules specifically includes: S601. The computing device arranges the data verification order of multiple target data verification rules according to the data verification logic of each target data verification rule in the multiple target data verification rules.

[0221] When there are multiple target data validation rules, these rules may include multiple atomic rules, multiple combined rules, or a mixture of atomic and combined rules. There are logical dependencies or differences in execution priority between different rules. Therefore, it is necessary to arrange the data validation order of multiple rules reasonably according to a preset orchestration strategy to ensure the logical correctness and execution efficiency of the validation process.

[0222] In one feasible approach, the computing device arranges the verification order of multiple target data verification rules according to the following criteria: Rule Type Priority: Set a preset priority order based on the rule type. For example, you can set existence checks (such as NOT NULL checks) to have the highest priority, type checks (such as numeric and string types) to have the next highest priority, format checks (such as regular expressions and enumeration values) to have the next lowest priority, and business logic checks (such as numeric range checks and cross-field checks) to have the lowest priority. The computing device arranges the rules in descending order of priority.

[0223] Rule dependencies: The computing device can predefine a dependency graph between rules, identifying which rules' execution depends on the passage of other rules. For example, a match validation of unit price * quantity depends on format validation rules for the unit price and quantity fields. The computing device determines the execution order based on these dependencies: dependent rules are executed first, followed by rules that depend on other rules.

[0224] Rule execution overhead: The computing device can calculate the average execution time or resource consumption of each rule, and arrange rules with low execution overhead at the beginning and rules with high execution overhead at the end to quickly filter abnormal data and reduce unnecessary overhead.

[0225] User-specified order: When users select multiple atomic rules to combine through the visual interface, they can manually specify the execution order of the rules. The computing device prioritizes the user-specified order for orchestration; if the user does not specify an order, the default orchestration strategy is used.

[0226] Preset order within a combination rule: For a user-selected combination rule, its internal arrangement already includes a preset order of atomic rules. When orchestrating the overall rules, the computing device treats the combination rule as a whole and determines the overall execution position of the combination rule according to its dependencies on external rules, while the execution order within the combination rule remains unchanged.

[0227] S602. The computing device verifies the front-end business data and the back-end business data according to the multiple target data verification rules arranged in the program.

[0228] In some embodiments, the computing device verifies front-end business data and back-end business data according to multiple orchestrated target data verification rules, including: The computing device performs logical mutual exclusion verification on multiple arranged target data verification rules according to preset logical mutual exclusion conditions.

[0229] If the logical mutual exclusion verification of the multiple target data verification rules after orchestration passes, the computing device verifies the front-end business data and the back-end business data according to the multiple target data verification rules after orchestration.

[0230] After orchestrating multiple target data validation rules, the computing device needs to perform compliance verification on the orchestrated rules to ensure that the rules themselves conform to logical specifications, business attribute requirements, and preset standards before applying the rules to actual data validation. Compliance verification is divided into two stages: configuration layer verification and release layer verification, and a complete compliance audit log is retained after the rules take effect.

[0231] During rule generation or configuration, the computing device performs configuration-level verification on the rules for multiple orchestrated target data in real time. Configuration-level verification includes two aspects: logical compliance verification and business attribute compliance verification.

[0232] Logical compliance verification refers to checking the logical consistency of the rules themselves. The computing device performs logical mutual exclusion verification on multiple compiled target data verification rules based on preset logical mutual exclusion conditions. Logical mutual exclusion conditions are used to determine whether there are logical contradictions between different data verification rules. For example, mandatory field verification is mutually exclusive with non-mandatory field verification; numerical ranges between 1-10 are mutually exclusive with numerical ranges between 20-30; and enumeration value sets {red, blue} are mutually exclusive with enumeration value sets {green, yellow} (if applied to the same field). If logical mutual exclusion exists among the compiled target data verification rules, the computing device determines that the logical compliance verification has failed and immediately generates a prompt message, displaying a specific problem description and correction suggestions to the user. After the user adjusts the rules according to the prompt message, the computing device re-verifies until the logical compliance verification passes.

[0233] Business attribute compliance verification refers to checking whether the rules match the metadata definition of the target business object. The computing device verifies, based on the metadata of the target business object, whether the orchestrated multiple target data verification rules are applicable to the data type, constraint range, and business semantics of the business attribute. For example, if the data type of the target business attribute is an enumeration type, and the orchestrated rules include numerical range verification rules, then the business attribute compliance verification is deemed to have failed. Similarly, the computing device immediately prompts specific issues and provides correction suggestions, guiding the user to adjust the rules.

[0234] After the configuration layer verification passes, the orchestrated verification rules for multiple target data enter the release process.

[0235] After the rules are configured and the release process begins, the computing device performs release-level verification on the orchestrated target data validation rules. Release-level verification primarily involves compliance checks, specifically verifying whether the rule content conforms to preset regulations, industry standards, and internal company requirements.

[0236] If the publishing layer verification fails, the computing device will prevent the target data verification rules from being published to the client and server, and will display the relevant supporting documentation and explain the specific reasons for the non-compliance to the user. The user must adjust the rules according to the supporting documentation and guidance, and then resubmit for verification until the publishing layer verification passes.

[0237] After the release layer verification is passed, the orchestrated multiple target data verification rules are determined as the final usable verification rules, which can be deployed to the unified verification engine for actual verification of front-end business data and back-end business data.

[0238] In one feasible approach, after both configuration layer and release layer validations pass, the computing device validates the front-end and back-end business data according to multiple orchestrated target data validation rules. The specific execution process includes: First, the computing device generates a standardized data verification file based on the orchestrated multiple target data verification rules. This file uses the SHACL format or other common rule description language and fully records the execution order, verification logic, and parameter configuration of the rules.

[0239] Next, the computing device sends the standardized data validation file to both the client and the server via the adaptation layer. For the client, the adaptation layer converts the file into a lightweight format (such as JSON) and loads it into the client's rule parser; for the server, the adaptation layer loads the file into the unified validation engine.

[0240] Then, when a user inputs or submits front-end business data, the client sequentially calls the corresponding atomic rules to validate the data according to the orchestration order. If the data fails a validation, the client immediately displays an error message and prevents the data submission. If all validations pass, the client submits the data to the server.

[0241] After receiving the backend business data submitted by the client, the unified validation engine validates the data in the same orchestration order. If the data fails any validation, the server returns an error message to the client and refuses to write the data to the database or proceed to subsequent business processes. If all validations pass, the server allows the data to continue processing.

[0242] After the rules are published and take effect, the computing devices automatically retain a log of the entire compliance verification process. The compliance audit log includes the following information: operation records during rule configuration, verification time and results of configuration-level verification, verification time and results of publication-level verification, rule version information, user adjustments to the rules, and verification records of front-end and back-end business data after the rules take effect. These logs can be used for subsequent auditing and traceability, meeting the auditability requirements of industry regulations and internal management for the data verification process.

[0243] Through the aforementioned phased compliance verification mechanism, the computing equipment ensures that the orchestrated verification rules for multiple target data comply with regulations at the logical, business attribute, and regulatory requirements levels, thereby guaranteeing the accuracy and compliance of subsequent data verification. Meanwhile, complete audit logs provide a reliable basis for issue tracing and accountability.

[0244] In an exemplary embodiment, this application also provides a data verification device. This data verification device can be a computing device that performs the aforementioned data verification method, or it can be a processor within the computing device. The data verification device may include one or more functional modules for implementing the data verification method of the above method embodiments.

[0245] This application also provides a computing device. Figure 7This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Figure 7 As shown, the computing device 100 includes: one or more memories 120, one or more processors 110, a communication bus 140, and a communication interface 130. The processors 110 and memories 120 are connected via the communication bus 140; the one or more memories 120 are used to store computer program code, which includes computer instructions; when the one or more processors 110 execute the computer instructions, the computing device 100 performs the data verification method provided in this embodiment.

[0246] Optionally, the memory 120 may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. The embodiments of this application do not impose any limitations on this.

[0247] The processor 110 may be a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof, and the embodiments of this application do not impose any limitations on this.

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

[0249] Communication interface 130 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 (WLAN), etc.

[0250] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0251] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; for example, the related hardware can be a processor of a computing device. The program instructions can be stored in the above-mentioned computer-readable storage medium, and when executed, the processes of the above method embodiments can be implemented. The computer-readable storage medium can be memory. The above-mentioned computer-readable storage medium can also be an external storage device, such as a hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Further, the above-mentioned computer-readable storage medium can include both memory and external storage devices. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program instructions and other programs and data required by the above-mentioned data verification method.

[0252] This application also provides a computer program product comprising a computer program that, when run on a computing device, causes the computing device to execute any of the data verification methods provided in the above embodiments.

[0253] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0254] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

[0255] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations 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 verification method, characterized in that, include: In response to a received data verification request, obtain the business type of the metadata of the business object involved in the data verification request; From a pre-built data validation rule library, a target data validation rule matching the business type of the metadata is obtained; the data validation rule library includes multiple data validation rules and the applicable business type of each data validation rule; the multiple data validation rules include the target data validation rule; each data validation rule includes at least one atomic rule; the atomic rule is used to represent independently encapsulated data validation logic; the applicable business type of the target data validation rule and the business type of the metadata satisfy the business type matching condition; According to the target data verification rules, the front-end business data and back-end business data requested for verification by the data verification request are verified; the front-end business data and the back-end business data have the same business meaning but are located on different ends.

2. The method according to claim 1, characterized in that, The business matching conditions include: the business scenario similarity between the applicable business type of the data verification rule and the business scenario of the metadata is greater than a preset scenario similarity, and / or, the semantic similarity between the semantic features of the applicable business type of the data verification rule and the semantic features of the business type of the metadata is greater than a preset semantic similarity.

3. The method according to claim 1 or 2, characterized in that, The step of obtaining target data verification rules that match the business type of the metadata from a pre-built data verification rule library includes: The data verification rules in the data verification rule library that meet the business matching conditions with the business type of the metadata are identified as candidate data verification rules. The data verification rules that meet the popularity criteria among the candidate data verification rules are determined as the target data verification rules.

4. The method according to claim 3, characterized in that, The popularity conditions include at least one of the following: the rule usage frequency is greater than the preset frequency, the rule usage growth rate is greater than the preset growth rate, and the rule reuse rate under different business objects is greater than the preset reuse rate.

5. The method according to claim 3 or 4, characterized in that, The candidate data verification rules include a first sub-rule set and a second sub-rule set; the candidate data verification rules in the first sub-rule set are combination rules composed of multiple atomic rules; the candidate data verification rules in the second sub-rule set are single atomic rules.

6. The method according to any one of claims 3-5, characterized in that, When there are multiple candidate data validation rules, the method further includes: Obtain popularity information and / or user preference information for each candidate data validation rule from multiple candidate data validation rules; Based on the popularity information and / or user preference information of each candidate data verification rule, the multiple candidate data verification rules are sorted and displayed. In response to a selection operation among multiple candidate data validation rules displayed in a sorted manner, the candidate data validation rule selected by the selection operation is determined as the target data validation rule.

7. The method according to any one of claims 1-6, characterized in that, When there are multiple target data verification rules, the step of verifying the front-end business data and back-end business data requested for verification by the data verification request according to the target data verification rules includes: The data verification order of the multiple target data verification rules is arranged according to the data verification logic of each target data verification rule. The front-end business data and the back-end business data are verified according to the multiple target data verification rules arranged in the system.

8. The method according to claim 7, characterized in that, The step of validating the front-end business data and the back-end business data according to the multiple configured target data validation rules includes: Based on preset logical mutual exclusion conditions, the multiple target data verification rules after arrangement are logically mutually exclusive verified. If the logical mutual exclusion verification of the multiple target data verification rules after the arrangement is passed, the front-end business data and the back-end business data are verified according to the multiple target data verification rules after the arrangement.

9. The method according to any one of claims 1-8, characterized in that, The step of verifying the front-end business data and back-end business data requested for verification in the data verification request according to the target data verification rules includes: Generate a data verification file in the target format according to the target data verification rules; The data verification file is added to the data verification request, and data verification requests carrying the data verification file are sent to the client storing the front-end business data and the server storing the back-end business data, respectively, to request the client to call a data verifier adapted to the target format to verify the front-end business data, and to request the server to call a data verifier adapted to the target format to verify the back-end business data.

10. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory. The memory is used to store computer instructions; The computer instructions are loaded and executed by the processor to enable the computing device to perform the method as described in any one of claims 1-9.

Images