CN113971165B - Data verification method, device, terminal equipment and storage medium - Google Patents
Data verification method, device, terminal equipment and storage medium Download PDFInfo
- Publication number
- CN113971165B CN113971165B CN202111231727.7A CN202111231727A CN113971165B CN 113971165 B CN113971165 B CN 113971165B CN 202111231727 A CN202111231727 A CN 202111231727A CN 113971165 B CN113971165 B CN 113971165B
- Authority
- CN
- China
- Prior art keywords
- key information
- rule
- verification
- transaction model
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Business, Economics & Management (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Computer Hardware Design (AREA)
- Development Economics (AREA)
- Software Systems (AREA)
- Library & Information Science (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The embodiment of the application is suitable for the technical field of big data, and provides a data verification method, a device, terminal equipment and a storage medium, wherein the method comprises the steps of identifying key information in a message; determining a target transaction model matched with key information from a plurality of preset transaction models, checking the key information based on the life cycle of the target transaction model to obtain a checking result, and if the checking result is a checking failure result, positioning the key information according to a transaction log file, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle. By adopting the method, the key information of verification failure can be rapidly positioned, and the data verification efficiency can be improved.
Description
Technical Field
The application belongs to the technical field of big data, and particularly relates to a data verification method, a data verification device, terminal equipment and a storage medium.
Background
With the rise of big data technology, a service system generally needs a huge amount of service data when running different types of services. In order to make any type of service normally run, data verification is usually required for each type of service data.
However, since different types of services correspond to different service data, the verification rules for the service data are also generally different. When the service data check fails, the service data cannot be positioned and checked directly from the code layer. And the service data failing to be checked cannot be rapidly positioned according to the corresponding prompt information so as to find out the detailed information of the service data failing to be checked.
Disclosure of Invention
The embodiment of the application provides a data verification method, a data verification device, terminal equipment and a storage medium, which can achieve the purpose of quickly positioning service data failing to verify.
In a first aspect, an embodiment of the present application provides a data verification method, where the method includes:
identifying key information in the message;
determining a target transaction model matched with the key information from a plurality of preset transaction models;
based on the life cycle of the target transaction model, carrying out verification processing on the key information to obtain a verification result;
If the verification result is a verification failure result, positioning the key information according to a transaction log file, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle.
In a second aspect, an embodiment of the present application provides a data verification apparatus, including:
the identification module is used for identifying key information in the message;
The target transaction model determining module is used for determining a target transaction model matched with the key information from a plurality of preset transaction models;
the processing module is used for checking the key information based on the life cycle of the target transaction model to obtain a checking result;
And the positioning module is used for positioning the key information according to the transaction log file if the verification result is a verification failure result, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle.
In a third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing a method according to any one of the first aspects described above when the computer program is executed by the processor.
In a fourth aspect, an embodiment of the present application provides a computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements a method according to any one of the first aspects.
In a fifth aspect, an embodiment of the application provides a computer program product for, when run on a terminal device, causing the terminal device to perform the method of any of the first aspects described above.
Compared with the prior art, the method has the beneficial effects that the terminal equipment can identify one or more pieces of key information contained in the message and then match according to all pieces of identified key information so as to determine the target transaction model from a plurality of preset transaction models. Furthermore, when the terminal device performs verification processing on the key information by using a rule engine in the target transaction model according to the life cycle of the target transaction model, a transaction log file containing verification results can be generated. Therefore, the terminal equipment can be enabled to directly identify according to the codes corresponding to the transaction log file, so that key information failing to check is accurately and rapidly located from the transaction log file, and workers are assisted to check the key information manually.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments or the description of the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart illustrating an implementation of a data verification method according to an embodiment of the present application;
FIG. 2 is a flowchart illustrating a data verification method according to another embodiment of the present application;
FIG. 3 is a flowchart illustrating a data verification method according to another embodiment of the present application;
FIG. 4 is a schematic diagram of an implementation of S104 of a data verification method according to an embodiment of the present application;
FIG. 5 is a flowchart illustrating a data verification method according to another embodiment of the present application;
FIG. 6 is a schematic diagram of a data verification device according to an embodiment of the present application;
Fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Furthermore, the terms "first," "second," "third," and the like in the description of the present specification and in the appended claims, are used for distinguishing between descriptions and not necessarily for indicating or implying a relative importance.
The data verification method provided by the embodiment of the application can be applied to terminal equipment such as tablet computers, notebook computers, ultra-mobile personal computer (UMPC) and netbooks, and the specific type of the terminal equipment is not limited.
Referring to fig. 1, fig. 1 shows a flowchart of an implementation of a data verification method according to an embodiment of the present application, where the method includes the following steps:
S101, terminal equipment identifies key information in the message.
In one embodiment, the message is a data unit used for switching and transmission in network transmission. In general, the message contains the complete data information to be sent, and the length of the message is inconsistent, and is unlimited and variable. In addition, messages typically have a structured format for loading and transporting data. For example, for a data request type message, the message may be composed of four parts. For example, the message includes a request line structure, a request header structure, a carriage return line structure, and a message body structure. It may also consist of four parts for a data response type message. For example, a message includes a status line structure, a response header structure, a carriage return line structure, and a message body structure.
For any message, the message body structure area generally contains information that the data request needs to be sent to the server, or contains a specific message that the server returns to the client. In this embodiment, the message may be a data response type message, and the key information is information carried in a region of a message body structure of the message.
Based on this, in this embodiment, the terminal device may consider the content included in the message body of the data response type message, that is, the essential key information. Therefore, when identifying the message, the terminal device can identify the message structure of the type message of the data response first so as to determine the region belonging to the message body structure in the message. And then, identifying the data contained in the area to obtain key information.
It will be appreciated that the types of messages that need to be sent are typically multiple, and that the critical information required for each type is also typically different. For example, for a financial type message, the message information contained therein typically has a plurality of information such as transaction type, transaction direction, transaction scenario, data loader, and check-out item. The terminal device may determine the one or more pieces of information as key information for subsequent processing.
Based on this, in another embodiment, the data identified by the terminal device from the region of the message body structure may have a plurality of substantial information. However, only one or two of the plurality of substantial information may belong to the key information. Therefore, after identifying any kind of essential information from the area of the message body structure, the terminal device can match the essential information with a plurality of preset key information. Further, key information in the message is determined from a plurality of substantial information.
S102, the terminal equipment determines a target transaction model matched with the key information from a plurality of preset transaction models.
In an embodiment, after determining the key information, the terminal device may further determine, from a plurality of preset transaction models, a transaction model matching with the key information as the target transaction model. Wherein the target transaction model is used to define the lifecycle of the entire transaction in the terminal device. It will be appreciated that for any type of transaction, the lifecycle includes various processes such as the initiation, intermediate processing, and ending of the transaction. During this lifecycle, a series of actions are performed around a certain transaction, progressing over time, resulting in a certain transaction result.
In one embodiment, the target transaction model includes a rule engine for verifying each piece of key information in the message, where the rule engine may be used to verify the key information when executed. Specifically, the rule engine has one or more logical rule expressions that verify each key information, and any one logical rule expression may be generated from at least one verification rule expression.
Illustratively, the verification rule expression may be a rule expression that verifies a single key information. For example, one consumption cannot be greater than a limit, a limit on the number of consumption per month, a limit on the number of consumption per period cannot be less than a limit, and so on. The logical rule expression may be an expression that verifies multiple key information simultaneously. For example, the logical rule expression for checking the critical information of the limit number may be two check rule expressions including a client layer limit check and an account layer limit check. The logic rule expression for checking the key information of the control code can be two check rule expressions including card layer control code check, account control code check and the like, and the logic rule expression is not limited.
In an embodiment, after obtaining the logic rule expression or the check rule expression, the terminal device may register the logic rule expression or the check rule expression in the rule engine, respectively. The rules engine is then loaded into the transaction model to obtain a transaction model for verifying the at least one key information. Based on this, it can be understood that, after the terminal device determines the target transaction model, the terminal device can execute the logic rule expression or the verification rule expression inside the terminal device according to the rule engine loaded in the target transaction model, so as to verify the key information in the message in turn.
In a specific application, a worker may develop a plurality of check rule expressions on the terminal device in advance, and then the terminal device automatically combines the plurality of check rule expressions to form a plurality of logic rule expressions. Then, the multiple logical rule expressions are registered in the rule engine, respectively, to form multiple transaction models. Finally, the transaction models are automatically cached in a database respectively. After the key information of the message is received and identified, matching is carried out on the basis of the identified key information and the key information which is respectively and correspondingly checked by a plurality of transaction models in the database, so as to obtain a matched target transaction model.
With reference to fig. 2, the terminal device may generate various transaction models through the following steps S121-S124, which are described in detail as follows:
s121, the terminal equipment acquires a verification rule expression for verifying the key information from the database.
S122, the terminal equipment defines rule names of the check rule expressions and establishes mapping relations between the rule names and the corresponding check rule expressions.
In one embodiment, the database is a database for storing check rule expressions. The verification rule expressions are verification rule codes developed in advance by workers, and each verification rule expression is used for verifying one key information.
It can be appreciated that a worker may define a plurality of key information in the terminal device in advance and develop a verification rule expression for each key information, respectively. And after developing the check rule expression corresponding to any key information, the terminal device can name the check rule expression to define the rule name of the check rule expression. It should be noted that, after defining the rule name, the terminal device may also establish a mapping relationship between the rule name and the corresponding check rule expression.
It should be noted that, for different check rule expressions, their corresponding rule names are generally different. Wherein the rule name includes, but is not limited to, characters, letters, numbers, or combinations thereof.
It should be added that the above logical rule expression is composed of one or more check rule expressions, so that when each check rule expression has a corresponding rule name, the logical rule expression may also have a corresponding rule name, which is not limited.
For example, as ：ACCT_STATUS_CHECKER＝(ACCT_BLKCD_1||ACCT_BLKCD_MEMO_1)&&(ACCT_BLKCD_2||ACCT_BLKCD_MEMO_2)||., acct_status_ CHECKER may be considered a rule name of a logical rule expression, acct_ BLKCD _1||acct_ BLKCD _memo_1 may be considered a rule name of one of the check rule expressions, and acct_ BLKCD _2||acct_ BLKCD _memo_2 may be considered a rule name of another check rule expression, which is not limited.
S123, aiming at any transaction model to be configured, the terminal equipment acquires a data table containing rule names.
S124, the terminal equipment registers the rule names contained in the data table into a rule engine of the transaction model to be configured to configure the transaction model, wherein the rule engine of the configured transaction model is used for mapping out a verification rule expression corresponding to the rule names according to the mapping relation so as to verify the key information.
In an embodiment, the data table is a data table including rule names, where the rule names included in the data table may be 1 or more. It will be appreciated that for a transaction model to be configured, it may be configured according to rule names contained in a data table.
It should be noted that, unlike the prior art, in which the verification rule expression is assembled to the rule engine to generate the configured transaction model, in this embodiment, the rule name is registered in the rule engine when the transaction model is configured. When the rule engine verifies the key information, the rule engine may map a verification rule expression corresponding to the rule name from the database based on the mapping relationship in S122 to verify the key information.
It can be appreciated that the code of the generated transaction model is relatively compact because the rule name is registered in the rule engine of the transaction model to be configured to configure the transaction model.
In one embodiment, the rule engine may be considered a processing center that maps, parses, and performs operations on the check rule expression. Specifically, the terminal device may simultaneously read the database when executing according to the lifecycle of the transaction model. The rules engine in the transaction model may then obtain the corresponding verification rule expression from the database based on the mapping relationship. Namely, locating the realization code corresponding to the check rule expression from the database. And finally, sequentially analyzing the positioned verification rule expressions, and verifying the key information according to the analyzed contents.
Based on this, when configuring any one of the transaction models to be configured, a developer needs to determine one or more pieces of key information that should be included in the transaction process in advance based on the actual transaction scenario. Then, a verification rule expression for verifying each key information is developed. And defining rule names corresponding to the check rule expressions, and establishing a mapping relation between each rule name and the corresponding check rule expression. Finally, registering the rule names contained in the data table into a rule engine, and loading the rule engine into the transaction model to obtain the configured transaction model. The transaction model to be configured is a pre-developed code model and can be used for loading a rule engine.
It will be appreciated that for any one of the formulated transaction models, a target transaction model that matches the critical information is determined from a plurality of the configured transaction models. The terminal device may also pre-associate each configured transaction model with corresponding key information. Specifically, referring to fig. 3, the terminal device may establish the association relationship between the transaction model and the corresponding key information through the following steps S131 to S132, which are described in detail as follows:
S131, the terminal equipment determines key information which can be checked by the transaction model according to rule names contained in the transaction model, wherein the number of the key information at least comprises one.
S132, the terminal equipment establishes an association relation between the transaction model and the key information.
In one embodiment, each configured transaction model includes at least one rule name corresponding to the verification rule expression, so that each configured transaction model can verify at least one key information. Based on this, the terminal device can determine a plurality of pieces of key information that can be verified for each configured transaction model according to the rule names contained in the transaction model. And then, associating each piece of key information with the corresponding transaction model to establish an association relation.
Specifically, for the transaction model a, an association relationship may be established with the consumption amount and the number of consumption times. At this time, if the key information identified in the message is the key information of the consumption amount and the consumption times, the transaction model a may be determined as the target transaction model when the transaction model matching is performed.
S103, the terminal equipment performs verification processing on the key information based on the life cycle of the target transaction model to obtain a verification result.
In an embodiment, the life cycle is explained in S102, which will not be described. The verification result is a result that verification failure or verification success occurs when the key information is verified by the rule engine.
It should be noted that, for a rule engine included in a transaction model, if the rule engine includes a plurality of check rule expressions, the terminal device may further define a sequence of checking between each check rule expression. The sequence of the serial verification includes, but is not limited to, a verification sequence of parallel verification processing of a plurality of key information, and a sequence of serial verification of each key information based on an identification sequence of each key information in the message, which is not limited.
In an embodiment, the verification result of verifying each key information may be displayed as follows. Specific:
if(gets.sum>1000){return false;}return true;}
the 1000 may be a specific amount of a predefined amount of money which cannot be consumed for one time, it is understood that if the amount of money is greater than the specific amount of money, a return false, i.e. a verification failure result is displayed, and if the amount of money is not greater than the specific amount of money, a return true, i.e. a verification success result is displayed.
And S104, if the verification result is a verification failure result, the terminal equipment locates the key information according to the transaction log file, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle.
In one embodiment, when the rules engine performs a verification of the critical information, a transaction log file containing the verification results is generated. The log files include, but are not limited to, transaction log files from server side logs, terminal device logs, web side logs, and target transaction models that are generated when executed according to a lifecycle. The log file is a data file generated when the terminal device performs a certain action (verification processing action). That is, the terminal device can record the operation of itself at any time, and particularly, the operation in which an error is generated or an abnormality occurs can be recorded. Exemplary transaction log files generated for online transfer transaction operations, and the like. Based on the above, when the terminal device executes the target transaction model according to the life cycle, a transaction log file during execution of the target transaction model can be generated, so that the key information corresponding to the verification failure result is positioned.
Specifically, referring to fig. 4, the terminal device may locate the key information of the verification failure through the following sub-steps S1041 to S1042, which are described in detail as follows:
s1041, the terminal equipment determines key information corresponding to the verification failure result as a hit item.
S1042, the terminal equipment locates the code corresponding to the hit from the transaction log file.
In an embodiment, when the terminal device uses the rule engine to verify the key information, the generated transaction log file needs to record the key information for verification and the corresponding verification result (verification failure result or verification success result), which has been explained in S103 above. Based on this, the terminal device may display the key information corresponding to the verification failure result in the form of "hit", i.e., determine the key information corresponding to the verification failure result as a hit. For example, the number of the cells to be processed,
{
Info ("hit { }, stage type: { }, whether or not this is the home token: { }
}
The "stage type" and "whether the token is" may be regarded as rule names of check rule expressions for checking one kind of key information in the message, respectively. Based on this, in the generated transaction log file, the code generated when the verification of the key information fails may be displayed in the form of "hit". For specific forms reference is made to the above codes. Furthermore, the terminal device can identify the codes corresponding to the transaction log file based on the obtained transaction log file, so as to quickly locate the key information corresponding to the verification failure result.
It can be understood that, with reference to the above example code, when locating the key information corresponding to the verification failure result, the rule name for verifying the key information may also be located at the same time. Since the rule name has an association relationship with the corresponding check rule expression. Therefore, when the key information corresponding to the verification failure result is manually checked, the terminal device can also map a specific verification rule expression from the database based on the rule name so as to further assist the staff in manual checking.
In this embodiment, the terminal device may first identify one or more pieces of key information included in the message, and then perform matching according to all pieces of identified key information, so as to determine a target transaction model from a plurality of preset transaction models. Furthermore, when the terminal device performs verification processing on the key information by using a rule engine in the target transaction model according to the life cycle of the target transaction model, a transaction log file containing verification results can be generated. Therefore, the terminal equipment can be enabled to directly identify according to the codes corresponding to the transaction log file, so that key information failing to check is accurately positioned from the transaction log file, and workers are assisted to check manually.
In one embodiment, the check rule expression is generated in Java code, referring to FIG. 5, after determining the target transaction model matching the key information from the preset transaction models in S102, the method further includes the following steps S125-S126, which are described in detail below:
s125, the terminal equipment writes the key information into a verification rule expression in the target transaction model by using a preset Java variable.
S126, the terminal equipment compiles a target transaction model, wherein the target transaction model is used for checking key information in the check rule expression according to the compiling principle of Java codes during compiling.
In an embodiment, before the terminal device verifies the key information according to the target transaction model, there may be a case that the target transaction model has an error code, so that the target transaction model cannot accurately verify the key information.
Typically, in the prior art, after the code of the check rule expression is generated, the code is written directly into a file ending with drl. Files ending with drl are then compiled. And finally, the terminal equipment invokes the compiled code file and executes the corresponding check rule expression. However, in practice, the file ending with drl is a text type file. If the writing errors occur to the variables of the key information to be verified in the verification rule expression, the terminal equipment does not report errors in the process of compiling the error codes to generate the text type compiled file. The error reporting occurs only when the terminal device invokes and executes the code in the compiled file of the text type. Therefore, there will be some latency when the code that checks the regular expression is found to be problematic.
Illustratively, when the variables of the key information to be verified are written into the verification rule expression for verification, the key information is taken as a card number of the bank card for explanation. The terminal device may define the card number in advance as a variable cardNo. In the conventional process of writing variables into codes of a check rule expression, when the codes are directly written into files ending with the speed of drl, even if a developer writes cardNo into cardNum by mistake, whether the variables in the files ending with the speed of drl belong to wrongly written variables cannot be identified in the process of compiling the wrong codes by the terminal equipment. Thereafter, the error is reported only when the terminal device invokes and executes the compiled file of the erroneous code.
However, in this embodiment, the above-mentioned principles of compiling Java code can be specifically divided into three processes of parsing and filling a symbol table, annotating by an inserted annotation processor, analyzing and generating a bytecode, which are sequentially performed on the source code. The process of parsing and filling the symbol table comprises two stages of lexical analysis and grammar analysis. Specifically, the lexical analysis stage is to transform the character stream of the source code (code of the check rule expression) into a set of labels. Wherein the Java code is marked as the minimum unit of the compiling process, and comprises, but is not limited to, characters in the forms of variable names, operators and the like. In the above example, the card number is compiled at cardNo, i.e., can be considered as the variable name in the compilation process.
Based on this, in the present embodiment, a code of a check rule expression that checks key information is generated using Java code, and the key information is present in the code in the form of a variable. Then, for the code of the generated verification rule expression, the terminal device can directly check the variable of the key information contained in the code of the verification rule expression at the moment based on the preset variable corresponding to each key information.
It will be appreciated that the target transaction model is a source code developed by a developer, and if the source code needs to be a program (executable code) that can be run on the terminal device, the target transaction model needs to undergo the processes of compiling, linking, and the like. The compiling process is the process in S125-S126. In this embodiment, since the step S125 is specifically adopted to write the key information into the verification rule expression in the target transaction model with the preset Java variable, it is possible to enable the terminal device to directly identify whether the Java variable written into the target transaction model belongs to the wrongly written variable according to the preset variable corresponding to each key information during the compiling process of the target transaction model. The linking process of the terminal equipment on the compiled target transaction model is not needed, and after the executable program is generated, the situation of wrongly writing the variables of the key information in the check rule expression can be found only when the program is run.
In one embodiment, if the verification result is a verification failure result in S104, locating the key information from the transaction log file generated when the target transaction model is executed according to the lifecycle, further includes:
uploading the verification result to the block chain for storage.
In all embodiments of the present application, the corresponding verification result is obtained based on the terminal device, specifically, the verification result is obtained by processing the terminal device. Uploading the verification result to the blockchain can ensure the security and the fairness and transparency to the user. The user device may download the verification result from the blockchain to verify whether the verification result has been tampered with. The blockchain referred to in this example is a novel mode of application for computer technology such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain (Blockchain), essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods, each of which contains information from a batch of network transactions for verifying the validity (anti-counterfeit) of its information and generating the next block. The blockchain may include a blockchain underlying platform, a platform product services layer, an application services layer, and the like.
Referring to fig. 6, fig. 6 is a block diagram illustrating a data verification apparatus according to an embodiment of the present application. The data verification device in this embodiment includes modules for executing the steps in the embodiments corresponding to fig. 1 to 5. Please refer to fig. 1 to 5 and the related descriptions in the embodiments corresponding to fig. 1 to 5. For convenience of explanation, only the portions related to the present embodiment are shown. Referring to FIG. 6, the data verification apparatus 600 may include an identification module 610, a target transaction model determination module 620, a processing module 630, and a positioning module 640, wherein:
The identifying module 610 is configured to identify key information in the message.
The target transaction model determining module 620 is configured to determine a target transaction model that matches the key information from a preset plurality of transaction models.
And the processing module 630 is configured to perform verification processing on the key information based on the life cycle of the target transaction model, so as to obtain a verification result.
And the positioning module 640 is configured to position the key information according to a transaction log file if the verification result is a verification failure result, where the transaction log file is a log file generated when the target transaction model is executed according to the lifecycle.
In one embodiment, the message includes a request line structure, a request header structure, a carriage return line structure, and a message body structure, and the identification module 610 is further configured to:
Determining the region belonging to the message body structure in the message, and determining the data in the region as key information.
In one embodiment, the transaction model includes a rules engine for verifying critical information, and the data verification device 600 further includes:
and the verification rule expression acquisition module is used for acquiring a verification rule expression for verifying the key information from the database.
The mapping relation establishing module is used for defining rule names of the check rule expressions and establishing mapping relations between the rule names and the corresponding check rule expressions.
The data table acquisition module is used for acquiring a data table containing rule names aiming at any transaction model to be configured.
The configuration module is used for registering the rule names contained in the data table into a rule engine of the transaction model to be configured to configure the transaction model, wherein the rule engine of the configured transaction model is used for mapping out a verification rule expression corresponding to the rule names according to the mapping relation so as to verify the key information.
In one embodiment, the data verification device 600 further includes:
and the key information determining module is used for determining key information which can be checked by the transaction model according to the rule names contained in the transaction model, wherein the number of the key information at least comprises one.
And the association relation establishing module is used for establishing the association relation between the transaction model and the key information.
In one embodiment, the check rule expression is generated in Java code, and the data check device 600 further comprises:
and the writing module is used for writing the key information into the verification rule expression in the target transaction model by using a preset Java variable.
And the compiling module is used for compiling a target transaction model, and the target transaction model is used for checking key information in the check rule expression according to the compiling principle of Java codes during compiling.
In one embodiment, the positioning module 640 is further configured to:
And locating the code corresponding to the hit item from the codes corresponding to the transaction log file.
In one embodiment, the data verification device 600 further includes:
and the uploading module is used for uploading the verification result to the blockchain for storage.
It should be understood that, in the block diagram of the data verification apparatus shown in fig. 6, each module is configured to perform each step in the embodiment corresponding to fig. 1 to 5, and each step in the embodiment corresponding to fig. 1 to 5 has been explained in detail in the above embodiment, and specific reference is made to fig. 1 to 5 and related descriptions in the embodiment corresponding to fig. 1 to 5, which are not repeated herein.
Fig. 7 is a block diagram of a terminal device according to an embodiment of the present application. As shown in fig. 7, the terminal device 700 of this embodiment includes a processor 710, a memory 720, and a computer program 730 stored in the memory 720 and executable on the processor 710, such as a program of a data verification method. The steps of the various embodiments of the data verification method described above, such as S101 to S104 shown in fig. 1, are implemented by the processor 710 when executing the computer program 730. Or processor 710, when executing computer program 730, performs the functions of the modules in the embodiment corresponding to fig. 6, for example, the functions of modules 610 to 640 shown in fig. 6, refer to the related descriptions in the embodiment corresponding to fig. 6.
For example, the computer program 730 may be partitioned into one or more modules that are stored in the memory 720 and executed by the processor 710 to implement the data verification method provided by the embodiments of the present application. One or more of the modules may be a series of computer program instruction segments capable of performing particular functions for describing the execution of the computer program 730 in the terminal device 700. For example, the computer program 730 may implement the data verification method provided by the embodiment of the present application.
Terminal device 700 can include, but is not limited to, a processor 710, a memory 720. It will be appreciated by those skilled in the art that fig. 6 is merely an example of a terminal device 700 and does not constitute a limitation of the terminal device 700, and may include more or less components than illustrated, or may combine certain components, or different components, e.g., a terminal device may also include an input-output device, a network access device, a bus, etc.
The processor 710 may be a central processing unit, but may also be other general purpose processors, digital signal processors, application specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 720 may be an internal storage unit of the terminal device 700, such as a hard disk or a memory of the terminal device 700. The memory 720 may also be an external storage device of the terminal device 700, such as a plug-in hard disk, a smart memory card, a flash memory card, etc. provided on the terminal device 700. Further, the memory 720 may also include both internal storage units and external storage devices of the terminal device 700.
The embodiment of the application provides a terminal device, which comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein the processor realizes the data verification method in each embodiment when executing the computer program.
In a fourth aspect, embodiments of the present application provide a computer readable storage medium including a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the data verification method in each of the embodiments described above when executing the computer program.
In a fifth aspect, embodiments of the present application provide a computer program product for causing a terminal device to perform the data verification method in the above embodiments when the computer program product is run on the terminal device.
The foregoing embodiments are merely for illustrating the technical solution of the present application, but not for limiting the same, and although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that the technical solution described in the foregoing embodiments may be modified or substituted for some of the technical features thereof, and that these modifications or substitutions should not depart from the spirit and scope of the technical solution of the embodiments of the present application and should be included in the protection scope of the present application.
Claims (9)
1. A method of data verification, comprising:
identifying key information in a message, wherein the key information is information carried by a region of a message body structure of the message;
Determining a target transaction model matched with the key information from a plurality of preset transaction models;
based on the life cycle of the target transaction model, performing verification processing on the key information to obtain a verification result;
if the verification result is a verification failure result, positioning the key information according to a transaction log file, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle;
if the verification result is a verification failure result, positioning the key information according to a transaction log file, including:
Determining key information corresponding to the verification failure result as a hit item;
Locating the code corresponding to the hit item and the checked rule name corresponding to the key information from the codes corresponding to the transaction log file;
The transaction model comprises a rule engine for verifying the key information, and before the target transaction model matched with the key information is determined from the preset transaction models, the method further comprises the steps of:
acquiring a verification rule expression for verifying the key information from a database;
defining rule names of the check rule expressions, and establishing a mapping relation between the rule names and the corresponding check rule expressions;
Aiming at any transaction model to be configured, acquiring a data table containing the rule names;
Registering the rule names contained in the data table into a rule engine of the transaction model to be configured so as to configure the transaction model.
2. The method for verifying data according to claim 1, wherein the message includes a request line structure, a request header structure, a carriage return line structure, and a message body structure, and the identifying key information in the message includes:
And determining the area belonging to the message body structure in the message, and determining the data in the area as the key information.
3. The data verification method according to claim 1, wherein a rule engine of the transaction model is configured to map out a verification rule expression corresponding to the rule name according to the mapping relationship to verify the key information.
4. A data verification method according to claim 3, wherein after said registering the rule name contained in said data table in the rule engine of said transaction model to be configured to configure said transaction model, further comprising:
determining key information which can be verified by the transaction model according to rule names contained in the transaction model, wherein the number of the key information at least comprises one;
And establishing an association relation between the transaction model and the key information.
5. The data verification method according to claim 3, wherein the verification rule expression is generated in Java code, and further comprising, after the target transaction model matching the key information is determined from the preset transaction models, the step of:
writing the key information into a verification rule expression in the target transaction model by a preset Java variable;
And compiling the target transaction model, wherein the target transaction model is used for checking key information in the check rule expression according to the compiling principle of the Java code during compiling.
6. The method for verifying data according to any one of claims 1-5, further comprising, after the positioning the key information according to the transaction log file if the verification result is a verification failure result:
and uploading the verification result to a blockchain for storage.
7. A data verification apparatus, comprising:
the identification module is used for identifying key information in the message, wherein the key information is information carried by a region of a message body structure of the message;
the target transaction model determining module is used for determining a target transaction model matched with the key information from a plurality of preset transaction models;
the processing module is used for checking the key information based on the life cycle of the target transaction model to obtain a checking result;
the positioning module is used for positioning the key information according to a transaction log file if the verification result is a verification failure result, wherein the transaction log file is generated when the target transaction model is executed according to the life cycle;
the positioning module is also used for determining key information corresponding to the verification failure result as hit items, positioning codes corresponding to the hit items and verification rule names corresponding to the key information from codes corresponding to the transaction log file;
The transaction model comprises a rule engine for checking the key information, and the data checking device further comprises:
the verification rule expression acquisition module is used for acquiring a verification rule expression for verifying the key information from the database;
The mapping relation establishing module is used for defining rule names of the check rule expressions and establishing mapping relations between the rule names and the corresponding check rule expressions;
The data table acquisition module is used for acquiring a data table containing rule names aiming at any transaction model to be configured;
and the configuration module is used for registering the rule names contained in the data table into a rule engine of the transaction model to be configured so as to configure the transaction model.
8. A terminal device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 6 when executing the computer program.
9. A computer readable storage medium storing a computer program, characterized in that the computer program when executed by a processor implements the method according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111231727.7A CN113971165B (en) | 2021-10-22 | 2021-10-22 | Data verification method, device, terminal equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111231727.7A CN113971165B (en) | 2021-10-22 | 2021-10-22 | Data verification method, device, terminal equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113971165A CN113971165A (en) | 2022-01-25 |
| CN113971165B true CN113971165B (en) | 2025-04-18 |
Family
ID=79587851
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111231727.7A Active CN113971165B (en) | 2021-10-22 | 2021-10-22 | Data verification method, device, terminal equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113971165B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116016719A (en) * | 2022-12-02 | 2023-04-25 | 中国建设银行股份有限公司 | Message processing method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109510824A (en) * | 2018-11-12 | 2019-03-22 | 中国银行股份有限公司 | A kind of method of calibration and device of interface packets |
| CN111562965A (en) * | 2020-04-27 | 2020-08-21 | 深圳木成林科技有限公司 | Page data verification method and device based on decision tree |
| CN112785411A (en) * | 2020-12-29 | 2021-05-11 | 平安消费金融有限公司 | Credit investigation data processing method, system, equipment and computer readable storage medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105589906B (en) * | 2014-12-26 | 2019-02-19 | 中国银联股份有限公司 | Normative monitoring method of transaction message |
| CN111222070B (en) * | 2019-12-30 | 2023-07-21 | 深圳市五谷网络科技有限公司 | Data processing method, device, equipment and storage medium |
-
2021
- 2021-10-22 CN CN202111231727.7A patent/CN113971165B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109510824A (en) * | 2018-11-12 | 2019-03-22 | 中国银行股份有限公司 | A kind of method of calibration and device of interface packets |
| CN111562965A (en) * | 2020-04-27 | 2020-08-21 | 深圳木成林科技有限公司 | Page data verification method and device based on decision tree |
| CN112785411A (en) * | 2020-12-29 | 2021-05-11 | 平安消费金融有限公司 | Credit investigation data processing method, system, equipment and computer readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113971165A (en) | 2022-01-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110474900B (en) | Game protocol testing method and device | |
| CN109564540A (en) | Debugging tool for JIT compiler | |
| WO2012052215A1 (en) | Software development | |
| CN114490692B (en) | Data verification method, device, equipment and storage medium | |
| CN115686631B (en) | Method, device and storage medium for generating random instructions based on knowledge base | |
| CN112181485A (en) | Script execution method and device, electronic equipment and storage medium | |
| CN112579475A (en) | Code testing method, device, equipment and readable storage medium | |
| CN114816993A (en) | Full link interface test method, system, medium and electronic equipment | |
| CN114661423A (en) | Cluster configuration detection method and device, computer equipment and storage medium | |
| CN113971165B (en) | Data verification method, device, terminal equipment and storage medium | |
| CN113434542A (en) | Data relation identification method and device, electronic equipment and storage medium | |
| CN112686759B (en) | Account reconciliation monitoring method, device, equipment and medium | |
| CN112948400B (en) | Database management method, database management device and terminal equipment | |
| CN117614681A (en) | Method, system, equipment and storage medium for detecting re-entry vulnerability of intelligent contract | |
| CN119105799A (en) | Code analysis method, electronic device, and computer readable medium | |
| CN116628005A (en) | Structured query statement processing method, device, equipment and storage medium | |
| CN116302079A (en) | Service data processing method and device, electronic equipment and storage medium | |
| US11144287B2 (en) | Compile time validation of programming code | |
| CN114925033A (en) | Information uploading method, device, system and storage medium | |
| Moebius et al. | A modeling framework for the development of provably secure e-commerce applications | |
| CN113282240A (en) | Storage space data read-write method, equipment, storage medium and program product | |
| CN113434414A (en) | Data testing method and device, electronic equipment and storage medium | |
| CN111767222A (en) | Data model verification method, device, electronic device, storage medium | |
| CN120353714B (en) | Data verification method, device, electronic device, medium and program product | |
| CN118626151B (en) | Instruction stream file generation method, device, electronic device and readable medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |