Data verification method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a data verification method and device, electronic equipment and a storage medium, and relates to the technical field of Internet. The method comprises the following steps: acquiring service record data of a to-be-verified service of a target service processing system; generating a first query request for the current service processing state; querying a target business process event set associated with the state identifier of the current business processing state from a first database; generating a second query request for the target business process event; querying a target event feature corresponding to a target event identifier of the target business process event from a second database; the method comprises the following steps: analyzing an event record to obtain record information of a business field related to an event, and extracting a first event feature from the record information of the business field; matching the first event feature with each target event feature to obtain a first matching result; and obtaining a data verification result of the business record data based on each first matching result. The data verification efficiency can be improved.

Description

Technical Field

[0001] This application relates to the Internet field, and more specifically, to a data verification method, apparatus, electronic device, and storage medium. Background Technology

[0002] During the business processing process in a business processing system, it is necessary to verify the business record data generated during the process. For example, in a credit card issuance system, it is necessary to verify the business record data during the card issuance process.

[0003] Currently, business record data in business processing systems is typically validated using BI (Business Intelligence Reports). However, these reports require a series of operations, including data collection, cleaning, and analysis, and the real-time nature of the data validation is weak, resulting in low efficiency. Summary of the Invention

[0004] The purpose of this application is to provide a data verification method, apparatus, and electronic device that can solve the problem of low efficiency in data verification. The technical solution provided in this disclosure is as follows: On one hand, embodiments of this application provide a data verification method, the method comprising: Obtain the business record data of the business to be verified from the target business processing system; the business record data includes the current business processing status of the business to be verified and event records of multiple first business process events; A first query request is generated for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, a target business process event set associated with the state identifier of the current business processing state is queried from the first database; wherein, the first database stores a business process event set corresponding to the state identifier of each business processing state in the target business processing system; For each target business process event in the target business process event set, a second query request is generated for the target business process event; the second query request carries the target event identifier of the target business process event; based on the second query request, the target event feature corresponding to the target event identifier of the target business process event is queried from the second database; wherein, the second database stores the event features corresponding to the event identifiers of each business process event of the target business system; the event feature of any business process event is used to characterize the business features possessed when the business process event has been generated; For each first business process event, the record information of the business fields related to the event is obtained by parsing the event record, the corresponding key business parameters are extracted from the record information of the business fields, and the extracted key business parameters are used as the first event feature of the first business process event. For each first business process event, the first event feature is matched with each of the target event features to obtain a first matching result; based on the first matching result of each first business process event, the data verification result of the business record data is obtained.

[0005] In some possible implementations, the method further includes: The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, a third query request is generated for the second business process event; the third query request carries a second event identifier of the second business process event; based on the third query request, the second event characteristics of each second business process event are queried from the second database; For each first business process event, the first event feature is matched with each of the second event features to obtain a second matching result; Based on the first matching results of each first business process event, the data verification results of the business record data are obtained, including: Based on the first and second matching results of each first process event, the data verification results of the business record data are obtained.

[0006] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state stored in the first database is generated based on the following method: Obtain multiple business process nodes of the business to be verified in the target business system, sort the business process nodes according to the node execution order, and obtain the corresponding node sequence; Each business process node in the node sequence is executed sequentially. Based on the execution status of each business process node, a corresponding business process event is generated, and the business processing status corresponding to at least one generated business process event is obtained; the execution status is either successful or failed. Each obtained business processing state is taken as the business processing state of the target business processing system, and a state identifier corresponding to each business processing state is generated; for each business processing state, at least one generated business process event corresponding to the business processing state is taken as the business process event set corresponding to the state identifier of the business processing state.

[0007] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state is stored in the first database in the form of a status event relationship table; For each business processing state, the step of taking at least one generated business process event corresponding to the business processing state as a set of business process events corresponding to the state identifier of the business processing state includes: Based on each execution state of each business process node, obtain each business process event of the target business processing system. For each business processing state, a first tag is used to mark the event identifier of the generated business process event corresponding to the state identifier of the business processing state, and a second tag is used to mark the event identifier of the ungenerated business process event corresponding to the state identifier of the business processing state, so as to obtain the state event relationship table. The step of querying the target business process event set associated with the current business processing status from the first database includes: The target business process event set is obtained by querying the state event relationship table and finding the business process event that corresponds to the state identifier of the current business processing state and is marked with the first mark.

[0008] In some possible implementations, based on the first and second matching results of each first process event, the data verification result of the business record data is obtained, including: If the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

[0009] In some possible implementations, if the data verification result indicates that the business record data is abnormal, the method further includes: Identify the business process events to be corrected from multiple first business process events; the event characteristics of the business process events to be corrected do not conform to the target event characteristics or conform to the second event characteristics; The event records of the business process events to be corrected are sent to the verification server, so that the verification server can generate the first alarm information based on the event records of the business process events to be corrected.

[0010] In some possible implementations, the method further includes: From multiple business process nodes of the target business in the target business system, query the business process node to which the business process event to be corrected belongs; Query the terminals to be alerted that are associated with the business process node to which the business process event to be corrected belongs, and send the alarm information to the terminals to be alerted.

[0011] In some possible implementations, each business process node of the target business in the target business system has a corresponding node importance level; Send alarm information to the terminals to be alerted, including: Query the importance level of the business process node to which the business process event to be corrected belongs, and query the reminder method corresponding to the importance level of the node; each importance level of the business process node has its own reminder method. Based on the retrieved notification method, the alarm information will be sent to the terminal to be notified.

[0012] In some possible implementations, before querying the target event characteristics corresponding to the event identifier of the target business process event from the second database based on the second query request, the method further includes: Extract the first event identifier of each first business process event from the event records of multiple first business process events; Query the target event identifier of each target business process event in the target business process event set from the first database; The first event identifier of each first business process event is matched with the target event identifier of each target business process event to obtain the third matching result; For each target business process event in the target business process event set, query the target event characteristics of the target business process event from the second database, including: If the third matching result is that the first event identifier of each first business process event matches the target event identifier of each target business process event, then for each target business process event in the target business process event set, the target event feature of the target business process event is queried from the second database.

[0013] In some possible implementations, the method further includes: If the third matching result is that there is a mismatch between the first event identifier of at least one first business process event and the target event identifier of at least one target business process event, then the event identifier to be corrected that does not match the target event identifier is determined from the first event identifiers of each first business process event. The event identifier to be corrected is sent to the verification server so that the verification server can generate a second alarm message based on the event identifier to be corrected.

[0014] On the other hand, embodiments of this application provide a data verification device, including: The acquisition module is used to acquire the business record data of the business to be verified in the target business processing system; the business record data includes the current business processing status of the business to be verified and the event records of multiple first business process events; The first query module is used to generate a first query request for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, it queries a target business process event set associated with the state identifier of the current business processing state from the first database; wherein, the first database stores a business process event set corresponding to the state identifier of each business processing state in the target business processing system. The second query module is used to generate a second query request for each target business process event in the target business process event set; the second query request carries a target event identifier of the target business process event; and queries the second database for the target event feature corresponding to the target event identifier of the target business process event based on the second query request; wherein, the second database stores the event features corresponding to the event identifiers of each business process event of the target business system; the event feature of any business process event is used to characterize the business features possessed when the business process event has been generated; The extraction module is used to obtain the record information of the business fields related to the event by parsing the event record for each first business process event, extract the corresponding key business parameters from the record information of the business fields, and use the extracted key business parameters as the first event feature of the first business process event. The first matching module is used to match the first event feature with each of the target event features for each first business process event to obtain a first matching result; and to obtain the data verification result of the business record data based on the first matching result of each first business process event.

[0015] In some possible implementations, the method further includes a third query module for: The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, a third query request is generated for the second business process event; the third query request carries the second event identifier of the second business process event; based on the third query request, the second event characteristics of each second business process event are queried from the second database. For each first business process event, the first event features are matched with each second event feature to obtain the second matching result; When the first matching module obtains the data verification result of the business record data based on the first matching result of each first business process event, it is specifically used for: Based on the first and second matching results of each first process event, the data verification results of the business record data are obtained.

[0016] In some possible implementations, a generation module is also included: Obtain multiple business process nodes of the business to be verified in the target business system, sort the business process nodes according to the execution order of the nodes, and obtain the corresponding node sequence; Each business process node in the node sequence is executed sequentially. Based on the execution status of each business process node, a corresponding business process event is generated, and the business processing status corresponding to at least one generated business process event is obtained; the execution status is either successful or failed. Each obtained business processing state is taken as the business processing state of the target business processing system, and a state identifier corresponding to each business processing state is generated; for each business processing state, at least one generated business process event corresponding to the business processing state is taken as the business process event set corresponding to the state identifier of the business processing state.

[0017] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state is stored in the first database in the form of a status event relationship table; When the generation module, for each business processing state, takes at least one generated business process event corresponding to that state as a set of business process events corresponding to the state identifier of that business processing state, it is specifically used for: Based on each execution state of each business process node, obtain each business process event of the target business processing system. For each business processing state, a first tag is used to mark the event identifier of the generated business process event corresponding to the state identifier of the business processing state, and a second tag is used to mark the event identifier of the ungenerated business process event corresponding to the state identifier of the business processing state, so as to obtain the state event relationship table. When the first query module queries the target business process event set associated with the current business processing status from the first database, it is specifically used for: The target business process event set is obtained by querying the state event relationship table and finding the business process event that corresponds to the state identifier of the current business processing state and is marked with the first mark.

