Automatic product application message checking method and related product

Abstract

The invention discloses an automatic product application message checking method and a related product. The method comprises the following steps: acquiring a plurality of to-be-checked product application messages of a product application; performing analysis processing on each to-be-checked product application message, and determining a timestamp corresponding to each to-be-checked product application message; screening the plurality of to-be-checked product application messages based on the timestamp corresponding to each to-be-checked product application message to obtain the screened to-be-checked product application message; obtaining the transaction quantity of the product application; and checking the screened to-be-checked product application messages and the transaction quantity of the product applications to obtain a checking result. According to the method and the device, the problems of message loss, repetition or abnormal transmission and the like can be effectively identified, the verification capability of message consistency is remarkably enhanced, automatic processing of product application message verification is realized, and the verification efficiency is effectively improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for verifying messages in automated product applications and related products. Background Technology

[0002] With the development of fintech, core banking systems are gradually migrating from centralized to distributed architectures. As part of this transformation, the distributed core public ledger plays a crucial role, providing basic accounting components and public ledger processing capabilities for various product applications, including funds, wealth management, credit cards, and corporate deposits. In this architecture, transaction details from product applications are transmitted asynchronously via Kafka for subsequent detailed processing and reconciliation. To avoid accounting processing anomalies (such as discrepancies between totals and totals, or loan-to-value imbalances) caused by Kafka message loss, product applications first generate transaction details through the accounting interface and save them to a local message table. Then, the data acquisition component sends this information via Kafka to the corresponding product application topic. The public ledger module subscribes to and consumes information from these topics, ultimately storing the transaction details in a transaction detail table.

[0003] Since verifying product application messages may involve more than 20 systems, traditional manual verification methods are inefficient, difficult to coordinate, and lack timeliness, potentially leading to untimely investigation of accounting anomalies. Furthermore, the verification process usually requires operations personnel to write SQL scripts to query messages, which not only demands a certain technical background from the operators but is also prone to errors, affecting subsequent anomaly investigations and debit / credit balance checks. Especially when dealing with a large number of transaction details (e.g., five types of data tables: quick, online transaction-by-transaction, online summary, batch, and account closure), using SQL scripts results in low performance and long processing times, leading to a waste of manpower and time. Summary of the Invention

[0004] To address the aforementioned issues, this application provides an automated product application message verification method and related products, which enables automated product application message verification and improves the efficiency of product application message verification.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] The first aspect of this application provides a method for verifying application messages in an automated product, the method comprising:

[0007] Retrieve multiple pending product application messages;

[0008] Each product application message to be verified is parsed and processed to determine the timestamp corresponding to each product application message to be verified;

[0009] Multiple product application messages to be verified are filtered based on the timestamp corresponding to each message to be verified, resulting in the filtered product application messages to be verified.

[0010] Obtain the number of transactions for the product application;

[0011] The filtered product application messages and the number of transactions for each product application are verified to obtain the verification results.

[0012] Optionally, obtaining multiple product application messages to be verified specifically includes:

[0013] Retrieve multiple product application messages to be filtered;

[0014] Determine the data storage location for each product application message to be filtered:

[0015] If the data storage locations corresponding to multiple product application messages to be filtered are all the same, then the multiple product application messages to be filtered will be output as multiple product application messages to be verified.

[0016] If the data storage locations corresponding to multiple product application messages to be filtered are inconsistent, return to the step of retrieving multiple product application messages to be filtered.

[0017] Optionally, the step of filtering multiple product application messages to be verified based on the timestamp corresponding to each message to be verified, to obtain the filtered product application messages to be verified, specifically includes:

[0018] Determine whether the timestamps corresponding to multiple product application messages to be verified all meet the preset time threshold, and obtain the first judgment result;

[0019] If the first judgment result is yes, then multiple product application messages to be verified will be output as filtered product application messages to be verified.

[0020] If the first judgment result is negative, then the product application messages to be verified that do not meet the preset time threshold will be deleted, and the filtered product application messages to be verified will be obtained.

[0021] Optionally, obtaining the number of transactions for the product application specifically includes:

[0022] Obtain multiple transaction tables for product applications according to preset time conditions;

[0023] Multi-threaded features are used to query multiple transaction tables to determine the number of transactions for the product application.

[0024] Optionally, the method further includes:

[0025] Obtain the timestamp determination method and multiple pending product application messages;

