Transaction playback comparison method and device for heterogeneous system migration and electronic equipment

Abstract

The invention provides a transaction playback comparison method and device for heterogeneous system migration and electronic equipment. The method comprises the following steps: extracting a plurality of first messages from a source system; determining a message conversion rule according to message specifications of an online interface and a transaction interface of the target system, and processing each first message to obtain a corresponding second message; determining a sending mode of each first message and each second message according to the transaction type; sending each first message to a source system for testing according to the sending mode to obtain a first test result, and sending each second message to a target system for testing according to the sending mode to obtain a second test result; and comparing each first test result with the corresponding second test result, and sending each comparison result to the target terminal. The method solves the problem that in the prior art, comparison is performed according to processing logs of a source system and a target system, testing cannot be performed through data with large magnitude, and consequently the testing result is inaccurate.

Description

Technical Field

[0001] This invention relates to the field of data migration technology, and more specifically, to a method, apparatus, computer-readable storage medium, and electronic device for transaction replay comparison during heterogeneous system migration. Background Technology

[0002] Playback comparison refers to using technical means to simulate various data flow cases of production operation based on data, transactions and data files in the production environment. By comparing the source system with the target system, the accuracy and consistency of the processing logic and processing results are verified, ensuring that the target system's functions and data migration meet quality standards and meet the conditions for going live.

[0003] Existing technologies for replay comparison typically use the processing logs of the source and target systems for comparison, without considering the differences in storage technologies between the metadata and target databases. This makes them unsuitable for processing large amounts of data, resulting in a lack of comprehensiveness and accuracy in the comparison test results. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, computer-readable storage medium, and electronic device for comparing transaction replays during heterogeneous system migration, so as to at least solve the problem in the prior art that comparing the processing logs of the source system and the target system cannot be tested with large amounts of data, resulting in inaccurate test results.

[0005] To achieve the above objectives, according to one aspect of this application, a transaction replay comparison method for heterogeneous system migration is provided, comprising: extracting online transaction request messages from historical production logs of the source system database to obtain multiple first messages; determining message conversion rules according to the message specifications of the online interface and transaction interface of the target system, and processing each first message according to the message conversion rules to obtain corresponding second messages; determining the sending method of each first message and the second message according to the transaction type, wherein the sending method includes concurrent and serial; sending each first message to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results; sending each second message to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results; comparing each first test result and the corresponding second test result to obtain multiple comparison results, and sending each comparison result to the target terminal.

[0006] Optionally, processing each first message according to the message conversion rules to obtain a corresponding second message includes: extracting the message header of the first message to obtain multiple first message headers, and concatenating the first message headers according to the message conversion rules corresponding to the online interface to obtain a second message header; extracting the message body of the first message to obtain multiple first message bodies, and splitting the first message bodies into multiple message fields according to the transaction type to obtain multiple first message fields; converting each first message field according to the message conversion rules corresponding to the transaction interface to obtain a corresponding second message field; filling in the threshold value of each second message field to obtain a corresponding second message body; and concatenating each second message header with the corresponding second message body to obtain the second message.

[0007] Optionally, determining the sending method of each of the first and second messages according to the transaction type includes: when the transaction type is a query transaction, determining that the sending method is concurrent sending and the corresponding number of concurrent transactions is greater than a first threshold; when the transaction type is a modification transaction, determining that the sending method is serial sending.

[0008] Optionally, when the transaction type is a modification transaction, determining the sending method as serial sending includes: determining the sending method as serial sending when the modification transaction and the subsequent transaction are associated; and determining the sending method as concurrent sending and the number of concurrent transactions is less than the first threshold when the modification transaction and the subsequent transaction are not associated.

[0009] Optionally, when the transaction type is a modification transaction, determining the sending method as serial sending includes: determining the sending method as serial sending when the modification transactions belong to the same customer; and determining the sending method as concurrent sending when the modification transactions do not belong to the same customer.

[0010] Optionally, each of the first messages is sent to the source system according to the sending method to perform single-transaction testing and multi-transaction mixed-transmission testing, and to obtain the corresponding first test result, including: splitting the first message according to the transaction number and operation field, splitting each first message into a query transaction and a modification transaction; sending the query transaction to the source system using concurrent sending, and obtaining the response message of the source system to obtain a first test sub-result, wherein the concurrency of the concurrent sending is greater than a first threshold; upon receiving the first test sub-result, sending the modification transaction that is not associated with the subsequent transaction to the source system using concurrent sending, and obtaining the response message and database data of the source system to obtain a second test sub-result, wherein the concurrency of the concurrent sending is less than the first threshold; upon receiving the second test sub-result, sending the modification transaction that is associated with the subsequent transaction to the source system using serial sending, and obtaining the response message and database data of the source system to obtain a third test sub-result; generating the first test result based on the first test sub-result, the second test sub-result, and the third test sub-result.

[0011] Optionally, multiple comparison results are obtained by comparing each first test result with the corresponding second test result, including: comparing the first object in the first test result and the second test result using an in-table loop comparison method to obtain a first comparison sub-result, where the first object is a list field; comparing the second object in the first test result and the second test result using a recursive call comparison method to obtain a second comparison sub-result, where the second object is a nested field; and comparing the third object in the first test result and the second test result using a numerical comparison method to obtain a third comparison sub-result, where the third object is a field other than the first object and the second object.

[0012] According to another aspect of this application, a transaction replay comparison method for heterogeneous system migration is provided, comprising: an acquisition unit, configured to extract online transaction request messages from historical production logs of a source system database to obtain multiple first messages; a first determination unit, configured to determine message conversion rules according to the message specifications of the online interface and transaction interface of the target system, and process each first message according to the message conversion rules to obtain a corresponding second message; a second determination unit, configured to determine the sending method of each first message and the second message according to the transaction type, wherein the sending method includes concurrent and serial; a first sending unit, configured to send each first message to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain a corresponding first test result, and send each second message to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain a corresponding second test result; and a second sending unit, configured to compare each first test result and the corresponding second test result to obtain multiple comparison results, and send each comparison result to a target terminal.