[0018] In some possible implementations, when the first matching module obtains the data verification result of the business record data based on the first matching result and the second matching result of each first process event, it is specifically used for: If the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

[0019] In some possible implementations, if the data verification result indicates that the business record data is abnormal, the device further includes a first alarm module, used for: Identify the business process events to be corrected from multiple first business process events; the event characteristics of the business process events to be corrected do not conform to the target event characteristics or conform to the second event characteristics; The event records of the business process events to be corrected are sent to the verification server, so that the verification server can generate the first alarm information based on the event records of the business process events to be corrected.

[0020] In some possible implementations, the device also includes a reminder module for: From multiple business process nodes of the target business in the target business system, query the business process node to which the business process event to be corrected belongs; Query the terminals to be alerted that are associated with the business process node to which the business process event to be corrected belongs, and send the alarm information to the terminals to be alerted.

[0021] In some possible implementations, each business process node of the target business in the target business system has a corresponding node importance level; When the first alarm module sends alarm information to the terminal to be alerted, it is specifically used for: Query the importance level of the business process node to which the business process event to be corrected belongs, and query the reminder method corresponding to the importance level of the node; each importance level of the business process node has its own reminder method. Based on the retrieved notification method, the alarm information will be sent to the terminal to be notified.

[0022] In some possible implementations, the apparatus further includes a second matching module for: Extract the first event identifier of each first business process event from the event records of multiple first business process events; Query the target event identifier of each target business process event in the target business process event set from the first database; The first event identifier of each first business process event is matched with the target event identifier of each target business process event to obtain the third matching result; When the second query module queries the target event characteristics of each target business process event in the target business process event set from the second database, it is specifically used for: If the third matching result is that the first event identifier of each first business process event matches the target event identifier of each target business process event, then for each target business process event in the target business process event set, the target event feature of the target business process event is queried from the second database.

[0023] In some possible implementations, the device further includes a second alarm module for: If the third matching result is that there is a mismatch between the first event identifier of at least one first business process event and the target event identifier of at least one target business process event, then the event identifier to be corrected that does not match the target event identifier is determined from the first event identifiers of each first business process event. The event identifier to be corrected is sent to the verification server so that the verification server can generate a second alarm message based on the event identifier to be corrected.

[0024] On the other hand, embodiments of this application also provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method provided in any optional embodiment of this application.

[0025] On the other hand, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in any optional embodiment of this application.

[0026] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the methods provided in any optional embodiment of this application.

[0027] The beneficial effects of the technical solution provided in this application are as follows: By pre-acquiring multiple processing states of the target business processing system and the business process event set corresponding to the status identifier of each business processing state, a first database is generated; and by pre-acquiring the event characteristics of each business process event of the target business system, a second database is generated. When the business record data of the business to be verified is obtained, the target business process event set associated with the status identifier of the current business processing state is queried from the first database, and the target event characteristics of the target business process events are queried from the second database. The target event characteristics are matched with each first event characteristic to obtain the first matching result. It can be determined whether the first event characteristics in the business data records in the business record data are the event characteristics of the target business events that should occur in the current business processing state. Based on the first matching results of each first business process event, the data verification result of the business record data is obtained. The business record data to be verified can be verified in real time, effectively improving the efficiency of business data verification. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0029] Figure 1 This is a schematic diagram illustrating the application environment of a data validation method provided in an example. Figure 2 A flowchart illustrating a data verification method provided in an embodiment of this application; Figure 3 A flowchart illustrating a data verification scheme provided in an embodiment of this application; Figure 4 An execution diagram of each business process node of the target business processing system provided as an example for this application; Figure 5 An execution diagram of each business process node of the target business processing system provided as an example for this application; Figure 6 This is a schematic diagram of the various card issuance process events and corresponding business processing states of a credit card issuance system provided as an example in this application; Figure 7 A schematic diagram illustrating a data verification scheme for a credit card issuance system provided as an example in this application; Figure 8 A schematic diagram illustrating a data verification scheme for a credit card issuance system provided as an example in this application; Figure 9 A schematic diagram illustrating a scheme for constructing data verification rules for a credit card issuance system provided as an example in this application; Figure 10A schematic diagram illustrating a data verification scheme for a credit card issuance system provided as an example in this application; Figure 11 A schematic diagram illustrating a scheme for displaying data verification results in a credit card issuance system provided as an example of this application; Figure 12 This is a schematic diagram of the structure of a data verification device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the structure of an electronic device to which this application applies. Detailed Implementation

[0030] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0031] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.” When describing multiple (two or more) items, if the relationship between the multiple items is not explicitly defined, the multiple items can refer to one, several or all of the multiple items. For example, the description of "parameter A includes A1, A2, A3" can be implemented as parameter A includes A1 or A2 or A3, or it can be implemented as parameter A includes at least two of the three items A1, A2 and A3.

[0032] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0033] To better illustrate and understand the solutions provided in the embodiments of this application, some related technical terms used in the embodiments of this application will be introduced first: Currently, most of the business data analyzed by the system is presented using BI reports. Figure 1 Based on the principles of BI reporting, BI can be divided into three levels according to different processes of enterprise business data: 1) Data source layer: The data source layer is also the data layer of BI. The business information systems of different departments and business lines collect and extract data from their underlying databases into the BI data warehouse for modeling, analysis, etc., and finally support the front-end visualization analysis and display.

[0034] 2) Data Model Layer: The data model layer, also known as the BI data warehouse, is mainly responsible for the analysis model of enterprise data and completes the transformation from business calculation rules to data calculation rules.

[0035] 3) Visualization and Analysis Presentation Layer: The visualization and analysis presentation layer is also the BI requirement layer. On the one hand, it represents the user's needs, and on the other hand, it represents what the user wants to analyze; that is, the final visual report presented.

[0036] Currently, BI reporting methods suffer from significant data processing delays. BI reports require a series of operations, including data collection, cleaning, and analysis, resulting in weak real-time data performance and making minute-level data monitoring difficult. Furthermore, BI reporting methods have limited capabilities for detailed data analysis. While BI reports excel at summarizing and analyzing large amounts of data, they lack support for detailed data analysis, a scenario typically not implemented at the BI level.

[0037] The data verification methods, apparatus, electronic devices, computer-readable storage media, and computer program products disclosed herein are intended to solve at least one of the above-mentioned technical problems of the prior art.

[0038] The following description of several optional embodiments illustrates the technical solutions provided in this application and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0039] In the specific embodiments of this application, any data related to the object, such as business record data, involved in the business verification process, requires the object's permission or consent when the embodiments of this application are applied to specific products or technologies. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if any of the aforementioned object-related data is involved in the embodiments of this application, this data must be obtained with the object's authorization and consent, and in accordance with the relevant laws, regulations, and standards of the country and region.

[0040] The data verification method provided in this application embodiment can be executed by any computer device. Optionally, it can be executed by a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.

[0041] Figure 1This is a schematic diagram illustrating the application environment of the data verification method provided in this application embodiment. The application environment may include a target business processing terminal 101 and a data verification server 102. The target business processing terminal 101 includes a target business processing system. Specifically, the target business processing terminal 101 processes the business to be verified, obtaining business record data for the business to be verified; the data verification server 102 acquires the business record data for the business to be verified; the business record data includes the current business processing status of the business to be verified and event records of multiple first business process events; the data verification server 102 generates a first query request for the current business processing status; the first query request carries a status identifier corresponding to the current business processing status; based on the first query request, it queries a target business process event set associated with the status identifier of the current business processing status from a first database; the data verification server 102 generates a second query request for the target business process events; the second query request carries the target business process event... The data verification server 102 identifies the event; based on the second query request, for each target business process event in the target business process event set, it queries the second database for the target event feature corresponding to the target event identifier of the target business process event; for each first business process event, the data verification server 102 parses the event record to obtain the record information of the business fields related to the event, extracts the corresponding key business parameters from the record information of the business fields, and uses the extracted key business parameters as the first event feature of the first business process event; for each first business process event, the first event feature is matched with each target event feature to obtain a first matching result; based on the first matching result of each first business process event, the data verification server 102 obtains the data verification result of the business record data. The data verification server 102 returns the data verification result to the target business processing terminal 101.

[0042] In the above application scenarios, the data verification server performs business data verification. In other application scenarios, the target business processing terminal can perform business processing and business data verification. This application does not limit this.

[0043] Those skilled in the art will understand that a server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server or server cluster that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Terminals can be smartphones (such as Android phones, iOS phones, etc.), tablets, laptops, digital broadcast receivers, MIDs (Mobile Internet Devices), PDAs (Personal Digital Assistants), desktop computers, smart home appliances, in-vehicle terminals (such as in-vehicle navigation terminals, in-vehicle computers, etc.), smart speakers, smartwatches, etc. Terminals and servers can be directly or indirectly connected via wired or wireless communication, but are not limited to these methods. Embodiments of this invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving. Specific applications can be determined based on actual application scenario requirements and are not limited here.