[0026] If the timestamp determination method includes the first setting method, then the time of obtaining each pending product application message is set as the timestamp of the pending product application message.

[0027] If the timestamp determination method includes the second setting method, then the offset is determined, and the timestamp of each product application message to be processed is determined based on the offset;

[0028] Each pending product application message is entered into the database according to its timestamp.

[0029] Optionally, the verification result includes verification success or verification failure; the verification of the filtered product application messages and the number of transactions of the product applications to obtain the verification result specifically includes:

[0030] The filtered product application messages and the number of transactions for each product application are verified to obtain the verification results.

[0031] If the verification result includes "verification successful", then the verification ends.

[0032] If the verification result includes verification failure, an error message is generated, and the application messages of the filtered products to be verified are corrected based on the error message.

[0033] A second aspect of this application provides an automated product application message verification device, the automated product application message verification device comprising:

[0034] The first acquisition module is used to acquire multiple product application messages to be verified from the product application.

[0035] The parsing module is used to parse and process each product application message to be verified and determine the timestamp corresponding to each product application message to be verified.

[0036] The filtering module is used to filter multiple product application messages to be verified based on the timestamp corresponding to each product application message to be verified, and obtain the filtered product application messages to be verified.

[0037] The second acquisition module is used to acquire the number of transactions for the product application;

[0038] The verification module is used to verify the filtered product application messages and the number of transactions of the product applications to obtain the verification results.

[0039] A third aspect of this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the automated product application message verification method provided in the first aspect.

[0040] The fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the automated product application message verification method provided in the first aspect.

[0041] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the automated product application message verification method provided in the first aspect.

[0042] Compared with the prior art, this application has the following beneficial effects:

[0043] This application includes: obtaining multiple product application messages to be verified; parsing and processing each product application message to determine the timestamp corresponding to each message; filtering the multiple product application messages based on the timestamp of each message to obtain the filtered product application messages; obtaining the transaction quantity of the product application; and verifying the filtered product application messages and the transaction quantity of the product application to obtain the verification result.

[0044] This application automatically acquires messages to be verified from product applications, parses the message content to extract timestamp information, and then filters the messages according to a set time range, retaining only valid data within the target time period. This improves the targeting, accuracy, and processing efficiency of the verification process. Furthermore, it compares the number of filtered messages with the actual number of transactions in the product application, effectively identifying issues such as message loss, duplication, or transmission anomalies. This significantly enhances the message consistency verification capability, automates the message verification process in product applications, and effectively improves verification efficiency. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 A flowchart illustrating an automated product application message verification method provided in this application embodiment;

[0047] Figure 2 A schematic diagram illustrating the determination of a timestamp as provided in an embodiment of this application;

[0048] Figure 3 An application diagram illustrating transaction volume statistics provided in this application embodiment:

[0049] Figure 4 This is a structural diagram of an automated product application message verification device provided in an embodiment of this application. Detailed Implementation

[0050] As described earlier, traditional manual reconciliation methods involve data comparison across multiple systems, resulting in low overall process efficiency, significant challenges in cross-team collaboration and resource coordination, and slow response times. This makes it difficult to meet the timeliness requirements for handling accounting anomalies in critical business scenarios. Furthermore, this process typically relies on operations personnel manually writing SQL scripts to extract and compare message data. This not only demands high technical skills from operators but is also prone to human error leading to inaccurate data comparison results, thus affecting the efficiency of anomaly investigation and the accuracy of debit / credit balance verification. Especially when dealing with large volumes of transaction details and complex structures (such as tables containing five types of detail tables: quick, online transaction-by-transaction, online summary, batch, and account closure), the SQL script-based data query method suffers from low execution efficiency and long processing times.

[0051] In view of the above problems, this application provides an automated product application message verification generation method and related products. The method includes: obtaining multiple product application messages to be verified; parsing each product application message to be verified to determine the timestamp corresponding to each product application message; filtering the multiple product application messages to be verified based on the timestamp corresponding to each product application message to obtain the filtered product application messages to be verified; obtaining the transaction quantity of the product application; and verifying the filtered product application messages to be verified with the transaction quantity of the product application to obtain the verification result.

