Data verification method implemented based on user-defined plug-in mode

Abstract

The invention provides a data verification method realized based on a user-defined plug-in mode, which can more flexibly configure verification rules for fields of each piece of basic data and reduce the code quantity of a system. The method comprises the following steps: pre-storing implementation logic of verification rules in a system based on class names and method names in a form of setting a plug-in, and storing a corresponding relationship between each verification rule and a verification method corresponding to the verification rule in a rule table; all the verification rules in the available state in the rule table are displayed through the rule management window, and a configuration administrator is allowed to flexibly select the verification rules required by the fields through the rule management window according to actual requirements; according to the method, the relation between each field and the corresponding verification rule and the implementation logic of the verification rule can be established through the form relation, and the field, the verification rule and the verification method do not need to be bound in the code.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a data verification method implemented based on a custom plug-in mode. Background Art

[0002] For example, the two systems disclosed in the two patent documents with application numbers CN202011474245.X and CN202011511579.X are data management systems built and maintained by our company. The system needs to collect basic data reported by enterprises and institutions every day, and then make subsequent analysis and statistics based on these uploaded data. Usually, each type of basic data that needs to be uploaded will include multiple fields, and each field needs to verify the compliance of the data when uploading, and the fields that cannot pass the verification are not allowed to be uploaded. For example, the basic data that needs to be uploaded is: double public administrative penalties, and the corresponding fields that need to be verified include: administrative counterpart name, administrative counterpart code, legal representative name, administrative penalty decision document number, penalty name, penalty category, penalty reason, penalty decision date, penalty deadline, etc. Common data verification methods include: regular expression verification, enumeration value verification, value range verification, name verification, date format verification, maximum value verification, ID card verification, etc. These verification methods are all implemented by very mature technologies in the prior art.

[0003] In actual applications, some fields of basic data will change for various reasons. For example, the ID number changes from 16 to 18 digits, or for example: the unique identification code of an enterprise or institution changes from the organization code to the unified social credit code. Once these changes occur, the verification methods related to the associated fields must be adjusted synchronously. Or if the latest relevant regulations require adding a few more fields to the "double public disclosure of administrative penalties", then the system needs to add new fields and related verification rules. It is even possible that the "double public disclosure of administrative penalties" will be deleted and changed to other types of basic data. Once these changes occur, the system needs to promptly and synchronously modify the data entry related modules.

[0004] The system structure of the existing data management platform is as follows: Figure 1 As shown in the figure, the terminal user accesses the data entry module page of the data platform based on the PC or mobile phone. When the user logs in, the page that opens is the data entry module page corresponding to the user's ID. Users with different permissions or different types of users will correspond to different data entry pages. In order to ensure that users can enter data accurately, according to relevant changes, the configuration administrator will configure the data entry page corresponding to each user based on the configuration module. The configuration content includes: the basic data that this user needs to enter, the fields included in the basic data, and the verification rules required for each field.

[0005] In the existing Java-based data management platform, each verification rule is implemented based on a method. The technicians create corresponding verification methods for each verification rule one by one, and bind the fields to the corresponding verification rules. After the end user uploads the data, the system automatically calls the corresponding verification method to run the data verification process based on the correspondence between the fields and the verification rules. In this way, each field of each basic data will be bound to its corresponding verification rules and verification methods. However, every time the verification rules of certain fields change, the relevant codes of the verification methods need to be modified one by one, which not only requires a lot of manpower, but also the same verification rules between different fields cannot be reused, which can easily cause code redundancy. Summary of the invention

[0006] In order to solve the problem that when the data verification rules in the data management system implemented based on Java in the prior art change, the synchronous modification of the verification method requires a lot of manpower, and the same verification rules between different fields cannot be reused, the present invention provides a data verification method implemented based on a custom plug-in, which can more flexibly configure the verification rules for each field of basic data and reduce the amount of system code.

[0007] The technical solution of the present invention is as follows: a data verification method implemented based on a custom plug-in, characterized in that it includes the following steps: S1: Keep the implementation logic of all validation rules in the form of methods in the plug-in file; Create a plug-in configuration page for configuring relevant parameters of the plug-in file; Plugin file parameters include: rule name, class name and method name; The rule name: specify a unique name for each verification rule; The class name is used to store the plug-in file where the method for implementing the verification rule is located, and the storage path of the plug-in file in the system source code, separated by "."; The method name is used to distinguish the implementation method of each verification rule stored in the same plug-in file; S2: Create a form for all rules, named: rule table DP_RULE, to record the verification rule contents corresponding to all fields; the contents set on the plug-in page are saved in the rule table; The fields in the rule table DP_RULE include: Rule name RULENAME, class name PLUGIN_CLASS_NAME, method name PLUGIN_METHOD_NAME, associated field parameter PARAM_COLUMN and prompt message MSG; S3: Set up a separate data configuration page for each type of basic data that needs to be uploaded; The data configuration page includes: a basic information configuration page and a collection information configuration page; The basic information configuration page includes: all fields included in the basic data; The collection information configuration page includes: a verification rule selection module, which is used to configure all fields that need to be verified and the verification rules corresponding to each field; S4: Build rule management window; Displaying all available validation rules for all states configured in the rule table in the rule management window, and opening the rule management window when the validation rule for each field is selected in the validation rule selection module; The rule management window includes all the verification rules, and each of the verification rules corresponds to a selection box; The selection box in the rule management window is a selection box that supports multiple selections, and allows each field to select more than or equal to 1 verification rule at the same time; S5: Build forms and relationships between different types of data; Build the catalog table DP_LOGIC_TABLE to record the basic information of all basic data. One record in the catalog table corresponds to one basic data. Build the field table DP_LOGIC_COLUMN to store the contents of all fields included in all basic data; at the same time, record the corresponding relationship between each field and the basic data; each record in the field configuration information data table corresponds to one field; Construct a field rule relationship data table DP_COLUMN_RULE to record the corresponding relationship between each field in the field table and the corresponding verification rule in the rule table; Construct the relational data table DP_LOGIC_TABLE_DEPT between the directory and the user, and record all the basic data that each terminal user needs to submit by recording the corresponding relationship between each basic data and the terminal user; S6: When it is necessary to configure the basic data, in the collection information configuration page, select relevant verification rules for the fields to be configured based on the rule management window; the configured association information is stored in the field rule relationship data table; S7: After all configuration work is completed, a data upload template is generated for each terminal user to complete this configuration operation; The data upload template includes: user code, user full name, directory code, directory name, field name, and field comment; Each of the data upload templates corresponds to one type of basic data; in the data upload template, each row includes all the fields that need to be checked for the basic data uploaded by the same terminal user; S8: After receiving the data imported by the user based on the data upload template, the system performs verification, which specifically includes the following steps: a1: read the fields to be checked one by one, recorded as: fields to be checked; a2: Find the name of the corresponding verification rule based on the field to be verified; a3: Based on the rule table, find the corresponding class name and method name according to the rule name, which are recorded as: the class name to be confirmed and the method name to be confirmed respectively; obtain the Class class object corresponding to the class name to be confirmed through the Class class method forName, and find the plug-in file where the verification method corresponding to the field to be verified is located; a4: Use getMethod to bring in the specific value of the method name to be confirmed, and obtain the implementation logic of the verification method corresponding to the field to be verified in the plug-in file, which is recorded as: Method object; a5: Reflect through the invoke method of the Method object, bring the field to be checked into the corresponding verification method to complete data verification and obtain the final verification result.

[0008] It is further characterized by: Step S1 also includes the following steps: Construct a field rule management page, which includes: a verification rule content configuration page, which is a configuration page for the specific content of different types of verification rules; in the verification rule content configuration page, configure specific implementation logic for each verification rule; The plug-in configuration page is set as a subpage of the field rule management page, and plug-in file related parameters are configured for each verification rule; and according to the parameters configured in the plug-in file, the implementation logic configured in the verification rule content configuration page is saved in the plug-in file under the path specified by the class name with the method name in the plug-in file parameter; All verification rule information configured in the field rule management page is stored in the rule table; The construction of the plugin file meets the following rules: The validation rules for different fields of the same basic data can be saved in different plug-in files; The validation rules corresponding to multiple fields can be saved in the same plug-in file; The same plug-in file allows you to save multiple validation rules corresponding to basic data; The plug-in file parameters also include: associated field parameters and prompt messages; When the condition for starting the verification rule of the field to be verified is a composite condition and it is also necessary to refer to the verification results of other fields, the relevant fields are configured in the relevant field parameters; The prompt message is the prompt information returned to the user when the field verification fails, which is used to tell the user the cause of the error; The collection information configuration page also includes: a user designation module, which is used to designate all terminal users who need to upload the basic data; and to complete the addition or modification of user information through the user information configuration page; In step S5, the following steps need to be performed: For each basic data record in the directory table, read the corresponding field table content, and create a physical table for each basic data; The physical table is used to store the data content actually uploaded by the terminal user, which includes: the physical table primary key, user code, user full name, field name, and field comment; Before the step S6 is implemented, the following steps are first implemented: According to specific business needs, based on the field rule management page, create or modify verification rules and store them in the rule table; In step S6, the configuration operations include: adding, deleting and modifying.

[0009] The present application provides a data verification method implemented in a custom plug-in manner. By setting the plug-in, the implementation logic of the verification rule is pre-saved in the system based on the class name and method name, and the corresponding relationship between each verification rule and the verification method corresponding to the verification rule is saved in the rule table; the verification rules in all available states in the rule table are displayed through the rule management window, allowing the configuration administrator to flexibly select the verification rules required by the field through the rule management window according to actual needs. The present application can establish a connection between each field and its corresponding verification rule, as well as the implementation logic of the verification rule, through a form relationship, without binding the field, verification rule and verification method in the code. Compared with the existing method, it is more flexible and can realize the reuse of the same verification rule when configuring different fields of different basic data, thereby reducing the complexity of the system code. After the terminal user uploads the data, after obtaining the field to be checked, the verification rule corresponding to the field to be checked is found based on the relationship between the forms, and then based on the plug-in file parameters corresponding to the verification rule, the implementation logic of the verification rule in the plug-in file is found. Based on the class reflection mechanism of Java, the field to be checked is brought into the corresponding verification method to complete the verification process. This method does not need to know the verification rules set by the configuration administrator for each field in advance, and can still ensure that the verification of the field is completed accurately. Compared with the existing implementation method of writing the method for verifying the rules first in the code associated with the field, this method is more suitable for application scenarios where fields and field verification rules change frequently. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 It is a schematic diagram of the system structure of the general data management platform of the prior art; Figure 2 This is a schematic diagram of the data form relationship in this application; Figure 3 This is a schematic diagram of the structure of the configuration module in this application; Figure 4 A flowchart for configuring plugin rules; Figure 5 An example of the field rule management page; Figure 6 Example of configuration page for validation rule content; Figure 7 An example of configuring a page for collection information; Figure 8 This is an example of the rule management window. DETAILED DESCRIPTION

[0011] like Figure 4 As shown, the present invention includes a data verification method implemented based on a custom plug-in, which includes the following steps.

[0012] S1: In this method, the implementation logic of all verification rules is maintained in the form of methods in the plugin file.

[0013] As Figure 3 shown, a field rule management page is constructed, which includes: a plugin configuration page and a verification rule content configuration page In the verification rule content configuration page, specific implementation logic is configured for each verification rule. For example, Figure 6 shown is an example of the configuration page for regular enumeration verification.

[0014] As Figure 5 shown, the plugin configuration page is set as a sub-page of the field rule management page, and relevant parameters of the plugin file are configured for each verification rule; and according to the parameters configured in the plugin file, the implementation logic configured in the verification rule content configuration page is saved in the plugin file at the path specified by the class name with the method name in the plugin file parameters.