[0013] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0014] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any one of the methods described.

[0015] Applying the technical solution of this application, in the above-mentioned heterogeneous system migration transaction replay comparison method, firstly, online transaction request messages are extracted from the historical production logs of the source system database to obtain multiple first messages; then, message conversion rules are determined according to the message specifications of the target system's online interface and transaction interface, and each first message is processed according to the message conversion rules to obtain corresponding second messages; then, the sending method of each first message and second message is determined according to the transaction type, including concurrent and serial sending methods; then, each first message is sent to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results, and each second message is sent to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results; finally, each first test result and the corresponding second test result are compared to obtain multiple comparison results, and each comparison result is sent to the target terminal. This application uses the messages from the source database as the basis for conversion and then uses them as the input response of the target system. This ensures the consistency of the data source, avoids the technical differences between the source system database and the target system database in heterogeneous systems, and makes it a feasible solution for comprehensive testing based on massive amounts of online transaction data. This improves the accuracy of the test and solves the problem in the existing technology that compares the processing logs of the source system and the target system, which cannot be tested with large amounts of data, resulting in inaccurate test results. Attached Figure Description

[0016] Figure 1 A hardware structure block diagram of a mobile terminal for a transaction replay comparison method for heterogeneous system migration provided in an embodiment of this application is shown.

[0017] Figure 2 A flowchart illustrating a transaction replay comparison method for heterogeneous system migration according to an embodiment of this application is shown.

[0018] Figure 3 A structural block diagram of a transaction replay comparison device for heterogeneous system migration provided according to an embodiment of this application is shown.

[0019] The above figures include the following reference numerals:

[0020] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] 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 should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., 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 for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] As described in the background section, existing replay comparisons typically use the processing logs of the source and target systems for comparison, without considering the differences in storage technologies between the metadata and target databases. This makes them unsuitable for processing large amounts of data, resulting in a lack of comprehensiveness and accuracy in the comparison test results. To address the problem that existing comparisons based on the processing logs of the source and target systems cannot be tested with large amounts of data, leading to inaccurate test results, embodiments of this application provide a transaction replay comparison method, apparatus, computer-readable storage medium, and electronic device for heterogeneous system migration.

[0025] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0026] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a transaction replay comparison method for heterogeneous system migration according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0027] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the transaction replay comparison method for heterogeneous system migration in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0028] This embodiment provides a transaction replay comparison method for heterogeneous system migration running on a mobile terminal, computer terminal or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0029] Figure 2 This is a flowchart of a transaction replay comparison method for heterogeneous system migration according to an embodiment of this application. For example... Figure 2 As shown, the method includes the following steps:

[0030] Step S201: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0031] Understandably, replay comparison testing first requires extracting online transaction request data from the historical data of the source system. This data serves as the basis for testing, accurately reflecting the transaction situation in the production environment, thereby effectively verifying the performance and accuracy of the target system in processing actual business.

[0032] In practice, we assume the source system is an Oracle database and the target system is a MySQL database. From the historical production logs of the Oracle database, we use SQL queries to extract request message data containing all online transactions (such as purchases, returns, installments, etc.). This message data may be contained in multiple log files and needs to be integrated and cleaned to remove irrelevant information, ultimately yielding a series of first messages, i.e., the set of online transaction request messages from the source system.

[0033] Step S202: Determine the message conversion rules according to the message specifications of the target system's online interface and transaction interface, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0034] It is understandable that, due to the significant technical differences between the source and target systems, the message formats of the source system and the target system may be inconsistent. Therefore, it is necessary to develop corresponding message conversion rules to convert the messages of the source system into a format that the target system can recognize and process.

[0035] In practice, message conversion rules are determined based on the online and transaction interface specifications of the target system's MySQL. Assuming the source system uses XML format for transaction messages and the target system uses JSON format, tools or scripts need to be written to automatically convert XML messages to JSON format, while adjusting field order and naming to conform to MySQL system specifications. The conversion process includes standardizing the message header and converting each transaction field in the message body, ensuring the target system can correctly parse and process these messages.

[0036] Step S203: Determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial.

[0037] Understandably, in order to effectively utilize test environment resources while ensuring the accuracy and comprehensiveness of the tests, it is necessary to determine the concurrency of sending request messages based on the transaction type (such as query, modification, and special modification).

[0038] In practice, the testing strategy involves sending query transactions in a high-concurrency mode to test the system's ability to handle a large number of queries; general modification transactions are sent with appropriate concurrency to test the system's efficiency in processing modification requests; and special modification transactions, due to the importance of their transaction order, are sent serially with low concurrency to ensure that the dependencies between preceding and following transactions are not broken.

[0039] By implementing the above steps, this strategy not only ensures test quality but also significantly improves test efficiency, reduces test time, and avoids system anomalies caused by improper concurrency settings.

[0040] Step S204: Send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0041] Understandably, sending the processed messages to the source and target systems separately to perform single-transaction and multi-transaction mixed-transaction tests can comprehensively verify the system's processing capabilities under different transaction types and data volumes.

[0042] In practice, when testing the source system Oracle, a first message is sent according to the defined concurrency strategy, recording the time it takes for the system to process each request, the returned status code, and the processing result to obtain the first test result. Similarly, a second message is sent to the target system MySQL, recording the same test information to obtain the second test result.

[0043] The above operations not only allow us to test the accuracy of processing a single transaction, but also to evaluate the stability and performance of the system when processing a large number of transactions.

[0044] Step S205: Compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0045] Understandably, by comparing the test results of the source system and the target system, it is possible to verify whether the target system can accurately execute the business logic of the source system after function porting and data migration.

[0046] In practice, the test results of the source system (Oracle) and the target system (MySQL) are compared, including key information such as response time, status codes, and processing results. If the results of the two systems are consistent, it is recorded as no difference; if there are differences, the type of difference, the transaction messages involved, and the specific points of difference are recorded in detail. These comparison results are then summarized and sent to the target terminal (such as the test management platform or the developers' email) for further analysis and problem localization.

[0047] In this embodiment, firstly, online transaction request messages are extracted from the historical production logs of the source system database to obtain multiple first messages. Then, message conversion rules are determined according to the message specifications of the target system's online and transaction interfaces, and each first message is processed according to the message conversion rules to obtain corresponding second messages. Next, the sending method of each first and second message is determined according to the transaction type, including concurrent and serial sending methods. Then, each first message is sent to the source system according to the sending method for single-transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results. Similarly, each second message is sent to the target system according to the sending method for single-transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results. Finally, each first test result and the corresponding second test result are compared to obtain multiple comparison results, and each comparison result is sent to the target terminal. This application uses the messages from the source database as the basis for conversion and then uses them as the input response of the target system. This ensures the consistency of the data source, avoids the technical differences between the source system database and the target system database in heterogeneous systems, and makes it a feasible solution for comprehensive testing based on massive amounts of online transaction data. This improves the accuracy of the test and solves the problem in the existing technology that compares the processing logs of the source system and the target system, which cannot be tested with large amounts of data, resulting in inaccurate test results.

[0048] In order to adapt the message to the target system, in one optional implementation, step S202 above includes:

[0049] Step S2021: Extract the header of the first message to obtain multiple first message headers, and concatenate the first message headers according to the message conversion rules corresponding to the online interface to obtain the second message header;

[0050] Understandably, message headers typically contain transaction metadata, such as message length, batch number, and timestamp, which are crucial for transaction processing. In heterogeneous system migration, the message header format of the source system may be incompatible with the target system; therefore, it is necessary to reconstruct the message header according to the target system's interface specifications.

[0051] In practical implementation, assume the source system is IBM DB2 and the target system is MS SQL Server. The DB2 header may contain a fixed prefix "DB2", while the MS SQL Server online interface specification requires the header to contain the prefix "SQL" and specifies a particular field order and format. Therefore, the first step is to extract all the first headers, and then reconstruct the headers according to the MS SQL Server online interface specification. For example, replace "DB2" with "SQL" and follow the new field order to complete the concatenation of the second header.

[0052] The above embodiments ensure that the target system can identify and parse the received messages, laying the foundation for subsequent processes. For example, when processing a transfer transaction, correct message header conversion ensures that the target system can quickly identify the transaction type and speed up processing.

[0053] Step S2022: Extract the message body of the first message to obtain multiple first message bodies, and split the first message body into multiple message fields according to the transaction type to obtain multiple first message fields;

[0054] Understandably, the message body carries the specific data of a transaction, and different transaction types may correspond to different data formats and fields. When migrating data between heterogeneous systems, the message body needs to be carefully split and transformed to adapt to the transaction interface of the target system.

[0055] In practice, the message body of the source system DB2 may be a continuous character stream containing different types of transaction data (such as consumption, transfer, and balance inquiry). First, these first message bodies are split, separating the data for each transaction into multiple first message fields. For example, the data for a consumption transaction is separated into one message field, labeled "CONSUMPTION"; the data for a transfer transaction is separated into another message field, labeled "TRANSFER".

[0056] The above operations improve the efficiency and accuracy of data processing. For example, when processing transfer transactions, only the message field marked "TRANSFER" needs to be focused on, avoiding interference from other types of transaction data.

[0057] Step S2023: Convert each first message field according to the message conversion rules corresponding to the transaction interface to obtain the corresponding second message field;

[0058] Understandably, the transformation rules are based on the differences in data formats between the source and target systems, and they guide how to transform data from the source system into a form readable by the target system.

[0059] Step S2024: Fill in the threshold values ​​for each second message field to obtain the corresponding second message body;

[0060] It is understandable that threshold values ​​refer to data values ​​set to test system boundary conditions or specific functions, such as minimum transaction amount or maximum number of transactions.

[0061] In practice, after completing the message field conversion, it is necessary to fill in threshold values ​​for each field of the second message field according to the specific requirements of the target system. For example, for consumer transactions, it may be necessary to set a threshold of a minimum transaction amount of x yuan to ensure that the target system can handle small transactions.

[0062] The above operations can comprehensively cover test cases, ensuring the stability and reliability of the target system under various extreme conditions.

[0063] Step S2025: Concatenate each second message header with the corresponding second message body to obtain the second message.

[0064] Understandably, after completing the conversion of the second message header and the second message body, the two need to be merged into a complete message for testing on the target system.

[0065] In practice, provided that the second message header and the second message body are formatted correctly and their contents match, each second message header is concatenated with its corresponding second message body. For example, a message header marked "SQL" is concatenated with a message field marked "CONSUMPTION" to form a complete second message for consumption transactions. Then, similar operations are performed until all message fields have been converted.

[0066] Through the above operations, the concatenated second message fully complies with the interface requirements of the target system MS SQL Server and can be used directly for testing without additional manual adjustments, greatly simplifying the test preparation process.

[0067] The above embodiments ensure seamless integration of message formats across heterogeneous systems, improving the efficiency of data exchange and processing between systems. Precise field conversion and threshold settings ensure the accuracy and integrity of test data, reducing test errors caused by data format mismatches. By splitting message fields according to transaction type and setting threshold values, the scope of test cases is effectively expanded, especially for boundary and extreme conditions, improving the comprehensiveness and depth of testing. The automation of the overall conversion process reduces manual intervention, lowers the probability of errors, accelerates testing, and shortens project cycles.

[0068] To improve testing efficiency, in one optional implementation, step S203 includes:

[0069] Step S2031: When the transaction type is a query transaction, determine that the sending method is concurrent sending and the corresponding number of concurrent transactions is greater than the first threshold.

[0070] It is understandable that query transactions consume less system resources compared to modification transactions, and in most cases do not cause changes in data state. Therefore, high-concurrency sending methods can be used to conduct large-scale tests to evaluate the system's query performance and response time.

[0071] In practical implementation, suppose we need to test the performance of a target system (such as a new distributed database system) under large-scale concurrent queries. 10,000 query-type online transaction request messages are extracted from the source system's historical production logs. Based on the target system's performance metrics and the hardware configuration of the test environment, a first threshold of 100 is determined, meaning the number of concurrently sent request messages will exceed 100. For example, in the test environment, the number of concurrently sent query messages can be set to 500 to test the system's stability and response speed under extremely high concurrency conditions.

[0072] By employing the above operations and high-concurrency testing methods, the system's capacity and performance bottlenecks in query transaction processing can be effectively evaluated, ensuring that the target system can cope with query pressure in the production environment during actual deployment.

[0073] Step S2032: If the transaction type is a modification transaction, determine that the sending method is serial sending.

[0074] Understandably, modification transactions involve changes to the internal data state of the system. High-concurrency modification transactions may cause problems such as data conflicts and transaction processing errors. Therefore, these transactions usually need to be processed sequentially in a certain order to maintain data consistency and transaction atomicity.

[0075] In practice, when processing modification transactions, such as transfer requests, to ensure the accuracy of fund transfers and the stability of the system, transaction request messages are sent serially. This means that each modification transaction message is sent only after the previous transaction has been processed, avoiding problems such as duplicate deductions or failed transfers that might occur due to concurrent operations. For example, when processing 1000 transfer requests, the system will receive and process each transaction one by one until all transactions are completed before ending the test.

[0076] By employing the serial transmission strategy described above, the independence of each modification transaction and the correct execution of the transaction are ensured, data conflicts are avoided, and the transaction security and data consistency of the system when processing such transactions are maintained.

[0077] The high-concurrency sending method for query transactions described in the above embodiments significantly shortens the testing time, while the selection of the number of concurrent transactions ensures the comprehensiveness of the test, enabling the detection of the system's concurrent performance and ultimate capacity. The serial sending strategy for modification transactions ensures the accuracy of the test results by avoiding data problems that might be caused by concurrent modifications. Serial sending of modification transactions reduces system risks caused by concurrent operations, especially in operations involving funds or other sensitive data; this strategy improves data security and transaction reliability.

[0078] To further improve testing efficiency, in one optional implementation, step S2032 includes:

[0079] Step S20321: If the modified transaction and the subsequent transaction are related, determine that the sending method is serial sending;

[0080] It is understandable that modification transactions have a direct impact on the database state. If the result of such transactions affects the execution of subsequent transactions, such as transactions involving changes in funds affecting subsequent balance inquiries or further transfers, then in order to maintain the accuracy and consistency of the data, it is necessary to ensure that transactions are executed in sequence to avoid data conflicts caused by concurrent operations.

[0081] In implementation, assume the source system records a series of consumption, refund, and re-consumption transaction requests. These transactions have data dependencies; a refund transaction can only be successfully executed after the original consumption transaction and when the balance is sufficient. To verify that the target system maintains the correct data flow and transaction order when processing these types of transactions, we choose to send these modification transaction messages serially. This means that the processing of each transaction message must wait for the previous message to complete processing and confirm its status before it can begin, ensuring the sequentiality and consistency of the entire transaction sequence.

[0082] Step S20322: If there is no association between the modification transaction and the subsequent transaction, determine that the sending method is concurrent sending and the number of concurrent transactions is less than the first threshold.

[0083] Understandably, for modification transactions, if their results do not directly affect the execution of subsequent transactions, concurrent sending can be used to improve testing efficiency. However, the number of concurrent transactions needs to be set reasonably based on system characteristics and hardware resources, usually below the first threshold, to avoid putting too much pressure on the system or causing unnecessary data competition.

[0084] In practical implementation, assume there are a large number of independent account top-up transactions, each operating on a single account and not directly related to other transactions. In this case, choose to send these modification transaction messages concurrently, but set the concurrency level below a first threshold, such as 100, to ensure that the system can handle them effectively and that performance degradation or data errors will not occur due to resource contention.

[0085] Through the above embodiments, the serial transmission strategy ensures that modification transactions involving data dependencies are executed in the correct order, effectively avoiding data inconsistencies and transaction processing errors caused by concurrent operations, and improving the system reliability after data migration. For modification transactions that do not involve data dependencies, the concurrent transmission method significantly improves the testing speed, reduces the overall testing cycle, and the control of the number of concurrent transactions also ensures the stability of the testing environment and avoids unnecessary system risks. The combined use of serial and concurrent strategies optimizes the allocation of testing resources, ensuring high priority for the system when processing critical transactions and efficient utilization when processing a large number of independent transactions.

[0086] To further improve testing efficiency, in an optional implementation, step S2032 further includes:

[0087] Step S20323: If the modified transactions belong to the same customer, determine that the sending method is serial sending;

[0088] Understandably, modification transactions, especially those involving changes in funds, may have significant dependencies if they target different accounts of the same customer or the same account. For example, an account balance update might affect subsequent withdrawals or transfers. Therefore, to maintain data consistency and integrity, and to ensure that each transaction builds upon the previous one, these transactions should be sent serially, meaning each transaction must wait until the previous transaction is fully processed before proceeding.

[0089] Step S20324: If the modification transactions do not belong to the same customer, determine that the sending method is concurrent sending.

[0090] Understandably, for modification transactions that do not involve the same customer, since they are independent at the data level, concurrent sending can be used for testing to improve testing efficiency and system performance evaluation. Concurrent sending allows for the parallel processing of a large number of transactions in a short period, effectively evaluating the system's concurrency capabilities and performance.

[0091] Through the above embodiments, the concurrent sending strategy for processing transactions belonging to different customers can quickly process a large number of independent transactions, improving testing efficiency. Conversely, the serial sending strategy for transactions belonging to the same customer ensures the correct execution order and data consistency between transactions, improving testing accuracy. The concurrent sending strategy fully utilizes system resources, making the testing process more efficient; the serial sending strategy ensures the orderly allocation of resources in critical transaction scenarios, avoiding data errors or system instability caused by improper concurrent operations. By comprehensively employing both serial and concurrent sending methods, the system's functional implementation and performance under different transaction scenarios can be comprehensively evaluated, providing strong data support for performance optimization and functional verification after system migration. The use of the serial sending strategy, especially when processing data involving the same customer, ensures consistency and accuracy before and after data migration, avoids data conflicts caused by concurrent operations, and improves the reliability of data migration.

[0092] To obtain the aforementioned first test result, in one optional implementation, step S204 includes:

[0093] Step S2041: The first message is split according to the transaction number and operation field, and each first message is split into query transaction and modification transaction;

[0094] Understandably, the transaction number is the unique identifier of a transaction, while the operation field defines the type of transaction, such as query, recharge, or refund. By splitting the first message (i.e., the transaction request message from the source system), targeted tests can be conducted separately for query and modification transactions to evaluate the system's performance and processing capabilities under different transaction types.

[0095] In the implementation, assume 10,000 transaction messages are extracted from the source system. These messages contain various types of transactions, such as account balance inquiries, account top-ups, and refunds. First, based on the transaction number and operation field, the messages are split into several subsets of query and modification transactions. For example, all account balance query transactions are labeled as "QUERY," while account top-up and refund transactions are labeled as "MODIFY," and subsequent tests are performed separately.

[0096] By performing the above operations, message splitting improves the targeting of testing, allowing the testing team to optimize test strategies for queries and modified transactions separately, thereby more effectively evaluating system performance.

[0097] Step S2042: Send the query transaction to the source system using concurrent sending and obtain the response message from the source system to obtain the first test sub-result, wherein the number of concurrent sending is greater than the first threshold.

[0098] Understandably, query transactions cause minor changes to the database state and can typically be executed concurrently to test the system's query capabilities and response time. The first threshold here defines the upper limit of concurrent operations to prevent excessive stress on the system.

[0099] In practical implementation, in the above scenario, all transactions marked "QUERY" (assuming 5000 transactions) are sent to the source system in a high-concurrency manner, for example, with the concurrency set to 500. By sending concurrently, the response time of multiple query transactions can be tested simultaneously, obtaining the system's performance and resource utilization under a large number of query requests, thus obtaining the first test sub-result.

[0100] Step S2043: Upon receiving the first test sub-result, the modified transaction that is not associated with the subsequent transaction is sent to the source system using concurrent sending, and the response message and database data of the source system are obtained to obtain the second test sub-result, wherein the number of concurrent sending is less than the first threshold.

[0101] Understandably, modification transactions can be categorized into two types based on whether they affect the execution of subsequent transactions: those related to subsequent transactions and those not related. For modification transactions not related to subsequent transactions, concurrency testing can be conducted while controlling the number of concurrent requests to balance test speed and data consistency.

[0102] In practice, it is assumed that among the remaining modification transactions, 3000 transactions are not directly related to subsequent transactions (such as independent account top-ups). A concurrent sending method is adopted, but the concurrency number is less than a first threshold, for example, set to 50, to test the processing speed and data processing consistency of these modification transactions. Simultaneously, the response message and database status of each transaction must also be obtained to ensure correct data updates.

[0103] Step S2044: Upon receiving the second test sub-result, the modified transaction associated with the subsequent transaction is sent to the source system via serial transmission, and the response message and database data of the source system are obtained to obtain the third test sub-result.

[0104] Understandably, for modification transactions that are associated with subsequent transactions, such as refund transactions (which depend on previous recharge transactions), serial transmission must be used to maintain the order of transactions and the correctness of the data.

[0105] In practice, the remaining 2,000 modification transactions are related to subsequent transactions (such as refund transactions). These transactions are sent serially, meaning the next transaction is sent only after the previous one has been fully processed and its status confirmed. This method ensures sequential data updates and consistency, while also verifying that dependencies between transactions are handled correctly.

[0106] Step S2045: Generate the first test result based on the first test sub-result, the second test sub-result, and the third test sub-result.

[0107] Understandably, the comprehensive first test results are formed by combining the test results of querying and modifying transactions (including those related to subsequent transactions and those not related to them). This will cover the system's performance and functionality under different transaction types and different concurrency strategies.

[0108] In practice, the first, second, and third test sub-results obtained above are summarized and analyzed to generate the first test result. The first test result will record in detail key indicators such as response time, system stability, and data processing consistency under each test strategy, providing a basis for system optimization and functional verification.

[0109] Through the above embodiments, high-concurrency query transaction testing and controllable concurrency modification transaction concurrency testing effectively utilized test resources and shortened the overall test time. For modification transactions involving data dependencies, a serial sending strategy was adopted to ensure the sequential execution of transactions, avoid data conflicts, and ensure data accuracy and consistency. Comprehensive analysis of the first, second, and third test sub-results provides a complete understanding of the system's performance under different transaction types and concurrency strategies, pointing the way for subsequent system optimization. Reasonably setting the concurrency level fully utilizes system resources while avoiding system risks caused by excessive concurrency, achieving efficient utilization of test resources and effective control of system risks.

[0110] To obtain the above comparison results, in an optional implementation, step S205 includes:

[0111] Step S2051: The first object in the first test result and the second test result is compared by using an in-table loop comparison method to obtain the first comparison sub-result. The first object is a list field.

[0112] Understandably, a list field is a sequence of multiple elements that may exist in a response message, representing a series of related information. When comparing the processing results of the source and target systems, it is necessary to ensure that each item in the list matches the result of the other system to verify the integrity and consistency of the data.

[0113] In the implementation, it is assumed that both the first and second test results contain transaction lists, originating from the source system and the target system, respectively. This transaction list is a list field that records the specific details of each transaction, such as transaction ID, transaction amount, and transaction time. To verify whether the transaction list generated by the target system during transaction processing is consistent with that of the source system, an inner loop is used to compare each transaction detail under the same transaction ID between the source and target systems. Specifically, this can be achieved by setting a loop to iterate through each element in the list and using conditional statements to check if the data of corresponding elements is consistent. If they are inconsistent, the specific differences are recorded, thus obtaining the first comparison result.

[0114] Step S2052: The second object in the first test result and the second test result is compared by recursive call comparison to obtain the second comparison sub-result. The second object is a nested field.

[0115] As is understandable, nested fields refer to fields that contain other fields or objects within a data structure. These may have multi-level structures; for example, transaction records may contain nested account information or product information. Recursive calls are an effective comparison strategy that can delve into every level of the data structure, ensuring consistency across all data.

[0116] In practice, transaction records contain nested account information, such as account balance and account type. These nested fields may exist in the response message and are used to describe the context of the transaction in detail. During comparison, the process starts from the outermost transaction record, identifies the nested account information fields, and then recursively enters these fields, comparing sub-fields such as account balance and account type layer by layer. If inconsistencies are found at any level, they are recorded and a second comparison sub-result is generated.

[0117] Step S2053: The third object in the first test result and the second test result is compared by numerical comparison to obtain the third comparison sub-result. The third object is the field other than the first object and the second object.

[0118] Understandably, besides list fields and nested fields, there are also a large number of single numeric fields, such as transaction amount and account balance. These fields can be directly compared numerically to check the consistency of the processing results between the source and target systems.

[0119] In practice, the response message contains many directly comparable numeric fields, such as the amount of each transaction (assuming they are all integers). These third-object fields are extracted one by one, and a numerical comparison is used—that is, the values ​​from the source system and the target system are directly compared. If the values ​​are equal, it is recorded as consistent; otherwise, it is recorded as different, forming a third comparison sub-result.

[0120] Through the above embodiments, various strategies such as in-table loop comparison, recursive call comparison, and numerical comparison are employed to ensure accurate and comprehensive comparison of both simple single fields and complex list and nested fields, avoiding any omissions in the comparison process. Multi-dimensional and multi-level data comparison not only verifies the accuracy of numerical fields but also ensures the structural consistency and content integrity of list and nested fields, strengthening the guarantee of consistency before and after data migration. Customized comparison strategies are optimized for the characteristics of different fields, reducing errors caused by inappropriate comparison strategies and improving the reliability of comparison results.

[0121] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0122] This application also provides a transaction replay comparison device for heterogeneous system migration. It should be noted that the transaction replay comparison device for heterogeneous system migration in this application can be used to execute the transaction replay comparison method for heterogeneous system migration provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0123] The following describes the transaction replay comparison device for heterogeneous system migration provided in the embodiments of this application.

[0124] Figure 3 This is a structural block diagram of a transaction replay comparison device for heterogeneous system migration according to an embodiment of this application. Figure 3 As shown, the device includes:

[0125] The acquisition unit 10 is used to extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0126] The first determining unit 20 is used to determine the message conversion rules according to the message specifications of the online interface and transaction interface of the target system, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0127] The second determining unit 30 is used to determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial transmission.

[0128] The first sending unit 40 is used to send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; and to send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0129] The second sending unit 50 is used to compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0130] In this embodiment, the acquisition unit extracts online transaction request messages from the historical production logs of the source system database to obtain multiple first messages; the first determination unit determines message conversion rules according to the message specifications of the target system's online interface and transaction interface, and processes each first message according to the message conversion rules to obtain corresponding second messages; the second determination unit determines the sending method of each first message and second message according to the transaction type, including concurrent and serial sending methods; the first sending unit sends each first message to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results, and sends each second message to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results; the second sending unit compares each first test result with the corresponding second test result to obtain multiple comparison results, and sends each comparison result to the target terminal. This application uses the messages from the source database as the basis for conversion and then uses them as the input response of the target system. This ensures the consistency of the data source, avoids the technical differences between the source system database and the target system database in heterogeneous systems, and makes it a feasible solution for comprehensive testing based on massive amounts of online transaction data. This improves the accuracy of the test and solves the problem in the existing technology that compares the processing logs of the source system and the target system, which cannot be tested with large amounts of data, resulting in inaccurate test results.

[0131] In order to adapt the message to the target system, in one optional implementation, the first determining unit includes:

[0132] The first acquisition module is used to extract the header of the first message, obtain multiple first message headers, and concatenate the first message headers according to the message conversion rules corresponding to the online interface to obtain the second message header;

[0133] The second acquisition module is used to extract the message body of the first message to obtain multiple first message bodies, and to split the first message body into multiple message fields according to the transaction type to obtain multiple first message fields;

[0134] The first processing module is used to convert each first message field according to the message conversion rules corresponding to the transaction interface to obtain the corresponding second message field;

[0135] The second processing module is used to fill in the threshold values ​​of each second message field to obtain the corresponding second message body;

[0136] The third processing module is used to concatenate each second message header with the corresponding second message body to obtain the second message.

[0137] To improve testing efficiency, in one optional implementation, the second determining unit includes:

[0138] The first determining module is used to determine that, in the case of a query transaction, the sending method is concurrent sending and the corresponding number of concurrent transactions is greater than a first threshold.

[0139] The second determining module is used to determine the sending method as serial sending when the transaction type is a modification transaction.

[0140] To further improve testing efficiency, in one optional implementation, the second determining module includes:

[0141] The first determination submodule is used to determine the sending method as serial sending when there is a relationship between the modification transaction and the subsequent transaction.