[0052] This application obtains the messages to be verified from product applications, parses them to extract timestamp information, and then filters the messages based on the timestamps to ensure that only valid data within a specified time period is processed, thereby improving the accuracy and efficiency of verification. At the same time, it combines the actual transaction volume of the product applications for consistency comparison, thereby accurately identifying message loss or anomalies, improving the accounting system's ability to verify message consistency in key scenarios, realizing automated product application message verification, and improving the efficiency of product application message verification.

[0053] Explanation of relevant professional terms:

[0054] Kafka: A distributed publish-subscribe messaging system written in Java. It was designed to handle high-throughput real-time data streams and can function as a message middleware, a storage system, and also supports streaming data processing frameworks.

[0055] Job scheduling platform: A system-level software tool used to coordinate and manage the execution of various tasks (jobs) in a computing environment. Its core objective is to achieve stable operation of large-scale jobs through intelligent resource allocation, task orchestration, and process control.

[0056] Reflection: A highly flexible mechanism suitable for framework development, which allows programs to dynamically obtain class information, manipulate class attributes and methods at runtime, and even create objects and call methods at runtime.

[0057] ID_SHARD: Database sharding key, a key field in a distributed database that determines the location of data distribution. It can be used to calculate the specific sharding node for data storage (in this application, it refers to set).

[0058] Abnormal Accounts: After the public accounts module receives transaction details data sent by various product applications, it will summarize and process the details data according to multiple dimensions and perform loan balance verification. Transaction details data with unbalanced loans are considered abnormal accounts.

[0059] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0060] Figure 1 A flowchart of an automated product application message verification method provided in this application embodiment is shown below. Figure 1 As shown, an automated product application message verification method includes:

[0061] S101: Retrieve multiple pending product application messages.

[0062] Automatically extracts message data to be verified from the product application's local message table; message format can be JSON, XML, or database records; supports scheduled tasks or manual triggering to retrieve data; data collection can be achieved through API calls, message queue subscriptions, or direct database connections. For example, after a transaction is completed, the product application writes the transaction details to the local message table through the accounting interface. A scheduled task reads messages to be verified from this table every 5 minutes.

[0063] It automates message collection, reducing manual intervention; supports multiple data formats and collection methods, making it highly adaptable; and improves the real-time performance and completeness of the verification process.

[0064] S102: Parse and process each product application message to be verified, and determine the timestamp corresponding to each product application message to be verified.

[0065] The system performs structured parsing of each message; extracts timestamp fields such as timestamp and create_time; the timestamp format can be a standard time format (such as ISO8601) or a Unix timestamp; and supports custom field mapping to adapt to message formats of different systems.

[0066] It enables structured message processing, facilitating subsequent filtering and comparison; supports timestamp recognition for messages from multiple formats and sources; and enhances the system's control over message timeliness.

[0067] S103: Filter multiple product application messages to be verified based on the timestamp corresponding to each product application message to be verified, and obtain the filtered product application messages to be verified.

[0068] Users or the system can set a time window (e.g., "2025-07-15 00:00:00 to 2025-07-15 23:59:59"); compare whether the timestamp of each message falls within this time range; only messages that meet the time range are retained, and invalid or historical data is filtered out; the system supports flexible configuration of the time window to adapt to different business scenarios (e.g., disaster recovery drills, year-end settlements, etc.). For example, if the system sets the time window to "2025-07-15 all day", it can filter out all messages with timestamps within this range, totaling 980 messages.

[0069] Reduce interference from invalid data and improve verification efficiency; enhance the accuracy and business relevance of verification results; support flexible configuration to adapt to various scenario requirements.

[0070] S104: Obtain the number of transactions for the product application.

[0071] Automatically retrieves the total number of transactions from the product application's transaction logs, core accounting system, or monitoring platform; supports counting transactions by time window; data sources can include databases, API calls, log files, etc.; configurable for automatic scheduled retrieval or on-demand querying. For example, by calling the product application's API / api / trade / count?date=2025-07-15, the number of transactions for the day is retrieved as 1000.

[0072] It enables automated acquisition of transaction volume; provides accurate benchmark data for comparison; reduces errors in manual statistics; and improves the reliability of comparison results.

[0073] S105: Verify the filtered product application messages and the number of transactions for the product applications to obtain the verification results.

[0074] The system compares the number of filtered messages with the number of transactions. If the numbers match, it outputs "Messages Match"; if they don't match, it outputs "Messages Inconsistent" and marks it as an anomaly. It can further generate an anomaly report, trigger alarms, or invoke repair mechanisms. The system supports visual display of the verification results for easy viewing and handling by operations and maintenance personnel. For example, message count: 980; transaction count: 1000; verification result: messages inconsistent, marked as an anomaly.

[0075] Quickly identify message loss, duplication, or transmission anomalies; support automatic anomaly marking and alerts; provide data support for subsequent abnormal accounting processing; and achieve full automation of the verification process, improving efficiency and accuracy.

[0076] The above describes the main technical solution of this application. Further implementations of the main technical solution are now introduced. Details are as follows:

[0077] Regarding the acquisition of multiple pending product application messages in S101, this application provides an optional embodiment:

[0078] Retrieve multiple product application messages to be filtered.

[0079] Determine the data storage location for each product application message to be filtered.

[0080] If the product application messages to be filtered are stored in a distributed manner, then the key fields for determining the distribution location of each product application message to be filtered are used to calculate the specific shard location (i.e., data storage location) of the data storage corresponding to each product application message to be filtered.

[0081] If the data storage locations corresponding to multiple product application messages to be filtered are all the same, then the multiple product application messages to be filtered will be output as multiple product application messages to be verified.

[0082] If the data storage locations corresponding to multiple product application messages to be filtered are inconsistent, return to the step of retrieving multiple product application messages to be filtered.

[0083] In practical applications, a "majority rule" mechanism can also be used to filter multiple product application messages with inconsistent storage locations. For example, multiple product application messages with inconsistent storage locations can be sorted, and the data storage location of the second product application message can be determined based on the sorting order. If they are inconsistent, a database transaction is committed first, and then the data is inserted into the verification table. This process is repeated to obtain multiple product application messages to be verified.

[0084] In this embodiment, this application introduces a data storage location consistency judgment mechanism to ensure that message data entering the subsequent verification process has a unified data source, avoiding verification deviations or incorrect identifications caused by scattered data storage or mixed messages. It ensures that all messages to be verified originate from the same storage location, avoiding distortion of comparison results due to inconsistent data sources; effectively identifies data distribution inconsistencies caused by system anomalies, message routing errors, etc.; prevents accounting anomalies caused by mixed messages entering the verification process; and achieves automatic verification of message sources, reducing manual intervention and improving operational efficiency. It is particularly suitable for scenarios in financial systems where product applications and public accounting modules transmit data via asynchronous communication methods such as Kafka.

[0085] The above embodiments describe in detail the method for obtaining product application messages to be verified. However, given that the number of product application messages to be verified is generally large, the messages can be filtered based on timestamps to lay the foundation for improving verification efficiency. Specifically, for S103, multiple product application messages to be verified are filtered based on the timestamp corresponding to each message to be verified to obtain the filtered product application messages to be verified. This application provides a specific embodiment:

[0086] The system determines whether the timestamps corresponding to multiple product application messages to be verified all meet the preset time threshold, and obtains the first judgment result.

[0087] The preset time threshold can be set according to the actual situation. For example, the preset time threshold can be set as the current time minus the offset. The offset can be any value. For example, if the offset is half an hour, then the preset time threshold is half an hour before the current time.

[0088] If the first judgment result is yes, then multiple product application messages to be verified will be output as filtered product application messages to be verified.

[0089] If the first judgment result is negative, then the product application messages to be verified that do not meet the preset time threshold will be deleted, and the filtered product application messages to be verified will be obtained.

[0090] For example, if the current time is 10:30 and the offset is 30 minutes, then the preset time threshold is 10:00. If the transaction time of the product application message to be verified is 09:40, it means that the product application message to be verified does not meet the preset time threshold, and the product application message to be verified is deleted. If the transaction time of the product application message to be verified is 10:06, it means that the product application message to be verified meets the preset time threshold, and the product application message to be verified is retained.

[0091] This application does not limit the method for determining the timestamp. As an optional embodiment, it obtains multiple pending product application messages of the product application and the timestamp determination method.

[0092] If the timestamp determination method includes the first setting method, then the time of obtaining each pending product application message is set as the timestamp of the pending product application message.

[0093] If the timestamp determination method includes the second setting method, then the offset is determined, and the timestamp of each product application message to be processed is determined based on the offset.

[0094] Each pending product application message is entered into the database according to its timestamp.

[0095] Because the running times of the various sub-nodes of the job scheduling platform are inconsistent, data from the same province may be counted on different sub-nodes. If a unified timestamp is not generated in advance, it will be impossible to count the total number of messages from a certain province. Figure 2 A schematic diagram illustrating the determination of a timestamp provided in an embodiment of this application, as shown below. Figure 2 As shown, this application generates a unified timestamp in two ways: the first is for the user to directly input the timestamp, which is convenient for subsequent message verification. If problems occur, retrying can be performed to recount the number of messages generated during that period; the second is for the user to input the offset, and the timestamp is generated by the method of [current time - offset]. The advantage of this method is that the timestamp is dynamically generated, and there is a default offset as a fallback, so the user does not need to configure it manually.

[0096] The above describes in detail the method for filtering product application messages to be verified. After determining the filtered product application messages to be verified, the filtered product application messages and the transaction quantity of the product application can be verified. Regarding S104 obtaining the transaction quantity of the product application, this application also provides a specific embodiment:

[0097] Obtain multiple transaction tables for the product application according to preset time conditions.

[0098] Multi-threaded features are used to query multiple transaction tables to determine the number of transactions for the product application.

[0099] This application primarily determines the number of transactions through multi-threaded features. For example, it utilizes Java's CompletableFuture and Python's concurrent and futures.ThreadPoolExecutor to implement multi-threaded asynchronous queries. After all threads have completed their execution, the counting results returned by each thread are aggregated to calculate the total number of transactions.

[0100] This application also provides a specific application embodiment. Figure 3 This application provides an schematic diagram of a transaction volume statistics method, as shown in the embodiments of this application. Figure 3 As shown, the process begins; input parameters (offset); obtain the same timestamp; filter data whose transaction details for the current accounting date are less than [unified timestamp - offset] and have been successfully sent; determine whether it is a single table or multiple tables (i.e., determine whether the successfully sent data is from a single table or multiple tables). If it is a single table, directly query EXP_MSG_REG to generate a message, which is then sent to the public finance component by the data acquisition component, and ends. If it is multiple tables, use multi-threaded queries (querying EXP_MSG_REG_1, EXP_MSG_REG_2, EXP_MSG_REG_3, EXP_MSG_REG_4, EXP_MSG_REG_5, EXP_MSG_REG_6, and EXP_MSG_REG_7, etc., one by one) to generate messages, which are then sent to the public finance component by the data acquisition component, and ends. This application is equipped with three parameters: sharding key, topic prefix, and time offset. The sharding key is the list of ID_SHARDs in the message table. It's recommended to configure it according to the ID_SHARDs under the same set node in the database to avoid cross-database queries and improve performance. The topic is where you need to count the number of messages delivered for a specific Kafka topic, mainly for verifying transaction details (with the TRDTAL suffix). The time offset is mainly for considering retrying in case of sending errors. Considering the processing capabilities of sending mirrors, an offset of 15 minutes is recommended. This component uses reflection to automatically adapt to single-table and multi-table modes of the local message table. In multi-table mode, a multi-threaded concurrent approach is used for message data statistics to further improve the performance of message count statistics.

[0101] This application achieves efficient transaction quantity statistics by introducing a multi-threaded parallel query mechanism combined with time-based filtering of transaction tables. It utilizes multi-threaded concurrent processing of multiple transaction tables, significantly reducing overall query time. It meets the real-time / near real-time statistical needs of critical business scenarios such as year-end settlement and disaster recovery drills. By rationally scheduling thread resources, it improves the utilization efficiency of server CPU and I / O. It enables automatic transaction quantity statistics, reducing manual operation costs and the probability of errors. Preset time conditions are configurable, supporting statistical needs at different time granularities (such as day, hour, minute).

[0102] Regarding step S105, which verifies the filtered product application messages and the number of transactions for each product application to obtain the verification results, this application provides an optional embodiment:

[0103] The filtered product application messages and the number of transactions of the product applications are checked to obtain the check results; the check results include check success or check failure.

[0104] If the verification result includes "verification successful", then the verification ends.

[0105] If the verification result includes verification failure, an error message is generated, and the application messages of the filtered products to be verified are corrected based on the error message.