[0044] The terminal (also known as a user terminal or user device) can be a smartphone, tablet, laptop, desktop computer, intelligent voice interaction device (e.g., smart speaker), wearable electronic device (e.g., smartwatch), in-vehicle terminal, smart home appliance (e.g., smart TV), AR / VR device, aircraft, etc., but is not limited to these. Embodiments of this invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0045] In some possible implementations, a data verification method is provided that can be performed by a server.

[0046] Figure 2 The illustration shows a flowchart of a data verification method provided in an embodiment of this application. Taking a server as the executing entity as an example, the data verification method provided in this application may include the following steps: Step S201: Obtain the business record data of the business to be verified from the target business processing system.

[0047] The business record data includes the current business processing status of the business to be verified and event records of multiple first business process events.

[0048] The current business processing status is used to characterize the progress status of the business to be verified and is related to each business processing node of the target business processing system.

[0049] Taking a credit card issuance system as an example, the various business processing nodes of the target business processing system can include user card application, document submission, preliminary review, document receipt, final review, etc.; accordingly, the current business processing status can be user card application status, document submission failure status, preliminary review in progress status, preliminary review failure status, document receipt in progress status, document receipt failure status, etc.

[0050] Specifically, business process events are events generated when executing various business processing nodes of the target business processing system, and the first business process event is the corresponding event generated by the business processing node that has been executed in the business record data to be verified.

[0051] Taking the target business processing system as a credit card issuance system as an example, the first business process event may include card application event, document submission success callback event, initial review success callback event, receipt success callback event, etc.

[0052] Specifically, the event log may include the generation time (i.e., the occurrence time) of each first business process event, as well as the content of the first business process event.

[0053] Taking the target business processing system as a credit card issuance system as an example, the event record of the first business process event can include the card application event, the card application information, the time of information submission, the time of successful information submission callback, etc.

[0054] Step S202: Generate a first query request for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, query the first database for a target business process event set associated with the state identifier of the current business processing state.

[0055] The first database stores the set of business process events corresponding to the status identifier of each business processing state in the target business processing system; the status identifier of the business processing state can be the name of the business processing state.

[0056] Specifically, the business process event set includes at least one business process event associated with the status identifier of each business processing state; that is, the business process event that should have occurred for each business processing state. Therefore, the target business process event set associated with the status identifier of the current business processing state contains the target business process events that should have occurred in the current business processing state.

[0057] In practice, the current business processing status is associated with the business process node being executed and the execution status of each business process node, and thus with business process events.

[0058] Taking the target business processing system as a credit card issuance system as an example, if the current business processing status is user application for card, the event that should occur is the card application event; if the current business processing status is preliminary review, the events that should have occurred are the card application event and the successful submission of materials callback event.

[0059] It should be noted that each business processing state in the target business processing system stored in the first database is a non-transient state, because transient states are difficult to capture.

[0060] For example, the various business processing nodes of the target business processing system may include nodes such as user card application, document submission, preliminary review, document receipt, and final review. If the user successfully submits the documents, the target business system will not remain in the document submission success state, but will proceed to the next business processing node, i.e., the preliminary review state. However, if the user fails to submit the documents, the target business system will remain in the document submission failure state. Similarly, if the preliminary review is successful, the target business system will not remain in the preliminary review success state, but will also proceed to the next node, i.e., the document receipt state. However, if the user fails the preliminary review, the target business system will remain in the preliminary review failure state.

[0061] Step S203: For each target business process event in the target business process event set, generate a second query request for the target business process event; the second query request carries the target event identifier of the target business process event; based on the second query request, query the target event feature corresponding to the target event identifier of the target business process event from the second database.

[0062] The second database stores the event characteristics corresponding to the event identifiers of each business process event in the target business system; the event characteristics of any business process event are used to characterize the business characteristics that the business process event has when it has been generated.

[0063] The event identifier for each business process event can include the event name of the respective business process event, and the target event identifier for the target business process event can include the target event name of the target business process event.

[0064] In the specific implementation process, the target business process event set associated with the status identifier of the current business processing status is the target business process event set that should have occurred in the current business processing status. In other words, the target event characteristics of the target business process event are the characteristics of the event that should have in the current business processing status.

[0065] Specifically, the characteristics of a target business process event can include the occurrence of the event, the content of the event occurrence, and so on.

[0066] Taking the target business processing system as a credit card issuance system as an example, if the business process event is a card application event, the corresponding event characteristics are that the application time is not empty and the application information is not empty; if the business process event is a data submission success event, the event characteristics include that the data submission time is not empty and the bank callback submission is successful.

[0067] Step S204: For each first business process event, the record information of the business fields related to the event is obtained by parsing the event record, the corresponding key business parameters are extracted from the record information of the business fields, and the extracted key business parameters are used as the first event feature of the first business process event.

[0068] Among them, business fields include the specific business items of the business process event. For example, business fields can include time fields, content fields, etc. Taking the time field as an example, the record information of the business field can include the occurrence time of the specific business process event.

[0069] Among them, key business parameters can be the content parameters of key fields in the business fields that are associated with the corresponding event characteristics.

[0070] Taking the target business processing system as the card issuance system and the first business process event as the card application event as an example, by parsing the event record of the card application event, we can obtain the time field and the content field of the card application event. By extracting key business parameters from the time field and the content field of the card application event, we can extract the specific content parameters of the time field.

[0071] Specifically, for each first business process event, parsing the event record of the first business process event can yield record information for multiple business fields.

[0072] Specifically, the first event characteristics of the first business process event can include the occurrence of the event, the content of the event occurrence, and so on.

[0073] Step S205: For each first business process event, the first event feature is matched with each of the target event features to obtain a first matching result; based on the first matching result of each first business process event, the data verification result of the business record data is obtained.

[0074] In the specific implementation process, the target event characteristics of the target business process event are the characteristics of the event that should exist in the current business processing state. The target event characteristics can be matched with each first event characteristic to determine whether the first event characteristics of the first business process meet the target event characteristics, thereby determining whether the first event characteristics in the business data record are the characteristics of the event that should occur.

[0075] Specifically, if the first matching result is that the first event characteristics of each first business process event match the target event characteristics of the target business process event, then it means that the first event characteristics of the event records of each first business process event match the target event characteristics of the target business process event that should be processed in the current business process state, and the data verification result is that the business record data is normal.

[0076] In the above embodiments, a first database is generated by pre-acquiring multiple processing states of the target business processing system and the business process event set corresponding to the status identifier of each business processing state; and a second database is generated by pre-acquiring the event characteristics of each business process event of the target business system; when the business record data of the business to be verified is obtained, the target business process event set associated with the status identifier of the current business processing state is queried from the first database, and the target event characteristics of the target business process events are queried from the second database. The target event characteristics are matched with each first event characteristic to obtain a first matching result; it can be determined whether the first event characteristics in the business data records in the business record data are the event characteristics of the target business events that should occur in the current business processing state, so as to obtain the data verification result of the business record data based on the first matching result of each first business process event. The business record data to be verified can be verified in real time, which effectively improves the efficiency of business data verification.

[0077] The above embodiments illustrate the process of verifying the business record data of the business to be verified in the target business processing system. The following will illustrate the above process with specific examples.

[0078] In one example, taking a credit card issuance system as the target business processing system, the data verification method may include the following steps: The system obtains multiple business processing states of the credit card issuance system and acquires the card issuance process event set corresponding to the status identifier of each business processing state; the card issuance process event set includes at least one card issuance process event; and stores the card issuance process event set corresponding to the status identifier of each business processing state in the first database. Obtain the card issuance event characteristics corresponding to each card issuance process event, and store the event characteristics of each card issuance process event in the second database; Obtain the card issuance record data to be verified from the credit card issuance system; the card issuance record data includes the current business processing status of the card issuance business and event records of multiple first card issuance process events; Query the target card issuance process event set associated with the status identifier of the current business processing status from the first data; the target card issuance process event set includes at least one target card issuance process event; For each target card issuance process event in the target card issuance process event set, query the target event characteristics of the target card issuance process event from the second database; Extract the first event features of each first card issuance process event from the event records of multiple first card issuance process events; for each target card issuance process event, match the target event features with each first event feature to obtain the first matching result; Based on the first matching results of each first business process event, the data verification results of the card issuance record data are obtained.

[0079] In some possible implementations, the method further includes: The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, a third query request is generated for the second business process event; the third query request carries the second event identifier of the second business process event; based on the third query request, the second event characteristics of each second business process event are queried from the second database. For each first business process event, the first event features are matched with each second event feature to obtain the second matching result.

[0080] Among them, the target business process event is the business process event that should occur in the current business processing state. Then, the business process events other than the target business process event in the target business processing system are business process events that should not occur in the current business processing state. That is, the second business process event is a business process event that should not occur in the current business processing state.

[0081] The second event identifier of the second business process event may include the event name of the second business process event.

[0082] Specifically, for business process events that should not occur in the current business processing state, the second event features of each second business process event are queried from the second database, and the target event features are matched with each second event feature to obtain the second matching result.

[0083] Step S205, based on the first matching results of each first business process event, obtains the data verification results of the business record data, which may include: Based on the first and second matching results of each first process event, the data verification results of the business record data are obtained.