[0015] In this application, a plugin file configuration page is created to configure relevant parameters of the plugin file; The plugin file parameters include: rule name RULENAME, class name PLUGIN_CLASS_NAME, method name PLUGIN_METHOD_NAME, associated field parameter PARAM_COLUMN, and prompt message MSG; Rule name: Specify a unique name for each verification rule; The class name is used to save the plugin file where the method for implementing the verification rule is located, as well as the storage path of the plugin file in the system source code, separated by "."; for example, if the class name is set to: com.udatech.common.util.RuleCheck, it means that the file path where this plugin will be inserted is the RuleCheck file in the util folder under the common folder under the udatech folder under the com folder.

[0016] The method name is used to distinguish the implementation methods of each verification rule saved in the same plugin file; for example: if the verification rule is written in the isContainChinese method in the RuleCheck file, then the method name is configured as: isContainChinese; When the condition for starting the verification rule of the field to be verified is related to other fields, the relevant fields are configured in the relevant field parameters; for example: normally, data containing the character "简" in the penalty document number (cf_wsh) is considered a summary penalty and is sent back as non-compliant data and cannot be reported. However, the following situations are exceptions: The name of the punishment agency (cfjg) contains "Jianyang" or "Mengjian", and there is only one "Jian" character in the document number (cf_wsh), and reporting is allowed.

[0017] For example, the name of the punishment agency: XX Bureau of Jianyang City, Sichuan Province; Punishment document number: Punishment Decision Letter (2024) Jian Character No. 000yyyyy; In this case, although it does not start with "Jian", since the punishment agency contains "Jianyang", reporting is also allowed. When configuring the verification rule for the field "Punishment Document Number cf_wsh", follow the following steps: b1: Write the verification method logic for the field "Punishment Document Number cf_wsh" in the RuleCheck file, and the method name is: wshMethod; In the specific implementation logic of wshMethod, it includes two parts: 1) Data containing the character "Jian" is considered a summary punishment and is sent back as non-compliant data; 2) The name of the punishment agency (cfjg) contains "Jianyang" or "Mengjian", and there is only one "Jian" character in the document number (cf_wsh), and reporting is allowed; b2: When configuring the plugin file parameters for cf_wsh, set the class name to: com.udatech.common.util.RuleCheck, the method name is configured as: wshMethod; the associated field parameter is set to: Name of the punishment agency: CF_CFJG; When specifically implementing the verification, if other names of punishment agencies need to be added, they can be directly added to the associated field parameters; if the verification of the punishment document number cf_wsh also needs to be associated with the verification of other fields, they can also be added to the associated field parameters in the same way. By setting the associated field parameters instead of writing these associated fields in the specific method logic, it is to ensure that when the field name changes, users can flexibly modify only the associated field parameters to handle the change without having to modify the corresponding logic method code. Ensure that this method can be flexibly applied to scenarios where field changes are frequent.

[0018] The prompt message is the prompt information returned to the user when the field verification fails, which is used to tell the user the reason for the error.

[0019] Such as Figure 5 In the field rule management page shown, it includes: code verification, regular expression verification, enumeration set verification, and plugins. Among them, the plugin page is the plugin parameter configuration page; the code verification, regular expression verification, and enumeration set verification pages are the implementation logic configuration pages for each verification rule.

[0020] In practical applications, the validation rules for different fields of the same basic data are allowed to be saved in different plug-in files; the validation rules corresponding to multiple fields are allowed to be saved in the same plug-in file; the validation rules corresponding to multiple basic data are allowed to be saved in the same plug-in file, ensuring that this method is applicable to data management systems of various sizes.

[0021] S2: Create a form for all rules, named: Rule Table DP_RULE, to record the verification rule content corresponding to all fields; all verification rule information configured in the field rule management page including plug-in file related parameters are stored in the rule table DP_RULE; the content set on the plug-in page is also saved in the rule table.

[0022] The fields in the rule table DP_RULE include: Rule name RULENAME, class name PLUGIN_CLASS_NAME, method name PLUGIN_METHOD_NAME, associated field parameter PARAM_COLUMN and prompt message MSG.