[0106] This application mainly consists of two parts: consumer processing and message verification batch processing. Consumer processing is mainly responsible for consuming relevant topics and parsing fields such as verification timestamp, topic name, transaction province, and number of entries in the message. In order to avoid cross-shard operations, it is necessary to obtain its set number first. If the set number is different from the set number of the previous data, a database transaction needs to be committed first, and then the current data is inserted into the verification table. The message verification batch mainly filters batch timestamps prior to [current time - offset], queries the corresponding transaction volume, and compares it with the data volume in the transaction details sent by each product application. Since the public accounting module's transaction details are divided into five tables—Quick, Online Transaction-by-Transaction, Online Summary, Batch, and Account Closure—and the data volume is enormous, a multi-threaded feature mode is used to query the transaction detail data volume. If the verification is successful, the success status of the landing table is updated; if the verification fails, an error log is logged and an error table is set up. The error information includes the subject, transaction province, verification timestamp, number of entries in the product application, number of entries in the public accounting module, and the difference. Subsequent batches that fail to verify will be retried. If multiple rounds of verification fail, it indicates that message sending by the product application may be congested or that the consumption latency is long, requiring an alert mechanism from the operations and maintenance monitoring platform.

[0107] This application automates message reconciliation between various product applications and the public accounting module, significantly improving reconciliation efficiency and effectively reducing labor costs. This application configures two methods for dynamically generating unified timestamps to ensure time consistency among nodes in the job scheduling platform when counting message counts, and supports automatic retries for batches with reconciliation anomalies.

[0108] By leveraging reflection, this application can automatically adapt to the single-table or multi-table structure of the local message table. In multi-table mode, it improves message statistics performance through multi-threaded concurrent queries. Simultaneously, during message verification, multi-threading is used to count the number of messages and query transaction detail data in parallel, further improving overall verification efficiency.

[0109] Furthermore, this application enhances the real-time performance of message verification by configuring a real-time batch processing template, automatically triggering a retry mechanism for batches that fail to verify. When the number of retries exceeds a preset threshold, an alarm will be issued by the operation and maintenance monitoring platform, thereby further ensuring the consistency of asynchronous message transmission. This application effectively avoids the maintenance difficulty and statistical errors caused by traditional reliance on manually written SQL scripts, improving the response speed and troubleshooting capabilities for abnormal accounting issues.

[0110] Figure 4 A structural diagram of an automated product application message verification device provided in this application embodiment is shown below. Figure 4 As shown, based on the automated product application message verification method provided in the preceding embodiments, this application also provides an automated product application message verification device, including:

[0111] The first acquisition module is used to acquire multiple product application messages to be verified.

[0112] The parsing module is used to parse and process each product application message to be verified, and determine the timestamp corresponding to each product application message.

[0113] The filtering module is used to filter multiple product application messages to be verified based on the timestamp corresponding to each product application message to be verified, and obtain the filtered product application messages to be verified.

[0114] The second acquisition module is used to acquire the number of transactions for the product application.

[0115] The verification module is used to verify the filtered product application messages and the number of transactions of the product applications to obtain the verification results.

[0116] As an optional embodiment, the first acquisition module specifically includes:

[0117] The "Information to be Filtered" unit is used to obtain multiple product application messages to be filtered.

[0118] The storage location determination unit is used to determine the data storage location corresponding to each product application message to be filtered.

[0119] The first judgment unit is used to output multiple product application messages to be filtered as multiple product application messages to be verified if the data storage locations corresponding to multiple product application messages to be filtered are all consistent.

[0120] The second judgment unit is used to return to the filter information determination unit if there are inconsistencies in the data storage locations corresponding to multiple product application messages to be filtered.

[0121] As an optional embodiment, the filtering module specifically includes:

[0122] The third judgment unit is used to determine whether the timestamps corresponding to multiple product application messages to be verified all meet the preset time threshold, and to obtain the first judgment result.

[0123] The fourth judgment unit is used to output multiple product application messages to be verified as filtered product application messages if the first judgment result is yes.

[0124] The fifth judgment unit is used to delete the product application messages to be checked that do not meet the preset time threshold if the first judgment result is negative, so as to obtain the filtered product application messages to be checked.

[0125] As an optional embodiment, the second acquisition module is specifically used for:

[0126] Retrieve multiple transaction tables for the product application according to preset time conditions; use multi-threaded features to query multiple transaction tables to determine the number of transactions for the product application.

[0127] As an optional embodiment, the device further includes:

[0128] The third acquisition module is used to acquire multiple pending product application messages based on the timestamp determination method and the product application.