[0084] Specifically, for business process events that should not occur under the current business processing state, and for business record data with normal business data, the first event record of each first process event should not conform to the second event characteristics of the second business process event. In other words, if the second matching result of each first process event is that the first event characteristics do not match the second event characteristics, and the first event characteristics match the target event characteristics, then the data verification result of the business record data is normal.

[0085] In other words, if the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

[0086] The following will be combined with the appendix Figure 3 The above embodiments are further described below.

[0087] like Figure 3 As shown, in one embodiment of this application, the data verification method of this application may include the following steps: Obtain the business record data of the business to be verified from the target business processing system; Generate a first query request for the current business processing status; Based on the first query request, query the first database for the target business process event set associated with the status identifier of the current business processing status; For each target business process event in the target business process event set, generate a second query request for the target business process event; Based on the second query request, query the second database for the target event characteristics corresponding to the target event identifier of the target business process event; For each first business process event, the record information of the business fields related to the event is obtained by parsing the event record; Extract the corresponding key business parameters from the record information of the business fields, and use the extracted key business parameters as the first event feature of the first business process event; The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, generate a third query request for the second business process event; Based on the third query request, query the second event characteristics of each second business process event from the second database; For each first business process event, the first event feature is matched with each of the target event features to obtain a first matching result; For each first business process event, the first event features are matched with each second event feature to obtain the second matching result; If the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

[0088] Taking a credit card issuance system as an example, the system obtains the first event characteristics of each first card issuance process event and the target event characteristics of the target card issuance process event associated with the current business processing state. It then takes the card issuance process events other than the target card issuance process event in the target card issuance processing system as second card issuance process events and obtains the second event characteristics of each second card issuance process event. The system matches the first event characteristics of each first card issuance process event with the target event characteristics to obtain a first matching result. Finally, it matches the first event characteristics and second event characteristics of each first card issuance process event to obtain a second matching result. If the first matching result for each first card issuance process event indicates that the first event characteristics match the target event characteristics, and the second matching result indicates that the first event characteristics do not match the second event characteristics of any of the second card issuance process events, then the data verification result indicates that the card issuance record data is normal data. If the first matching result indicates that the first event characteristics do not match the target event characteristics, or the second matching result indicates that the first event characteristics match the second event characteristics of any of the second card issuance process events, then the data verification result indicates that the card issuance record data is abnormal data.

[0089] In the actual implementation process, the occurrence of each business process event will leave data traces in the data source, which are called event characteristics. Taking the target business processing system as a credit card issuance system as an example, as shown in Table 1 below, for instance, when an application event occurs, the corresponding event characteristics are that the application time is not empty and the application information is not empty; when a successful data submission callback event occurs, the corresponding event characteristics are that the data submission time is not empty and the bank's callback indicates successful submission; when a failed data submission callback event occurs, the corresponding event characteristics are that the data submission time is not empty and the bank's callback indicates failed submission; when a successful initial review callback occurs, the initial review time is not empty and the bank's callback indicates successful initial review; when a failed initial review callback event occurs, the corresponding event characteristics are that the initial review time is not empty and the bank's callback indicates failed initial review; when a successful receipt callback event occurs, the corresponding event characteristics are that the receipt time is not empty and the bank's callback indicates successful receipt; when a failed receipt callback event occurs, the corresponding event characteristics are that the receipt time is not empty and the bank's callback indicates failed receipt; when a successful final review callback event occurs, the corresponding event characteristics are that the final review time is not empty, the bank's callback indicates successful final review, and the applied credit card number is not empty; when a failed final review callback occurs, the corresponding event characteristics are that the final review event is empty and the bank's callback indicates failed final review.

[0090] Table 1: Relationship between events and event characteristics in the credit card issuance process of a credit card issuance system

[0091] The following will further illustrate the process of generating the business process event set corresponding to each business processing state in the first database, with reference to the embodiments.

[0092] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state stored in the first database is generated based on the following method: (1) Obtain multiple business process nodes of the business to be verified in the target business system, sort the business process nodes according to the execution order of the nodes, and obtain the corresponding node sequence; (2) Execute each business process node in the node sequence in sequence, generate the corresponding business process event according to the execution status of each business process node, and obtain the business processing status corresponding to at least one generated business process event; the execution status is execution success or execution failure. (3) Take each business processing state as the business processing state of the target business processing system and generate a status identifier corresponding to each business processing state; for each business processing state, take at least one business process event that has been generated corresponding to the business processing state as the business process event set corresponding to the status identifier of the business processing state.

[0093] Specifically, multiple business process nodes can be executed sequentially, or at least two business process nodes can be executed in parallel.

[0094] It is understandable that in a node sequence, the prerequisite for a later node to be executed is that the execution status of the earlier nodes has been successfully completed.

[0095] like Figure 4As shown in the example, the target business processing system includes three sequential business process nodes: business process node A, business process node B, and business process node C. Business process node A can have two states: successful execution or failed execution. Different execution states of business process node A can generate different business process events. For example, if business process node A executes successfully, an event "Node A Execution Successful Callback" is generated, and the corresponding business processing state is "Business Process Node B Executing," which is used as the status identifier for that state. The corresponding business process event for "Business Process Node B Executing" is the "Node A Execution Successful Callback." If business process node A fails, an event "Node A Execution Failure Callback" is generated, and the corresponding business processing state is "Business Process Node A Execution Failure." The corresponding business process event for "Business Process Node A Execution Failure" is the "Node A Execution Failure Callback." If business process node A is in a successful execution state, business process node B continues execution. Similarly, business process node B can have two states: successful execution or failed execution, and different execution states of business process node B can also generate different business process events. If business process node B executes successfully, an event "Node B Execution Successful" callback is generated. The corresponding business processing status is now "Business Process Node C Executing." The business process events corresponding to "Business Process Node C Executing" include the "Node A Execution Successful" callback and the "Node B Execution Successful" callback. If business process node B fails, an event "Node B Execution Failure" callback is generated. The corresponding business processing status is now "Business Process Node B Execution Failure." The business process events corresponding to "Business Process Node B Execution Failure" include the "Node A Execution Successful" callback and the "Node B Execution Failure" callback. If both business process node A and business process node B are in the "Execution Successful" state, then business process node C continues execution. Similarly, business process node C can have either a "Execution Successful" or "Execution Failure" state, and different execution states of business process node C can generate different business process events. If business process node C executes successfully, an event "Node C Execution Successful" callback is generated. At this time, the corresponding business processing status is marked as "Business Processing Completed." The business process events corresponding to "Business Processing Completed" include the callbacks for "Node A Execution Successful," "Node B Execution Successful," and "Node C Execution Successful." If business process node C fails to execute, an event "Node C Execution Failed" callback is generated. At this time, the corresponding business processing status is marked as "Business Process Node C Execution Failed." The business process events corresponding to "Business Process Node C Execution Failed" include the callbacks for "Node A Execution Successful," "Node B Execution Successful," and "Node C Execution Failed."

[0096] like Figure 5As shown in the figure, in one example, the target business processing system includes four business process nodes, namely business process node D, business process node E, business process node F and business process node H shown in the figure, and... Figure 4 The difference from the example is that, Figure 4 Business process node E and business process node F are parallel.

[0097] Specifically, in Figure 5 In the example shown, business process node D can include two states: successful execution or failed execution. Different execution states of business process node D can generate different business process events. For example, if business process node D executes successfully, an event "Node D Execution Successful Callback" is generated. At this time, the corresponding business processing state is identified as "Business Process Nodes E and F are Executing". The business process event corresponding to "Business Process Node D is Executing Successful Callback" is "Node D Execution Successful Callback". If business process node D fails to execute, an event "Node D Execution Failed Callback" is generated. At this time, the corresponding business processing state is identified as "Business Process Node D Execution Failed". The business process event corresponding to "Business Process Node D Execution Failed Callback" is "Node D Execution Failed Callback". Assuming that business process node D is successfully executed, business process nodes E and F are executed separately. Similarly, business process node E can have two states: successful or failed. Different execution states of business process node E can also generate different business process events. Similarly, business process node F can have two states: successful or failed. Different execution states of business process node F can also generate different business process events. Unlike serial nodes, whether business process node H can be executed depends on the execution states of business process node E and business process node F. Furthermore, assuming that business process node D is successfully executed, the business processing state of the target business process system depends on the execution states of business process node E and business process node F.

[0098] If business process node E executes successfully, an event "Node E Execution Successful" callback is generated. At the same time, business process node F also executes successfully, generating an event "Node F Execution Successful" callback. The corresponding business processing status is marked as "Business Process Node H is Executing." The business process events corresponding to "Business Process Node H is Executing" include the events "Node D Execution Successful," "Node E Execution Successful," and "Node F Execution Successful." If business process node E executes successfully, an event "Node E Execution Successful" callback is generated. At the same time, business process node F fails, generating an event "Node F Execution Failure" callback. The corresponding business processing status is marked as "Business Process Node E Executed Successfully and Business Process Node F Executed Failed." The business process events corresponding to "Business Process Node E Executed Successfully and Business Process Node F Executed Failed" include the events "Node D Execution Successful," "Node E Execution Successful," and "Node F Execution Failure" callback. If business process node E fails, an event "Node D Execution Successful" callback is generated. If a business process node E fails to execute, a callback event is generated. If the business process node F succeeds, a callback event is generated. The corresponding business processing status is marked as "Business process node E failed to execute and business process node F succeeded to execute". The business process events corresponding to this status include the callback events for successful execution of node D, failed execution of node E, and successful execution of node F. If business process node E fails to execute, a callback event is generated. If the business process node F also fails to execute, a callback event is generated. The corresponding business processing status is marked as "Business process node E failed to execute and business process node F failed to execute". The business process events corresponding to this status include the callback events for successful execution of node D, failed execution of node E, and failed execution of node F.

[0099] Assuming that business process nodes D, E, and F all execute successfully, the business processing status of the target business process system depends on the execution status of business process node H. If business process node H fails, an event "H node execution failure callback" is generated. The corresponding business processing status is marked as "Business process node H execution failure." The business process events corresponding to the failure of business process node H include the callbacks for successful execution of nodes D, E, and F, and the callback for failed execution of node H. If business process node H executes successfully, an event "H node execution success callback" is generated. The corresponding business processing status is marked as "Business completion." The business process events corresponding to the "Business completion" status include the callbacks for successful execution of nodes D, E, F, and H.

[0100] like Figure 6As shown, taking a credit card issuance system as the target business processing system as an example, the credit card issuance system includes the following business process nodes: user application, document submission, preliminary review, document receipt, and final review. When a user's application is successfully executed, the corresponding event is the user application event, and the state of the credit card issuance system at this time is the user application state. If the document submission execution state is successful, the event is a document submission success callback, and the corresponding business processing state is preliminary review. This is because after document submission is successful, the target business processing system will execute the next node and will not remain in the instantaneous state of document submission success. In other words, the business processing states in this application are non-instantaneous states, as instantaneous states are difficult to capture. If the document submission execution state is failed, the event is a document submission failure callback, and the corresponding business processing state is document submission failure. If both the user's application and document submission are successful, and the preliminary review execution state is successful, the event is a preliminary review success callback, and the corresponding business processing state is preliminary review. Similarly, during the document receipt process, after a successful initial review, the target business processing system will execute the next business process node, rather than remaining in the instant of successful initial review. If the execution status of the initial review is "execution failed," the event that occurs is the "initial review failed" callback, and the corresponding business processing status is "initial review failed." Assuming the user's card application, document submission, and initial review are all successful, if the document receipt execution status is "execution successful," the event that occurs is the "document receipt successful" callback, and the corresponding business processing status is "final review in progress." Likewise, after successful document receipt, the target business processing system will execute the next business process node, rather than remaining in the instant of successful document receipt. If the execution status of document receipt is "execution failed," the event that occurs is the "document receipt failed" callback, and the corresponding business processing status is "document receipt failed." Assuming the user's card application, document submission, initial review, and document receipt are all successful, if the execution status of the final review is "execution successful," the event that occurs is the "final review successful" callback, and the corresponding business processing status is "final review passed." If the execution status of the final review is "execution failed," the event that occurs is the "final review failed" callback, and the corresponding business processing status is "final review failed."

[0101] The above embodiments illustrate the generation process of the business process event set corresponding to each business processing state in the first database. The following will describe the storage format of the business process event set corresponding to each business processing state in conjunction with specific embodiments.

[0102] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state is stored in the first database in the form of a status event relationship table.

[0103] For each business processing state, at least one generated business process event corresponding to that state is used as the business process event set corresponding to the state identifier of the business processing state, including: (1) Based on each execution state of each business process node, obtain each business process event of the target business processing system; (2) For each business processing state, the first mark is used to mark the event identifier of the generated business process event corresponding to the state identifier of the business processing state, and the second mark is used to mark the event identifier of the ungenerated business process event corresponding to the state identifier of the business processing state, so as to obtain the state event relationship table.

[0104] In the actual implementation process, each business process node in the node sequence is executed sequentially, and a corresponding business process event is generated based on the execution status of each business process node.

[0105] For each business processing state, the event identifiers of business process events that should occur in that business processing state are marked with a first marker; the event identifiers of business process events that should not occur in that business processing state are marked with a second marker.

[0106] The first and second marks can be in the form of pre-set symbols, numbers, graphics, letters, etc.

[0107] Specifically, the table can use the status identifiers of multiple business processing states as the list headers and the event identifiers of each business process event in the target business processing system as the row headers. For each business processing state in the list header, the event identifiers of each business process event in the target business processing system are marked in sequence. The event identifiers of business process events that should occur in the business processing state are marked with the first mark, and the event identifiers of business process events that should not occur in the business processing state are marked with the second mark.

[0108] In one example, as shown in Table 2 below, the target business processing system includes three sequential business process nodes A, B, and C. The execution status of different business process nodes corresponds to different business process events, which can be obtained as follows: A node execution success callback, A node execution failure callback, B node execution success callback, B node execution failure callback, C node execution success callback, and C node execution failure callback. The status indicators of the business processing status can be obtained as follows: business process node A execution failure, business process node B execution in progress, business process node B execution failure, business process node C execution in progress, business process node C execution failure, and business processing completed.

[0109] Table 2: Relationship between Status and Event

[0110] Taking a first marker of 1 and a second marker of 0 as an example, if business process node A executes successfully, an event "Node A Execution Successful Callback" is generated. At this time, the status identifier of the corresponding business processing state is "Business Process Node B is Executing". The event identifier of the business process event corresponding to "Business Process Node B is Executing" is "Node A Execution Successful Callback". In the event identifiers of each business process event corresponding to "Business Process Node B is Executing", the "Node A Execution Successful Callback" is marked as "1", and other business process events are marked as "0". If business process node A fails to execute, an event "Node A Execution Failure Callback" is generated. At this time, the status identifier of the corresponding business processing state is "Business Process Node A Execution Failure". The event identifier of the business process event corresponding to "Business Process Node A Execution Failure" is "Node A Execution Failure Callback". In the event identifiers of each business process event corresponding to "Business Process Node A Execution Failure", the "Node A Execution Failure Callback" is marked as "1", and other business process events are marked as "0". If business process node A is executed successfully, then business process node B continues to execute. If business process node B executes successfully, a "Node B Execution Successful" callback event is generated. At this time, the corresponding business processing status is "Business Process Node C Executing". The event identifiers for the business process events corresponding to the execution of business process node C include the "Node A Execution Successful" callback and the "Node B Execution Successful" callback. In the event identifiers for each business process event corresponding to the execution of business process node C, the "Node A Execution Successful" and "Node B Execution Successful" callbacks are marked as "1", and the event identifiers for other business process events are marked as "0". If business process node B fails, a "Node B Execution Failure" callback event is generated. At this time, the corresponding business processing status is "Business Process Node B Execution Failure". The event identifiers for the business process events corresponding to the execution failure of business process node B include the "Node A Execution Successful" callback and the "Node B Execution Failure" callback. In the event identifiers for each business process event corresponding to the execution failure of business process node B, the "Node A Execution Successful" and "Node B Execution Failure" callbacks are marked as "1", and the event identifiers for other business process events are marked as "0".If both business process node A and business process node B are successfully executed, then business process node C continues execution. If business process node C succeeds, a "Node C Execution Successful" callback event is generated. At this point, the corresponding business processing status is marked as "Business Processing Completed." The event identifiers for the business process events corresponding to "Business Processing Completed" include the "Node A Execution Successful" callback, the "Node B Execution Successful" callback, and the "Node C Execution Successful" callback. Therefore, among the event identifiers for each business process event corresponding to "Business Processing Completed," the corresponding markers for the "Node A Execution Successful" callback, the "Node B Execution Successful" callback, and the "Node C Execution Successful" callback are... If business process node C fails to execute, an event "C Node Execution Failure Callback" is generated. At this time, the status identifier of the corresponding business processing status is "Business Process Node C Execution Failure". The event identifiers of the business process events corresponding to the failure of business process node C include the callbacks for successful execution of node A, successful execution of node B, and failure of node C. In the event identifiers of each business process event corresponding to the failure of business process node C, the callbacks for successful execution of node A, successful execution of node B, and failure of node C are marked as "1", and other business process events are marked as "0".

[0111] Retrieve the target business process event set associated with the current business processing status from the first database, including: The target business process event set is obtained by querying the status event relationship table and finding the business process event that corresponds to the status identifier of the current business processing status and is marked as the first identifier.

[0112] Specifically, you can first query the table row or column corresponding to the status identifier of the current business processing status in the status event relationship table, and then query the target event identifier corresponding to the business process event marked as the first identifier from the event identifiers of the business process events corresponding to the table row or column, thereby obtaining the target business process event set.

[0113] Taking Table 2 above as an example, if the current business processing status is "Business process node C is executing", then the event line corresponding to "Business process node C is executing" can be found in Table 2 above. The markers corresponding to the successful execution callback of node A are "1", the failed execution callback of node A is "0", the successful execution callback of node B is "1", the failed execution callback of node B is "0", the successful execution callback of node C is "0", and the failed execution callback of node C is "0".

[0114] In one example, as shown in Table 3 below, taking a credit card issuance system as the target business processing system, the credit card issuance system includes the following business process nodes: user application, document submission, preliminary review, document receipt, and final review. The execution status of different business process nodes corresponds to different business process events, which can be obtained as follows: application event, document submission success callback, document submission failure callback, preliminary review success callback, document receipt success callback, document receipt failure callback, final review success callback, and final review failure callback. The business processing statuses that can be obtained include: user application, document submission failure, preliminary review in progress, preliminary review failure, document receipt in progress, document receipt failure, final review in progress, final review passed, and final review failed.