[0023] S3: Set up a separate data configuration page for each type of basic data that needs to be uploaded; The data configuration page includes: basic information configuration page and collection information configuration page; The basic information configuration page includes: all fields included in the basic data; The collection information configuration page includes: a verification rule selection module, which is used to configure all fields that need to be verified and the verification rules corresponding to each field; the collection information configuration page also includes: a user specification module, which is used to specify all terminal users who need to upload this basic data; the addition or modification of user information is completed through the user information configuration page.

[0024] Configuration administrators can use the data configuration page to specify corresponding validation rules for all fields in each type of basic data, and can also specify all end users who need to upload this type of data for each basic data.

[0025] S4: Build rule management window; Display all available validation rules for all states configured in the rule table in the rule management window, and open the rule management window when selecting validation rules for each field in the validation rule selection module; The rule management window includes all the verification rules, and each verification rule corresponds to a selection box; The selection box in the rule management window supports multiple selections, allowing each field to have more than or equal to 1 validation rule selected at the same time.

[0026] like Figure 7 As shown in the figure, because the terminal user in this embodiment is a department, the "department" in the figure is the user-specified module. The verification rule selection module below includes: indicator name, indicator code, collection length, required, operation and annotation, which are used to configure the corresponding verification rules for each field, where the indicator name is the field name and the indicator code is the field code. A "rule" button is set in the "operation" behind each field to display the rule management window in a pop-up window, such as Figure 8 As shown, all available validation rules are displayed. Before each startup of the rule management window, the rule table is read first, and the latest rule table content is displayed in the current window. All validation rule changes can be dynamically displayed in all data configuration pages, which is especially suitable for application scenarios with a large number of basic data types.

[0027] This method connects the start ID to mark the associated field of the verification rule selected in the rule management window opened this time, ensuring that the associated information of the field and the verification rule can be accurately saved in the field table, and flexibly applies the rule window to a variety of basic data configuration scenarios with a small amount of code. Based on the rule management window, not only can the corresponding verification rule be flexibly selected for each field, but once the verification rule changes, only the relevant modifications need to be made in the verification rule configuration page, which can be directly reflected in the rule table, and then reflected in the trajectory information configuration page through the rule management window.

[0028] S5: Build a form and build relationships between different types of data; Figure 2 shown.

[0029] Build the directory table DP_LOGIC_TABLE to record the basic information of all basic data. One record in the directory table corresponds to one basic data. The directory table DP_LOGIC_TABLE includes: directory primary key, directory name and directory code.

[0030] Build the field table DP_LOGIC_COLUMN to store the contents of all fields included in all basic data; at the same time, record the corresponding relationship between each field and the basic data; each record in the field configuration information data table corresponds to one field; Construct the field rule relationship data table DP_COLUMN_RULE to record the correspondence between each field in the field table and the corresponding verification rule in the rule table; Construct the relational data table DP_LOGIC_TABLE_DEPT between the directory and the user, and record all the basic data that each terminal user needs to submit by recording the corresponding relationship between each basic data and the terminal user; Create a user table for all end users to record all end user information; user table: user table primary key, user full name, user code; Build a directory user correspondence table, establish a relationship between the user table and the directory table, and record all the basic data that each terminal user needs to submit; the directory user correspondence table includes: the primary key of the relationship table, the primary key of the user table, and the primary key of the directory; For each basic data record in the directory table, read the corresponding field table content and create a physical table for each basic data; The physical table is used to store the data content actually uploaded by the terminal user, which includes: physical table primary key, user code, user full name, field name, and field comment.

[0031] For example, if the basic data to be verified is administrative penalties, the field to be verified is the penalty category in the administrative penalty table. Configure the administrative penalty data table here, then check the penalty category field in the table, and finally click the rule configuration in the operation column, select the rule name that has been defined for the field in the field rule management page, and click Save.