[0142] The second determination submodule is used to determine that the sending method is concurrent sending and the number of concurrent transactions is less than the first threshold when there is no association between the modification transaction and the subsequent transaction.

[0143] To further improve testing efficiency, in one optional implementation, the second determining module further includes:

[0144] The third determination submodule is used to determine whether to send data serially when the modified transactions belong to the same customer.

[0145] The fourth determination submodule is used to determine whether to send the modified transactions as concurrent transactions when the transactions do not belong to the same customer.

[0146] In order to obtain the aforementioned first test result, in one optional implementation, the first sending unit includes:

[0147] The fourth processing module is used to split the first message according to the transaction number and operation field, and to split each first message into query transaction and modify transaction;

[0148] The first sending module is used to send the query transaction to the source system using concurrent sending, and obtain the response message from the source system to obtain the first test sub-result, wherein the number of concurrent sending is greater than the first threshold.

[0149] The second sending module is used to send the modified transaction that is not related to the subsequent transaction to the source system in the case of receiving the first test sub-result, and to obtain the response message and database data of the source system to obtain the second test sub-result, wherein the number of concurrent sending is less than the first threshold.

[0150] The third sending module is used to send the modified transaction associated with the subsequent transaction to the source system in serial transmission after receiving the second test sub-result, and to obtain the response message and database data of the source system to obtain the third test sub-result.

[0151] The generation module is used to generate the first test result based on the first test sub-result, the second test sub-result, and the third test sub-result.

[0152] To obtain the above comparison results, in one optional implementation, the second sending unit includes:

[0153] The first comparison module is used to compare the first object in the first test result and the second test result using an in-table loop comparison method to obtain the first comparison sub-result, where the first object is a list field;

[0154] The second comparison module is used to compare the second object in the first test result and the second test result using a recursive call comparison method to obtain the second comparison sub-result, where the second object is a nested field;

[0155] The third comparison module is used to compare the third object in the first test result and the second test result using numerical comparison to obtain the third comparison sub-result. The third object is the field other than the first object and the second object.

[0156] The aforementioned heterogeneous system migration transaction replay comparison device includes a processor and a memory. The acquisition unit, first determination unit, second determination unit, first sending unit, and second sending unit are all stored as program units in the memory. The processor executes these program units stored in the memory to achieve their respective functions. All of the above modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0157] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can improve the accuracy of heterogeneous system migration.

[0158] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0159] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the transaction replay comparison method for heterogeneous system migration.

[0160] Specifically, the transaction replay comparison methods for heterogeneous system migration include:

[0161] Step S201: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0162] Step S202: Determine the message conversion rules according to the message specifications of the target system's online interface and transaction interface, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0163] Step S203: Determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial.

[0164] Step S204: Send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0165] Step S205: Compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0166] This invention provides a processor for running a program, wherein the program executes the transaction replay comparison method for heterogeneous system migration.

[0167] Specifically, the transaction replay comparison methods for heterogeneous system migration include:

[0168] Step S201: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0169] Step S202: Determine the message conversion rules according to the message specifications of the target system's online interface and transaction interface, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0170] Step S203: Determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial.

[0171] Step S204: Send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0172] Step S205: Compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0173] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0174] Step S201: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0175] Step S202: Determine the message conversion rules according to the message specifications of the target system's online interface and transaction interface, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0176] Step S203: Determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial.

[0177] Step S204: Send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0178] Step S205: Compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0179] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0180] Step S201: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages;

[0181] Step S202: Determine the message conversion rules according to the message specifications of the target system's online interface and transaction interface, and process each first message according to the message conversion rules to obtain the corresponding second message;

[0182] Step S203: Determine the transmission method of each first message and second message according to the transaction type. The transmission methods include concurrent and serial.

[0183] Step S204: Send each first message to the source system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding first test result; send each second message to the target system according to the sending method to perform single transaction test and multi-transaction mixed sending test, and obtain the corresponding second test result.

[0184] Step S205: Compare each first test result with the corresponding second test result to obtain multiple comparison results, and send each comparison result to the target terminal.

[0185] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0186] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0187] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0188] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0190] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0191] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0192] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0193] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0194] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0195] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0196] 1) The transaction replay comparison method for heterogeneous system migration in this application firstly extracts online transaction request messages from the historical production logs of the source system database to obtain multiple first messages; then, it determines message conversion rules according to the message specifications of the target system's online interface and transaction interface, and processes each first message according to the message conversion rules to obtain corresponding second messages; then, it determines the sending method of each first message and second message according to the transaction type, including concurrent and serial sending methods; then, it sends each first message to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results, and sends each second message to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results; finally, it compares each first test result with the corresponding second test result to obtain multiple comparison results, and sends each comparison result to the target terminal. This application uses the messages from the source database as the basis for conversion and then uses them as the input response of the target system. This ensures the consistency of the data source, avoids the technical differences between the source system database and the target system database in heterogeneous systems, and makes it a feasible solution for comprehensive testing based on massive amounts of online transaction data. This improves the accuracy of the test and solves the problem in the existing technology that compares the processing logs of the source system and the target system, which cannot be tested with large amounts of data, resulting in inaccurate test results.