[0129] The first judgment module is used to set the time of obtaining each pending product application message as the timestamp of the pending product application message if the timestamp determination method includes the first setting method.

[0130] The second judgment module is used to determine the offset if the timestamp determination method includes the second setting method, and to determine the timestamp of each product application message to be processed based on the offset.

[0131] The storage module is used to transmit each pending product application message to the database according to the timestamp of each pending product application message.

[0132] As an optional embodiment, the verification result includes verification success or verification failure; the verification module is specifically used for:

[0133] The filtered product application messages to be verified and the number of transactions of the product applications are verified to obtain the verification result; if the verification result includes verification success, the verification ends; if the verification result includes verification failure, an error message is generated, and the filtered product application messages to be verified are corrected based on the error message.

[0134] This application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement an automated product application message verification method.

[0135] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements an automated product application message verification method.

[0136] This application provides a computer program product, including a computer program that, when executed by a processor, implements an automated product application message verification method.

[0137] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and equipment embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and equipment embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0138] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for verifying application messages in automated products, characterized in that, The method for verifying application messages of automated products includes: Retrieve multiple pending product application messages; Each product application message to be verified is parsed and processed to determine the timestamp corresponding to each product application message to be verified; Multiple product application messages to be verified are filtered based on the timestamp corresponding to each message to be verified, resulting in the filtered product application messages to be verified. Obtain the number of transactions for the product application; The filtered product application messages and the number of transactions for each product application are verified to obtain the verification results.

2. The automated product application message verification method according to claim 1, characterized in that, The acquisition of multiple product application messages to be verified specifically includes: Retrieve multiple product application messages to be filtered; Determine the data storage location for each product application message to be filtered; If the data storage locations corresponding to multiple product application messages to be filtered are all the same, then the multiple product application messages to be filtered will be output as multiple product application messages to be verified. If the data storage locations corresponding to multiple product application messages to be filtered are inconsistent, return to the step of retrieving multiple product application messages to be filtered.

3. The automated product application message verification method according to claim 1, characterized in that, The step of filtering multiple product application messages to be verified based on the timestamp corresponding to each message to be verified, to obtain the filtered product application messages to be verified, specifically includes: Determine whether the timestamps corresponding to multiple product application messages to be verified all meet the preset time threshold, and obtain the first judgment result; If the first judgment result is yes, then multiple product application messages to be verified will be output as filtered product application messages to be verified. If the first judgment result is negative, then the product application messages to be verified that do not meet the preset time threshold will be deleted, and the filtered product application messages to be verified will be obtained.

4. The automated product application message verification method according to claim 1, characterized in that, The number of transactions obtained from the product application specifically includes: Obtain multiple transaction tables for product applications according to preset time conditions; Multi-threaded features are used to query multiple transaction tables to determine the number of transactions for the product application.

5. The automated product application message verification method according to claim 1, characterized in that, The method further includes: Obtain the timestamp determination method and multiple pending product application messages; If the timestamp determination method includes the first setting method, then the time of obtaining each pending product application message is set as the timestamp of the pending product application message. If the timestamp determination method includes the second setting method, then the offset is determined, and the timestamp of each product application message to be processed is determined based on the offset; Each pending product application message is entered into the database according to its timestamp.

6. The automated product application message verification method according to claim 1, characterized in that, The verification result includes verification success or verification failure; the verification of the filtered product application messages and the number of transactions of the product applications to obtain the verification result specifically includes: The filtered product application messages and the number of transactions for each product application are verified to obtain the verification results. If the verification result includes "verification successful", then the verification ends. If the verification result includes verification failure, an error message is generated, and the application messages of the filtered products to be verified are corrected based on the error message.

7. An automated product application message verification device, characterized in that, The automated product application message verification device includes: The first acquisition module is used to acquire multiple product application messages to be verified from the product application. The parsing module is used to parse and process each product application message to be verified and determine the timestamp corresponding to each product application message to be verified. The filtering module is used to filter multiple product application messages to be verified based on the timestamp corresponding to each product application message to be verified, and obtain the filtered product application messages to be verified. The second acquisition module is used to acquire the number of transactions for the product application; The verification module is used to verify the filtered product application messages and the number of transactions of the product applications to obtain the verification results.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the automated product application message verification method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the automated product application message verification method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the automated product application message verification method as described in any one of claims 1-6.

Images