[0032] The configured table information is stored in the DP_LOGIC_TABLE table, the field directory configuration information is stored in the DP_LOGIC_COLUMN table, and the relationship between the field and the rule is saved in the field rule relationship table DP_COLUMN_RULE table. In the directory and user (department) relationship table DP_LOGIC_TABLE_DEPT table, it is searched whether there is data. If there is, its status field STATUS is changed to deleted, and then a new piece of data is saved in the DP_LOGIC_TABLE_DEPT table. In this application, a connection is established between the basic data, terminal users, fields, and verification rules through a form. If any of the data changes, just modify the changed data in the corresponding configuration page, which is especially suitable for application scenarios where data changes frequently.

[0033] S6: Create or modify validation rules based on the field rule management page according to specific business needs and store them in the rule table; When it is necessary to configure the basic data, in the collection information configuration page, select the relevant verification rules for the fields to be configured based on the rule management window; the configured associated information is stored in the field rule relationship data table.

[0034] In specific implementation, configuration operations include: adding, deleting and modifying.

[0035] S7: After all configuration work is completed, a data upload template is generated for each terminal user to complete this configuration operation; The data upload template includes: user code, user full name, directory code, directory name, field name, and field comment; Each data upload template corresponds to one kind of basic data; in the data upload template, each row includes all the fields that need to be checked of the basic data uploaded by the same terminal user.

[0036] After the end user imports data into the system based on the data upload template, because each data upload template corresponds to a basic data, but the data uploaded by the user only includes the field name, and the corresponding rules cannot be found directly from the field name, because the field names in the field table may be repeated. Therefore, the system needs to find the corresponding rules for each field based on the field's unique identifier field table primary key. The specific process is as follows: SS1: The system jointly queries DP_LOGIC_TABLE_DEPT and DP_LOGIC_TABLE based on the access ID of the terminal user and the directory CODE in the imported template, and can obtain the directory primary key of the DP_LOGIC_TABLE table. Then: the corresponding DP_LOGIC_TABLE directory table can be accessed; SS2: According to the "catalog primary key" in the DP_LOGIC_TABLE catalog table, find all the field names corresponding to the same "catalog primary key" from the DP_LOGIC_COLUMN field table; because the same catalog primary key may correspond to multiple field names, take out all the field names and collide them with the field names in the data upload template to find the field table primary keys corresponding to all the field names included in the data upload template; SS3: Access the field rule relationship table DP_COLUMN_RULE according to the field table primary key, and find the rule table primary key of the verification rule corresponding to each field; SS4: Based on the primary key of the rule table, obtain the rule corresponding to each field from the rule table DP_RULE.

[0037] S8: After receiving the data imported by the user based on the data upload template, the system performs verification, which specifically includes the following steps: a1: read the fields to be checked one by one, recorded as: fields to be checked; a2: Based on steps SS1 to SS4, find the rule name of the corresponding verification rule through the field to be verified; a3: Based on the rule table, find the corresponding class name and method name according to the rule name, which are recorded as: the class name to be confirmed and the method name to be confirmed respectively; obtain the Class class object corresponding to the class name to be confirmed through the Class class method forName, and find the plug-in file where the verification method corresponding to the field to be verified is located; a4: Use getMethod to bring in the specific value of the method name to be confirmed, and obtain the implementation logic of the verification method corresponding to the field to be verified in the plug-in file, which is recorded as: Method object; a5: Through the invoke method of the Method object, the field to be checked is brought into the corresponding verification method to complete the data verification and obtain the final verification result. If the verification fails, the prompt message MSG field value of the rule configuration in the rule table DP_RULE is returned.

[0038] To implement data verification based on this method, for example, to verify whether a number is greater than or equal to 100, follow the steps below.

[0039] (1) Figure 6 In the validation rule configuration page shown, write specific validation logic. If more complex validation can only be implemented through coding, there is no need to use Figure 6 Instead of using the validation rule configuration page shown in the figure, you can directly write the logic of the method in code.

[0040] (2) Figure 5 In the field rule management page shown, configure: The rule name is: Number greater than or equal to 100; The class name is configured as: com.udatech.common.util.RuleCheckNew; The method name is configured as: numberOverHundred; The associated field parameter does not need to be limited to a certain field at this time and can be left empty; The prompt message MSG is set to: "The value of this field is greater than or equal to 100 and will be considered as questionable data. Please contact the system administrator to report the data!" (3) Enter Figure 7 On the collection information configuration page shown, configure the corresponding verification rules for the fields.

[0041] The configured field is: the "Administrative Penalty Decision Document Number" field in the basic data "Administrative Penalty", which needs to be checked whether the number is greater than or equal to 100. Figure 7 and Figure 8 As shown, in the verification rule selection module, you can check the administrative penalty table, check the administrative penalty decision document number field, click the operation column to select "Rule", and select the rule name in the pop-up "Rule Management Window": the number is greater than or equal to 100. The rule configuration work for the field "Administrative Penalty Decision Document Number" is completed. Click Save to generate the data upload template corresponding to the basic data "Administrative Penalty" in real time.

[0042] The terminal user will use the latest data upload template to import data into the system. After the system receives the data uploaded by the terminal user, it will perform data verification: according to the relationship between the forms, find the rule corresponding to the "Administrative Penalty Decision Document Number" field; in the rule table, find the rule table primary key configured for the field, and then obtain the information configured for the rule: class name, method name, prompt information; perform reflection operations through the file path configured by the class name to obtain the class object of the class, and then obtain the corresponding rule verification method in the plug-in file through the configured method name numberOverHundred, and pass the field value in for verification; if the verification data is correct, it will be stored in the database, and if it is incorrect, an error message will be returned, and the configured prompt message: "The value of this field is greater than or equal to 100 and will be treated as questionable data. Please contact the system administrator to report this data!" will be returned to the user.

[0043] After using the technical solution of the present invention, corresponding verification rules are configured for any customized table and its fields, and the rules are in the form of plug-ins. The file path, class name, and method name of the plug-in file can be freely configured, and the plug-in verification rule code is applied to the configured fields for verification through the reflection mechanism of the Java class; this method can facilitate the system to verify the correctness of the reported data, making it more comprehensive, correct, and efficient. The plug-in can edit the verification rules by itself, so it can fully cover all scenarios that require data verification.

Claims

1. A data verification method based on a custom plug-in, characterized in that: It includes the following steps: S1: Keep the implementation logic of all validation rules in the form of methods in the plug-in file; Create a plug-in configuration page for configuring relevant parameters of the plug-in file; Plugin file parameters include: rule name, class name and method name; The rule name: specify a unique name for each verification rule; The class name is used to store the plug-in file where the method for implementing the verification rule is located, and the storage path of the plug-in file in the system source code, separated by "."; The method name is used to distinguish the implementation method of each verification rule stored in the same plug-in file; S2: Create a form for all rules, named: rule table DP_RULE, to record the verification rule contents corresponding to all fields; the contents set on the plug-in page are saved in the rule table; The fields in the rule table DP_RULE include: Rule name RULENAME, class name PLUGIN_CLASS_NAME, method name PLUGIN_METHOD_NAME, associated field parameter PARAM_COLUMN and prompt message MSG; S3: Set up a separate data configuration page for each type of basic data that needs to be uploaded; The data configuration page includes: a basic information configuration page and a collection information configuration page; The basic information configuration page includes: all fields included in the basic data; The collection information configuration page includes: a verification rule selection module, which is used to configure all fields that need to be verified and the verification rules corresponding to each field; S4: Build rule management window; Displaying all available validation rules for all states configured in the rule table in the rule management window, and opening the rule management window when the validation rule for each field is selected in the validation rule selection module; The rule management window includes all the verification rules, and each of the verification rules corresponds to a selection box; The selection box in the rule management window is a selection box that supports multiple selections, and allows each field to select more than or equal to 1 verification rule at the same time; S5: Build forms and relationships between different types of data; Build the catalog table DP_LOGIC_TABLE to record the basic information of all basic data. One record in the catalog table corresponds to one basic data. Construct the field table DP_LOGIC_COLUMN to store the contents of all fields included in all basic data; at the same time, record the corresponding relationship between each field and the basic data; each record in the field configuration information data table corresponds to one field; Construct a field rule relationship data table DP_COLUMN_RULE to record the corresponding relationship between each field in the field table and the corresponding verification rule in the rule table; Construct the relational data table DP_LOGIC_TABLE_DEPT between the directory and the user, and record all the basic data that each terminal user needs to submit by recording the corresponding relationship between each basic data and the terminal user; S6: When it is necessary to configure the basic data, in the collection information configuration page, select relevant verification rules for the fields to be configured based on the rule management window; the configured association information is stored in the field rule relationship data table; S7: After all configuration work is completed, a data upload template is generated for each terminal user to complete this configuration operation; The data upload template includes: user code, user full name, directory code, directory name, field name, and field comment; Each of the data upload templates corresponds to one type of basic data; in the data upload template, each row includes all the fields that need to be checked for the basic data uploaded by the same terminal user; S8: After receiving the data imported by the user based on the data upload template, the system performs verification, which specifically includes the following steps: a1: read the fields to be checked one by one, recorded as: fields to be checked; a2: Find the name of the corresponding verification rule based on the field to be verified; a3: Based on the rule table, find the corresponding class name and method name according to the rule name, which are recorded as: the class name to be confirmed and the method name to be confirmed respectively; obtain the Class class object corresponding to the class name to be confirmed through the Class class method forName, and find the plug-in file where the verification method corresponding to the field to be verified is located; a4: Use getMethod to bring in the specific value of the method name to be confirmed, and obtain the implementation logic of the verification method corresponding to the field to be verified in the plug-in file, which is recorded as: Method object; a5: Reflect through the invoke method of the Method object, bring the field to be checked into the corresponding verification method to complete data verification and obtain the final verification result.