[0115] Table 3: Status and Event Relationship Table

[0116] Taking a first marker of 1 and a second marker of 0 as an example, when a user's card application is successfully executed, the corresponding event is the "User Card Application Event." At this time, the credit card issuance system is in the "User Card Application Status." Therefore, in the various issuance process events corresponding to the "User Card Application Status," the "Application Event" is marked as "1," and other issuance process events are marked as "0." If, assuming the user's card application is successful, the execution status of submitting materials is "Successful," the event that occurs is the "Materials Submission Successful Callback." The corresponding business processing status is "Under Initial Review." In the various issuance process events corresponding to "Under Initial Review," the "Application Event" and the "Materials Submission Successful Callback" are marked as "1," and other issuance process events are marked as "0." If, assuming the user's card application is successful, the execution status of submitting materials is "Successful," the event that occurs is the "Materials Submission Successful Callback." The corresponding business processing status is "Under Initial Review." In this case, in the various issuance process events corresponding to "Under Initial Review," the "Application Event" and the "Materials Submission Successful Callback" are marked as "1," and other issuance process events are marked as "0." If the execution status is "Execution Failure," the event that occurs is a "Document Submission Failure Callback." The corresponding business processing status is "Document Submission Failure." In the card issuance process events corresponding to this status, the "Application Event" and "Document Submission Failure Callback" are marked as "1," while other card issuance process events are marked as "0." If the user's card application and document submission are successful, and the initial review execution status is "Execution Successful," the event that occurs is a "Initial Review Successful Callback." The corresponding business processing status is "Receiving Documents." In the card issuance process events corresponding to "Receiving Documents," the "Application Event," "Document Submission Successful Callback," and "Initial Review Successful Callback" are marked as "1," while other card issuance process events are marked as "0." If the initial review execution status is "Execution Failure," the event that occurs... The event is a callback for initial review failure, corresponding to the business processing status of initial review failure. In the card issuance process events corresponding to initial review failure, the events for card application, successful document submission, and initial review failure are marked as "1", while other card issuance process events are marked as "0". If the user's card application, document submission, and initial review are successful, and the document receipt execution status is "execution successful", the event that occurs is a document receipt success callback, corresponding to the business processing status of final review. In the card issuance process events corresponding to final review, the events for card application, successful document submission, successful initial review, and successful document receipt are marked as "1", while other card issuance process events are marked as "0". If the document receipt execution status is "execution failed", the event that occurs is a document receipt success callback. If the event is a receipt failure callback, and the corresponding business processing status is receipt failure, then in the card issuance process events corresponding to receipt failure, the card application event, document submission success callback, initial review success callback, and receipt failure callback are marked as "1", and other card issuance process events are marked as "0". If the user's card application is successful, document submission is successful, initial review is successful, and receipt is successful, and the final review execution status is execution success, then the event that occurs is a final review success callback, and the corresponding business processing status is final review passed. Then in the card issuance process events corresponding to final review passed, the card application event, document submission success callback, initial review success callback, receipt success callback, and final review success callback are marked as "1", and other card issuance process events are marked as "0".If the final review execution status is "execution failed," the event that occurs is a "final review failure callback." The corresponding business processing status is "final review failure." In the card issuance process events corresponding to the final review failure, the following events are marked as "1": application event, document submission success callback, initial review success callback, document receipt success callback, and final review failure callback. Other card issuance process events are marked as "0."

[0117] Taking Table 2 above as an example, if the current business processing status is "receiving", then the event row corresponding to "receiving" can be found in Table 1 above. The event row will be marked as "1" for card application, "1" for successful document submission callback, "0" for successful document failure callback, "1" for successful initial review callback, "0" for failed initial review callback, "0" for successful document receipt callback, "0" for failed document receipt callback, "0" for successful final review callback, and "0" for failed final review callback.

[0118] The following will illustrate the specific process of data verification using Tables 2 and 3 above, with examples.

[0119] like Figure 7 As shown in one example, taking a credit card issuance system as the target business processing system, the data verification process includes: Retrieve credit card application records within a preset time period; For each credit card application record, determine the current processing status, that is, determine the application status of the record; Based on the data verification matrix composed of Table 2 and Table 3 above, the data verification rules for this state are determined; that is, the target card issuance process event corresponding to the current business processing state is queried in conjunction with Table 2, and the target event characteristics corresponding to the target card issuance process event are queried in conjunction with Table 3. Verify the data in this state; that is, determine whether the data characteristics in the credit card application record match the target event characteristics queried by combining Tables 2 and 3. If the data verification is successful, the correct reconciliation information will be recorded; if the data verification determines that there is abnormal data in the card application record, the incorrect account information will be recorded.

[0120] The following will further illustrate the exception alert process when the business record data is abnormal, with reference to specific examples.

[0121] In some possible implementations, if the data verification result indicates that the business record data is abnormal, the method further includes: (1) Identify the business process events to be corrected from multiple first business process events.

[0122] Among them, the event characteristics of the business process events to be corrected do not conform to the target event characteristics or conform to the second event characteristics.

[0123] (2) Send the event records of the business process events to be corrected to the verification server so that the verification server can generate the first alarm information based on the event records of the business process events to be corrected.

[0124] Specifically, you can simply remind the verification server that the business record data is abnormal, or you can further analyze the business record data to determine which business process events in the business record data do not conform to the target event characteristics. That is, in the current business processing state, which event characteristics should have appeared but did not appear, or which event characteristics should not have appeared but did appear in the current business processing state. These are the event characteristics of the business process events that need to be corrected.

[0125] In some possible implementations, the method further includes: From multiple business process nodes of the target business in the target business system, query the business process node to which the business process event to be corrected belongs; Query the terminals to be alerted that are associated with the business process node to which the business process event to be corrected belongs, and send the alarm information to the terminals to be alerted.

[0126] Specifically, different associated reminder terminals can be set up in advance for different business process nodes, and different reminder terminals can be assigned to different business personnel for processing.

[0127] For example, taking a credit card issuance system as the target business processing system, some business personnel are responsible for the initial review of the corresponding card issuance process nodes, while other business personnel are responsible for the final review of the corresponding card issuance process nodes. However, if it is found that the business process node to which the business process event to be corrected belongs is the business process node corresponding to the initial review, then an alarm message will be sent to the terminal to be reminded corresponding to the initial review.

[0128] In practice, different terminals to be reminded can be of different types or of the same type; there is no limitation on this.

[0129] In some possible implementations, each business process node of the target business in the target business system has a corresponding node importance level; Send alarm information to the terminals to be alerted, including: Query the importance level of the business process node to which the business process event to be corrected belongs, and query the reminder method corresponding to the importance level of the node; each importance level of the business process node has its own reminder method. Based on the retrieved notification method, the alarm information will be sent to the terminal to be notified.

[0130] Different reminder methods can be preset for different node importance levels. For example, for business process nodes with relatively higher importance levels, the corresponding reminder methods are relatively more real-time or more urgent; for business process nodes with relatively lower importance levels, the corresponding reminder methods are relatively less urgent.

[0131] For example, email reminders can be used for business process nodes with relatively low importance levels, while instant messaging messages can be sent to the terminal to be reminded for business process nodes with relatively higher importance levels.

[0132] Furthermore, the frequency of reminders can vary depending on the importance level of the node. For example, a business process node with a relatively low importance level might receive an email reminder, while a business process node with a relatively high importance level might receive an instant messaging message sent to the terminal to be reminded at preset intervals.

[0133] like Figure 8 As shown, taking a credit card issuance system as an example, the business in the issuance system includes reconciliation. The data verification server verifies the record data of the transactions to be verified in different reconciliation transactions A, B, and C, respectively, and obtains the data verification results, namely the reconciliation results and reconciliation details shown in the figure. The data verification server can send the data verification results to the reconciliation platform, which generates alarm information and pushes the alarm information to the terminals to be reminded using different reminder methods. The reconciliation platform can also visualize the data verification results, such as generating corresponding charts, so that business personnel can quickly locate abnormal data, i.e., the reconciliation visualization shown in the figure. It can also automatically analyze the reasons for abnormal data based on the data verification results, i.e., error management shown in the figure.

[0134] In some possible implementations, for each target business process event in the target business process event set, before querying the target event characteristics of the target business process event from the second database, the method further includes: (1) Extract the first event identifier of each first business process event from the event records of multiple first business process events; (2) Query the target event identifiers of each target business process event in the target business process event set from the first database; (3) Match the first event identifier of each first business process event with the target event identifier of each target business process event to obtain the third matching result.

[0135] Specifically, before querying the target event features of the target business process event from the second database and matching the event features of the first business process event with the target event features of the target business process event, it is also possible to directly match the first event identifier of the first business process event with the target event identifiers of each target business process event. That is, before matching the feature levels, it is first determined whether the business process event that occurred in the business data record under the current business processing state is the target business process event that should occur.

[0136] For each target business process event in the target business process event set, query the target event characteristics of the target business process event from the second database, including: If the third matching result is that the first event identifier of each first business process event matches the target event identifier of each target business process event, then for each target business process event in the target business process event set, the target event feature of the target business process event is queried from the second database.