[0197] 2) The heterogeneous system migration transaction replay comparison device of this application comprises: an acquisition unit extracting online transaction request messages from the historical production logs of the source system database to obtain multiple first messages; a first determination unit determining message conversion rules according to the message specifications of the target system's online interface and transaction interface, and processing each first message according to the message conversion rules to obtain corresponding second messages; a second determination unit determining the sending method of each first message and second message according to the transaction type, including concurrent and serial sending methods; a first sending unit sending each first message to the source system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding first test results, and sending each second message to the target system according to the sending method for single transaction testing and multi-transaction mixed sending testing to obtain corresponding second test results; and a second sending unit comparing each first test result with the corresponding second test result to obtain multiple comparison results, and sending each comparison result to the target terminal. This application uses the messages from the source database as the basis for conversion and then uses them as the input response of the target system. This ensures the consistency of the data source, avoids the technical differences between the source system database and the target system database in heterogeneous systems, and makes it a feasible solution for comprehensive testing based on massive amounts of online transaction data. This improves the accuracy of the test and solves the problem in the existing technology that compares the processing logs of the source system and the target system, which cannot be tested with large amounts of data, resulting in inaccurate test results.

[0198] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for comparing transaction replays during heterogeneous system migration, characterized in that, include: Extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages; The message conversion rules are determined based on the message specifications of the target system's online interface and transaction interface, and each first message is processed according to the message conversion rules to obtain the corresponding second message; The transmission method for each of the first and second messages is determined according to the transaction type, and the transmission method includes concurrent and serial transmission. Each of the first messages is sent to the source system according to the sending method to perform single transaction testing and multi-transaction mixed sending testing, and the corresponding first test result is obtained. Each of the second messages is sent to the target system according to the sending method to perform single transaction testing and multi-transaction mixed sending testing, and the corresponding second test result is obtained. The first test results and the corresponding second test results are compared to obtain multiple comparison results, and each comparison result is sent to the target terminal.

2. The method according to claim 1, characterized in that, Each of the first messages is processed according to the message conversion rules to obtain the corresponding second message, including: Extract the header of the first message to obtain multiple first message headers, and concatenate the first message headers according to the message conversion rules corresponding to the online interface to obtain the second message header; Extract the message body of the first message to obtain multiple first message bodies, and split the first message body into multiple message fields according to the transaction type to obtain multiple first message fields; Each of the first message fields is converted according to the message conversion rules corresponding to the transaction interface to obtain the corresponding second message field; Fill in the threshold values ​​for each of the second message fields to obtain the corresponding second message body; The second message is obtained by concatenating each second message header with the corresponding second message body.

3. The method according to claim 1, characterized in that, The method of sending each of the first and second messages is determined according to the transaction type, including: When the transaction type is a query transaction, it is determined that the sending method is concurrent sending and the corresponding number of concurrent transactions is greater than the first threshold. In the case where the transaction type is a modification transaction, the sending method is determined to be serial sending.

4. The method according to claim 3, characterized in that, In the case where the transaction type is a modification transaction, determining that the sending method is serial sending includes: When the modified transaction and the subsequent transaction are related, the sending method is determined to be the serial sending method; If the modified transaction and the subsequent transaction are not related, the sending method is determined to be concurrent sending and the number of concurrent transactions is less than the first threshold.

5. The method according to claim 3, characterized in that, In the case where the transaction type is a modification transaction, determining that the sending method is serial sending includes: If the modified transactions belong to the same customer, the sending method is determined to be serial sending; If the modified transactions do not belong to the same customer, the sending method is determined to be concurrent sending.

6. The method according to claim 1, characterized in that, Each of the first messages is sent to the source system according to the aforementioned sending method for single-transaction testing and multi-transaction mixed-send testing, obtaining the corresponding first test results, including: The first message is split according to the transaction number and operation field, and each first message is split into query transaction and modify transaction; The query transaction is sent to the source system using concurrent sending, and the response message of the source system is obtained to obtain the first test sub-result, wherein the number of concurrent sending is greater than a first threshold; Upon receiving the first test sub-result, the modified transaction, which is not associated with the subsequent transaction, is sent to the source system concurrently, and the response message and database data of the source system are obtained to obtain the second test sub-result, wherein the number of concurrent transmissions is less than the first threshold. Upon receiving the second test sub-result, the modified transaction associated with the subsequent transaction is sent to the source system via serial transmission, and the response message and database data of the source system are obtained to obtain the third test sub-result. The first test result is generated based on the first test sub-result, the second test sub-result, and the third test sub-result.

7. The method according to claim 1, characterized in that, By comparing each of the first test results with the corresponding second test results, multiple comparison results are obtained, including: The first object in the first test result and the second test result are compared by using an in-table loop comparison method to obtain the first comparison sub-result, where the first object is a list field; The second object in the first test result and the second test result is compared by recursive call comparison to obtain the second comparison sub-result, where the second object is a nested field; A third comparison sub-result is obtained by comparing the third object in the first test result and the second test result using a numerical comparison method. The third object is a field other than the first object and the second object.

8. A method for comparing transaction replays during heterogeneous system migration, characterized in that, include: The acquisition unit is used to extract online transaction request messages from the historical production logs of the source system database to obtain multiple first messages; The first determining unit is used to determine the message conversion rules according to the message specifications of the online interface and transaction interface of the target system, and process each first message according to the message conversion rules to obtain the corresponding second message; The second determining unit is used to determine the transmission method of each of the first message and the second message according to the transaction type, wherein the transmission method includes concurrent and serial transmission; The first sending unit is configured to send each of the first messages to the source system according to the sending method to perform single transaction testing and multi-transaction mixed sending testing, and obtain the corresponding first test result; and to send each of the second messages to the target system according to the sending method to perform single transaction testing and multi-transaction mixed sending testing, and obtain the corresponding second test result. The second sending unit is used to compare each of the first test results and the corresponding second test results to obtain multiple comparison results, and send each of the comparison results to the target terminal.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising methods for performing any one of claims 1 to 7.

Images