2. According to claim 1, a data verification method based on a custom plug-in is characterized in that: Step S1 also includes the following steps: Construct a field rule management page, which includes: a verification rule content configuration page, which is a configuration page for the specific content of different types of verification rules; in the verification rule content configuration page, configure specific implementation logic for each verification rule; The plug-in configuration page is set as a subpage of the field rule management page, and plug-in file related parameters are configured for each verification rule; and according to the parameters configured in the plug-in file, the implementation logic configured in the verification rule content configuration page is saved in the plug-in file under the path specified by the class name with the method name in the plug-in file parameter; All verification rule information configured in the field rule management page is stored in the rule table.

3. According to claim 1, a data verification method based on a custom plug-in is characterized in that: The construction of the plugin file meets the following rules: The validation rules for different fields of the same basic data can be saved in different plug-in files; The validation rules corresponding to multiple fields can be saved in the same plug-in file; The same plug-in file allows saving validation rules corresponding to multiple basic data.

4. According to claim 1, a data verification method based on a custom plug-in is characterized in that: The plug-in file parameters also include: associated field parameters and prompt messages; When the condition for starting the verification rule of the field to be verified is a composite condition and it is also necessary to refer to the verification results of other fields, the relevant fields are configured in the relevant field parameters; The prompt message is the prompt information returned to the user when the field verification fails, and is used to tell the user the cause of the error.

5. According to claim 1, a data verification method based on a custom plug-in is characterized in that: The collection information configuration page also includes: a user specifying module, which is used to specify all terminal users who need to upload the basic data; and the addition or modification of user information is completed through the user information configuration page.

6. According to claim 1, a data verification method based on a custom plug-in is characterized in that: In step S5, the following steps need to be performed: For each basic data record in the directory table, read the corresponding field table content, and create a physical table for each basic data; The physical table is used to store the data content actually uploaded by the terminal user, which includes: physical table primary key, user code, user full name, field name, and field comment.

7. According to claim 1, a data verification method based on a custom plug-in is characterized in that: Before step S6 is implemented, the following steps are first implemented: According to specific business needs, based on the field rule management page, new or modified verification rules are created and stored in the rule table.

8. According to claim 1, a data verification method based on a custom plug-in is characterized in that: In step S6, the configuration operations include: adding, deleting and modifying.

Images