[0137] Specifically, if the business process event that occurs in the current business processing state in the business record data is the target business process event that should occur, then it can be further determined whether the business process event that occurs in the business record data matches the target event characteristics of the target business process event that should occur.

[0138] In some possible implementations, the method further includes: If the third matching result is that there is a mismatch between the first event identifier of at least one first business process event and the target event identifier of at least one target business process event, then the event identifier to be corrected that does not match the target event identifier is determined from the first event identifiers of each first business process event. The event identifier to be corrected is sent to the verification server so that the verification server can generate a second alarm message based on the event identifier to be corrected.

[0139] Specifically, if the business process events that occur in the current business processing state are not the target business process events that should occur, then the business record data is abnormal. In this case, we can first find out which target business process events that should have occurred did not occur in the current business processing state, or which first business process events that should not have occurred did occur, so as to quickly locate the abnormal data.

[0140] In the above embodiments, it is first determined whether the business process event occurring in the current business processing state in the business data record is the target business process event that should occur. If the business process event occurring in the current business processing state in the business record data is the target business process event that should occur, it can be further determined whether the business process event occurring in the business record data matches the target event characteristics of the target business process event that should occur. Matching is performed first at the event identifier level and then at the event characteristic level, which can quickly filter out abnormal data and improve data verification efficiency.

[0141] To further illustrate the above data verification method, the following will provide a more detailed explanation in conjunction with the accompanying drawings.

[0142] Taking the target business processing system as a credit card issuance system as an example, the data verification method of this application may include the following process: like Figure 9 As shown, multiple business processing states of the credit card issuance system are obtained, and the issuance process event set corresponding to the status identifier of each business processing state is obtained; the issuance process event set includes at least one issuance process event; that is, the establishment state and event relationship shown in the figure; For each card issuance process event, obtain the event characteristics of the card issuance process event; that is, establish the relationship between the event and the event characteristics as shown in the figure; The card issuance process event set corresponding to each business processing state, and the event characteristics of each card issuance process event, are used to construct a data verification matrix. Based on the data verification matrix, the corresponding data verification rules for each business processing state are determined. For the business record data of the business to be verified, the corresponding target business process event can be queried based on the current business processing status in the business record data, and then the corresponding target event characteristics can be queried. Figure 10 As shown, in the set of credit card application records, based on the data verification matrix corresponding to state A, the corresponding data verification rule A is determined, and the corresponding verification result A is obtained; based on the data verification matrix corresponding to state B, the corresponding data verification rule B is determined, and the corresponding verification result B is obtained; and based on the data verification matrix corresponding to state C, the corresponding data verification rule C is determined, and the corresponding verification result C is obtained. like Figure 11 As shown, based on the data verification results, the data verification results are sent to the reconciliation platform, which then visualizes the data verification results and displays the details of the verification results so that business personnel can process them in a timely manner.

[0143] The aforementioned data verification method generates a first database by pre-acquiring multiple processing states of the target business processing system and the business process event set corresponding to the status identifier of each business processing state; and generates a second database by pre-acquiring the event characteristics of each business process event of the target business system; when the business record data of the business to be verified is obtained, the method queries the target business process event set associated with the status identifier of the current business processing state from the first database, and then queries the target event characteristics of the target business process events from the second database, matching the target event characteristics with each first event characteristic to obtain a first matching result; it can determine whether the first event characteristics in the business data records in the business record data are the event characteristics of the target business events that should occur in the current business processing state, and thus obtain the data verification result of the business record data based on the first matching result of each first business process event, which can verify the business record data to be verified in real time, effectively improving the efficiency of business data verification.

[0144] Furthermore, first determine whether the business process events occurring in the current business processing state in the business data records are the target business process events that should occur. If the business process events occurring in the current business processing state in the business record data are the target business process events that should occur, then we can further determine whether the business process events occurring in the business record data match the target event characteristics of the target business process events that should occur. Matching is performed first at the event identifier level and then at the event characteristic level, which can quickly filter out abnormal data and improve data verification efficiency.

[0145] like Figure 12 As shown, in some possible implementations, a data verification device is provided, comprising: The acquisition module 1201 is used to acquire the business record data of the business to be verified in the target business processing system; the business record data includes the current business processing status of the business to be verified and the event records of multiple first business process events; The first query module 1202 is used to generate a first query request for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, it queries a target business process event set associated with the state identifier of the current business processing state from the first database; wherein, the first database stores a business process event set corresponding to the state identifier of each business processing state in the target business processing system. The second query module 1203 is configured to generate a second query request for each target business process event in the target business process event set; the second query request carries a target event identifier of the target business process event; and query the target event feature corresponding to the target event identifier of the target business process event from the second database based on the second query request; wherein, the second database stores the event features corresponding to the event identifiers of each business process event of the target business system; the event feature of any business process event is used to characterize the business features possessed when the business process event has been generated; The extraction module 1204 is used to, for each first business process event, obtain the record information of the business fields related to the event by parsing the event record, extract the corresponding key business parameters from the record information of the business fields, and use the extracted key business parameters as the first event feature of the first business process event. The first matching module 1205 is used to match the first event feature with each of the target event features for each first business process event to obtain a first matching result; and to obtain the data verification result of the business record data based on the first matching result of each first business process event.

[0146] In some possible implementations, the method further includes a third query module for: The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, a third query request is generated for the second business process event; the third query request carries the second event identifier of the second business process event; based on the third query request, the second event characteristics of each second business process event are queried from the second database. For each first business process event, the first event features are matched with each second event feature to obtain the second matching result; When the first matching module 1205 obtains the data verification result of the business record data based on the first matching result of each first business process event, it is specifically used for: Based on the first and second matching results of each first process event, the data verification results of the business record data are obtained.

[0147] In some possible implementations, a generation module is also included: Obtain multiple business process nodes of the business to be verified in the target business system, sort the business process nodes according to the execution order of the nodes, and obtain the corresponding node sequence; Each business process node in the node sequence is executed sequentially. Based on the execution status of each business process node, a corresponding business process event is generated, and the business processing status corresponding to at least one generated business process event is obtained; the execution status is either successful or failed. Each obtained business processing state is taken as the business processing state of the target business processing system, and a state identifier corresponding to each business processing state is generated; for each business processing state, at least one generated business process event corresponding to the business processing state is taken as the business process event set corresponding to the state identifier of the business processing state.

[0148] In some possible implementations, the set of business process events corresponding to the status identifier of each business processing state is stored in the first database in the form of a status event relationship table; When the generation module, for each business processing state, takes at least one generated business process event corresponding to that state as a set of business process events corresponding to the state identifier of that business processing state, it is specifically used for: Based on each execution state of each business process node, obtain each business process event of the target business processing system. For each business processing state, a first tag is used to mark the event identifier of the generated business process event corresponding to the state identifier of the business processing state, and a second tag is used to mark the event identifier of the ungenerated business process event corresponding to the state identifier of the business processing state, so as to obtain the state event relationship table. When the first query module 1202 queries the target business process event set associated with the current business processing status from the first database, it is specifically used for: The target business process event set is obtained by querying the state event relationship table and finding the business process event that corresponds to the state identifier of the current business processing state and is marked with the first mark.

[0149] In some possible implementations, when the first matching module 1205 obtains the data verification result of the business record data based on the first matching result and the second matching result of each first process event, it is specifically used for: If the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

[0150] In some possible implementations, if the data verification result indicates that the business record data is abnormal, the device further includes a first alarm module, used for: Identify the business process events to be corrected from multiple first business process events; the event characteristics of the business process events to be corrected do not conform to the target event characteristics or conform to the second event characteristics; The event records of the business process events to be corrected are sent to the verification server, so that the verification server can generate the first alarm information based on the event records of the business process events to be corrected.

[0151] In some possible implementations, the device also includes a reminder module for: From multiple business process nodes of the target business in the target business system, query the business process node to which the business process event to be corrected belongs; Query the terminals to be alerted that are associated with the business process node to which the business process event to be corrected belongs, and send the alarm information to the terminals to be alerted.

[0152] In some possible implementations, each business process node of the target business in the target business system has a corresponding node importance level; When the first alarm module sends alarm information to the terminal to be alerted, it is specifically used for: Query the importance level of the business process node to which the business process event to be corrected belongs, and query the reminder method corresponding to the importance level of the node; each importance level of the business process node has its own reminder method. Based on the retrieved notification method, the alarm information will be sent to the terminal to be notified.

[0153] In some possible implementations, the apparatus further includes a second matching module for: Extract the first event identifier of each first business process event from the event records of multiple first business process events; Query the target event identifier of each target business process event in the target business process event set from the first database; The first event identifier of each first business process event is matched with the target event identifier of each target business process event to obtain the third matching result; When the second query module 1203 queries the target event characteristics of each target business process event in the target business process event set from the second database, it is specifically used for: If the third matching result is that the first event identifier of each first business process event matches the target event identifier of each target business process event, then for each target business process event in the target business process event set, the target event feature of the target business process event is queried from the second database.

[0154] In some possible implementations, the device further includes a second alarm module for: If the third matching result is that there is a mismatch between the first event identifier of at least one first business process event and the target event identifier of at least one target business process event, then the event identifier to be corrected that does not match the target event identifier is determined from the first event identifiers of each first business process event. The event identifier to be corrected is sent to the verification server so that the verification server can generate a second alarm message based on the event identifier to be corrected.

[0155] The aforementioned data verification device generates a first database by pre-acquiring multiple processing states of the target business processing system and the business process event set corresponding to the status identifier of each business processing state; and generates a second database by pre-acquiring the event characteristics of each business process event of the target business system; when the business record data of the business to be verified is obtained, the device queries the target business process event set associated with the status identifier of the current business processing state from the first database, and then queries the target event characteristics of the target business process events from the second database, matching the target event characteristics with each first event characteristic to obtain a first matching result; it can determine whether the first event characteristics in the business data records in the business record data are the event characteristics of the target business events that should occur in the current business processing state, and thus obtain the data verification result of the business record data based on the first matching result of each first business process event, which can verify the business record data to be verified in real time, effectively improving the efficiency of business data verification.

[0156] Furthermore, first determine whether the business process events occurring in the current business processing state in the business data records are the target business process events that should occur. If the business process events occurring in the current business processing state in the business record data are the target business process events that should occur, then we can further determine whether the business process events occurring in the business record data match the target event characteristics of the target business process events that should occur. Matching is performed first at the event identifier level and then at the event characteristic level, which can quickly filter out abnormal data and improve data verification efficiency.

[0157] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0158] This application provides an electronic device including a memory, a processor, and a computer program stored in the memory. When the processor executes the computer program stored in the memory, it can implement the method in any optional embodiment of this application. Compared with the prior art, it can achieve real-time verification of business record data to be verified, effectively improving the efficiency of business data verification.

[0159] In one alternative embodiment, an electronic device is provided, such as Figure 13 As shown, Figure 13 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this disclosure.

[0160] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0161] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0162] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0163] The memory 4003 is used to store computer programs that execute embodiments of the present disclosure, and is controlled by the processor 4001 to execute them. The processor 4001 is used to execute the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0164] Based on the same principle as the method provided in the embodiments of this application, the embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the corresponding content of the aforementioned method embodiments.

[0165] This application also provides a computer program product, which includes a computer program that, when executed by a processor, can implement the corresponding content of the aforementioned method embodiments.

[0166] It should be noted that the terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0167] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0168] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A data verification method, characterized in that, The method includes: Obtain the business record data of the business to be verified from the target business processing system; the business record data includes the current business processing status of the business to be verified and event records of multiple first business process events; A first query request is generated for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, a target business process event set associated with the state identifier of the current business processing state is queried from the first database; wherein, the first database stores a business process event set corresponding to the state identifier of each business processing state in the target business processing system; For each target business process event in the target business process event set, a second query request is generated for the target business process event; the second query request carries the target event identifier of the target business process event; based on the second query request, the target event feature corresponding to the target event identifier of the target business process event is queried from the second database; wherein, the second database stores the event features corresponding to the event identifiers of each business process event of the target business system; the event feature of any business process event is used to characterize the business features possessed when the business process event has been generated; For each first business process event, the record information of the business fields related to the event is obtained by parsing the event record, the corresponding key business parameters are extracted from the record information of the business fields, and the extracted key business parameters are used as the first event feature of the first business process event. For each first business process event, the first event feature is matched with each of the target event features to obtain a first matching result; based on the first matching result of each first business process event, the data verification result of the business record data is obtained.

2. The method according to claim 1, characterized in that, The method further includes: The business process events other than the target business process event in each business process event of the target business processing system are regarded as the second business process events; For each second business process event, a third query request is generated for the second business process event; the third query request carries a second event identifier of the second business process event; based on the third query request, the second event characteristics of each second business process event are queried from the second database; For each first business process event, the first event feature is matched with each of the second event features to obtain a second matching result; The data verification result of the business record data obtained based on the first matching result of each first business process event includes: Based on the first and second matching results of each first process event, the data verification result of the business record data is obtained.

3. The method according to claim 1, characterized in that, The business process event set corresponding to the status identifier of each business processing status stored in the first database is generated based on the following method: Obtain multiple business process nodes of the business to be verified in the target business system, sort the business process nodes according to the node execution order, and obtain the corresponding node sequence; Each business process node in the node sequence is executed sequentially. Based on the execution status of each business process node, a corresponding business process event is generated, and the business processing status corresponding to at least one generated business process event is obtained. The execution status is either successful or failed. Each obtained business processing state is taken as the business processing state of the target business processing system, and a state identifier corresponding to each business processing state is generated; for each business processing state, at least one generated business process event corresponding to the business processing state is taken as the business process event set corresponding to the state identifier of the business processing state.

4. The method according to claim 3, characterized in that, The set of business process events corresponding to the status identifier of each business processing status is stored in the first database in the form of a status event relationship table; For each business processing state, the step of taking at least one generated business process event corresponding to the business processing state as a set of business process events corresponding to the state identifier of the business processing state includes: Based on each execution state of each business process node, obtain each business process event of the target business processing system. For each business processing state, a first tag is used to mark the event identifier of the generated business process event corresponding to the state identifier of the business processing state, and a second tag is used to mark the event identifier of the ungenerated business process event corresponding to the state identifier of the business processing state, so as to obtain the state event relationship table. The step of querying the target business process event set associated with the current business processing status from the first database includes: The target business process event set is obtained by querying the state event relationship table and finding the business process event that corresponds to the state identifier of the current business processing state and is marked with the first mark.

5. The method according to claim 2, characterized in that, The data verification result of the business record data obtained based on the first matching result and the second matching result of each first process event includes: If the first matching result of each first business process event is that the first event feature matches the target event feature, and the second matching result is that the first event feature does not match the second event feature of each second business process event, then the data verification result indicates that the business record data is normal data. If the first matching result indicates that the first event feature does not match the target event feature, or if the second matching result indicates that the first event feature matches the second event feature of any second business process event, then the data verification result indicates that the business record data is abnormal data.

6. The method according to claim 5, characterized in that, If the data verification result indicates that the business record data is abnormal, the method further includes: From multiple first business process events, identify the business process events to be corrected; the event characteristics of the business process events to be corrected do not conform to the target event characteristics or conform to the second event characteristics; The event records of the business process events to be corrected are sent to the verification server, so that the verification server generates a first alarm message based on the event records of the business process events to be corrected.

7. The method according to claim 6, characterized in that, The method further includes: Query the business process node to which the business process event to be corrected belongs from multiple business process nodes of the target business in the target business system; Query the terminal to be reminded that is associated with the business process node to which the business process event to be corrected belongs, and send the alarm information to the terminal to be reminded.

8. The method according to claim 7, characterized in that, Each business process node in the target business system has a corresponding node importance level. Sending the alarm information to the terminal to be alerted includes: Query the node importance level corresponding to the business process node to which the business process event to be corrected belongs, and query the reminder method corresponding to the node importance level; wherein, each node importance level corresponds to a business process node with its own reminder method; The alarm information is sent to the terminal to be alerted based on the retrieved alert method.

9. The method according to claim 1, characterized in that, Before querying the target event characteristics corresponding to the event identifier of the target business process event from the second database based on the second query request, the method further includes: Extract the first event identifier of each first business process event from the event records of the plurality of first business process events; Query the target event identifier of each target business process event in the target business process event set from the first database; The first event identifier of each first business process event is matched with the target event identifier of each target business process event to obtain the third matching result; For each target business process event in the target business process event set, querying the target event characteristics of the target business process event from the second database includes: If the third matching result is that the first event identifier of each first business process event matches the target event identifier of each target business process event, then for each target business process event in the target business process event set, the target event feature of the target business process event is queried from the second database.

10. The method according to claim 9, characterized in that, The method further includes: If the third matching result is that there is a mismatch between the first event identifier of at least one first business process event and the target event identifier of at least one target business process event, then the event identifier to be corrected that does not match the target event identifier is determined from the first event identifiers of each first business process event. The event identifier to be corrected is sent to the verification server, so that the verification server generates a second alarm message based on the event identifier to be corrected.

11. A data verification device, characterized in that, The device includes: The acquisition module is used to acquire the business record data of the business to be verified in the target business processing system; the business record data includes the current business processing status of the business to be verified and event records of multiple first business process events; The first query module is used to generate a first query request for the current business processing state; the first query request carries a state identifier corresponding to the current business processing state; based on the first query request, it queries a target business process event set associated with the state identifier of the current business processing state from the first database; wherein, the first database stores a business process event set corresponding to the state identifier of each business processing state in the target business processing system. The second query module is used to generate a second query request for each target business process event in the target business process event set; the second query request carries a target event identifier of the target business process event; and queries the second database for the target event feature corresponding to the target event identifier of the target business process event based on the second query request; wherein, the second database stores the event features corresponding to the event identifiers of each business process event of the target business system; the event feature of any business process event is used to characterize the business features possessed when the business process event has been generated; The extraction module is used to obtain the record information of the business fields related to the event by parsing the event record for each first business process event, extract the corresponding key business parameters from the record information of the business fields, and use the extracted key business parameters as the first event feature of the first business process event. The first matching module is used to match the first event feature with each of the target event features for each first business process event to obtain a first matching result; and to obtain the data verification result of the business record data based on the first matching result of each first business process event.

12. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method of any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-10.

Images