A Parallel Playback Method and System

Abstract

This invention provides a parallel replay method and system, relating to the field of Internet technology, comprising: acquiring all gateway log files and synchronizing them to a replay system database; parsing the gateway log files according to a specified date using multiple threads to obtain original transaction information and registering it to the replay system database; segmenting all transactions corresponding to the gateway log files by time and replaying them in chronological order; acquiring the original transaction data and sending request messages to the new core system through the replay system to obtain new response messages and response results; configuring a transaction parameter table, assembling comparison expressions based on the transaction parameter table, and comparing the response messages returned by the old and new core systems; configuring and maintaining statistical SQL, executing the statistical SQL in both the old and new core systems, and comparing the statistical results. This invention enables the system to accommodate two core business models through technical means and also allows for the verification of the new core system's functionality through parallel replay, reducing the workload of manual testing.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a parallel playback method and system. Background Technology

[0002] In the field of internet technology, especially in the banking internet technology field, the implementation plan for core system upgrades has shifted from a one-time overall plan to a phased plan and implementation based on business modules. From technical verification to the step-by-step launch of loan systems, accounting systems, and deposit centers, the core system objectively exists in the production system, with the new and old core systems running in parallel for a considerable period of time.

[0003] As financial information technology innovation continues to deepen, the demand for information technology innovation transformation from various financial institutions is constantly increasing. In order to verify the performance and stability of information technology innovation software and hardware, information technology innovation transformation solutions have also seen a situation where information technology innovation supporting software and hardware and original supporting software and hardware are produced in parallel.

[0004] Currently, the technical solution adopted by various banks to address the above issues is the traffic replication solution. There are two types of traffic replication solutions: ESB traffic diversion to complete transaction playback and independent traffic replication tools to complete transaction playback.

[0005] The general process for ESB traffic diversion to complete transaction replay is as follows: After the traffic transaction request message is sent to the ESB, the ESB determines whether it should be sent to the old core or the new core to complete the transaction replay based on the service routing list. The replay result comparison is completed by comparing the results of the old and new core messages and comparing them with the database.

[0006] The independent traffic replication tool completes transaction replay. The general process is as follows: the traffic replication tool is used to perform message conversion and communication adaptation, obtain the old core transaction request, send it to the new core for transaction replay, and complete the data comparison through a separate database comparison function module.

[0007] The above two solutions have the following drawbacks: (1) When the traffic replication tool completes the transaction playback, the old and new cores must be homogeneous systems, and message conversion and communication adaptation are required; (2) Business data comparison cannot be performed, and a new comparison system must be built after playback to perform business data comparison separately; (3) The transaction playback order cannot be controlled, resulting in a high transaction playback failure rate and a low accuracy rate of business data comparison results; (4) When the main elements are inconsistent, the data cannot be updated, resulting in the failure of all subsequent playbacks. Summary of the Invention

[0008] To address the aforementioned issues, this invention provides a parallel playback method and system that uses technical means to accommodate two core business models and verify the functionality of the new core system. Simultaneously, verifying the functionality of the new core system through technical means reduces the workload of manual testing.

[0009] To achieve the above objectives, the present invention provides a parallel playback method, comprising:

[0010] Retrieve all gateway log files from the gateway log list, synchronize them to the playback system database, and record them all as newly entered.

[0011] Based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system.

[0012] The service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the playback system database.

[0013] All transactions corresponding to the gateway log files are segmented by time and replayed in chronological order. The original transaction data is obtained from the replay database, and the request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system.

[0014] Configure a transaction parameter table, assemble a comparison expression based on the transaction parameter table, and compare the new response message returned by the new core system with the response message returned by the old core system.

[0015] Configure and maintain the statistical SQL, execute the statistical SQL in both the new and old core systems, and compare the statistical results.

[0016] As a further improvement of the present invention, when parsing the gateway log file, the customer information filing interface and account opening interface of the old core system are identified according to the transaction code, and the customer number and account number returned by the customer information filing interface and account opening interface are registered in the intermediate table to form a piece of information, and the status of the piece of information is recorded as replaying.

[0017] When the transaction corresponding to any piece of information in the intermediate table is successfully replayed, the status of that piece of information in the intermediate table is updated to "replay successful".

[0018] As a further improvement of the present invention, when replaying each transaction, the customer number and account number are used as tokens to query the intermediate table;

[0019] If the query result is no record or the status is "replay successful", then continue replaying the transaction.

[0020] As a further improvement of the present invention, transaction parameters are set separately for different transactions, and different fields are compared and controlled for different transactions;

[0021] The transaction parameter table includes the fields that need to be compared.

[0022] As a further improvement of the present invention, the service code, transaction type, and transaction code in the transaction parameters are used as business primary keys to configure the transaction parameter table.

[0023] As a further improvement of the present invention, assembling a comparison expression based on the transaction parameter table includes:

[0024] Based on the fields to be compared configured in the transaction parameter table, the values ​​of each field are obtained from the new response message returned by the new core system and the response message returned by the old core system, and then assembled to obtain the comparison object.

[0025] As a further improvement of the present invention, statistical SQL is configured and maintained, and the statistical SQL is executed in both the new core system and the old core system respectively, and the statistical results are compared, including:

[0026] Using dates as the unit, multiple dimensions are set, and the transaction amounts are summarized according to the comparison dimensions. The transaction amounts of the new core system and the old core system under the same dimension are compared to see if they are the same. The dimensions include: institution, product, lending direction, currency, and reversal flag.

[0027] The statistical SQL is executed in both the new and old core systems to obtain and compare statistical results in the same dimensions. The statistical results include: number of accounts opened and transaction requests.

[0028] As a further improvement to the present invention, regarding the mechanism dimension, it includes:

[0029] Start the statistics SQL to summarize the number of transaction requests in the old core system and the new core system by institution, and compare whether the number of daily transaction requests for the same institution is the same.

[0030] Start the statistics SQL to summarize the transaction volume of the old core system and the new core system by institution, and compare whether the daily transaction volume of the same institution is the same.

[0031] As a further improvement to the present invention, account comparison is also included;

[0032] Parse the new response message returned by the new core system, obtain the account, and update the account field of the account information table in the new core system.

[0033] The present invention also provides a parallel playback system, including: a log file parsing module, a transaction playback module, a parameterized configuration module, and a comparison module;

[0034] The log file parsing module is used for:

[0035] Retrieve all gateway log files from the gateway log list, synchronize them to the playback system database, and record them all as newly entered.

[0036] Based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system.

[0037] The service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the playback system database.

[0038] The transaction replay module is used for:

[0039] All transactions corresponding to the gateway log files are segmented by time and replayed in chronological order. The original transaction data is obtained from the replay database, and the request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system.

[0040] The parameterized configuration module is used for:

[0041] Configure the transaction parameter table, and assemble the comparison expression based on the transaction parameter table;

[0042] The comparison module is used for:

[0043] Compare the new response message returned by the new core system with the response message returned by the old core system;

[0044] Configure and maintain the statistical SQL, execute the statistical SQL in both the new and old core systems, and compare the statistical results.

[0045] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0046] This invention supports the replay of non-homogeneous core systems (new and old) through a log parsing and replay scheme, without requiring message conversion or communication adaptation, and is non-intrusive to production. At the same time, the replay system includes a comparison module. After replay, business data factors and comparison dimensions can be flexibly set according to parameterized configuration to realize the replay and comparison functions. This can verify the accuracy of the results of the new core system. Verification through technical means also reduces the workload of manual testing.

[0047] This invention also employs a token scheme, which allows for parameterized configuration to control the playback order and improve the accuracy of comparison results.

[0048] The playback system of this invention is non-intrusive to the production system, relatively lightweight, and consumes few resources. The system includes multiple functional modules, such as log file parsing, message sending, and comparison. Each functional module can run and be deployed independently. The parameterized configuration of message field comparison and the comparison rules are of great significance for improving the comparison efficiency and the accuracy of the comparison results.

[0049] This invention features parameterized configuration for business data comparison, multi-dimensional comparison, summary comparison, and generation of comparison result files, resulting in a more comprehensive comparison and a more intuitive display of results. Attached Figure Description

[0050] Figure 1 This is a flowchart of a parallel playback method disclosed in one embodiment of the present invention;

[0051] Figure 2 This is a diagram of a parallel playback system architecture disclosed in one embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram illustrating the segmentation of transactions by time and multi-threaded playback according to an embodiment of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] The present invention will now be described in further detail with reference to the accompanying drawings:

[0055] like Figure 1 As shown, the present invention provides a parallel playback method, comprising the following steps:

[0056] S1, such as Figure 1 As shown, all gateway log files in the gateway log list are retrieved, synchronized to the playback system database, and all are recorded as newly entered.

[0057] in,

[0058] The gateway log file synchronized to the playback system database is recorded as a newly entered file, which facilitates monitoring the parsing status of the gateway log file.

[0059] S2, such as Figure 1As shown, based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system.

[0060] in,

[0061] When parsing the gateway log file, the old core system's customer information filing interface and account opening interface are identified based on the transaction code. The customer number and account number returned by the customer information filing interface and account opening interface are registered in the intermediate table to form a piece of information. The status of this piece of information is recorded as being replayed.

[0062] When the transaction corresponding to any piece of information in the intermediate table is successfully replayed, the status of that piece of information in the intermediate table will be updated to "replay successful".

[0063] S3, such as Figure 1 As shown, the service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the replay system database.

[0064] S4, such as Figure 3 As shown, all transactions corresponding to the gateway log files are segmented by time (e.g., transactions within one minute are replayed each time), and the transactions are replayed in chronological order. The original transaction data is obtained from the replay database, and a request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system for subsequent message comparison.

[0065] in,

[0066] When replaying each transaction, the customer number and account number are used as tokens to query the intermediate table.

[0067] If the query result is no record or the status is "replay successful", then continue replaying the transaction.

[0068] Furthermore,

[0069] Use multithreading to replay transactions within segments.

[0070] S5. Configure the transaction parameter table, assemble the comparison expression according to the transaction parameter table, and compare the new response message returned by the new core system with the response message returned by the old core system (i.e., comparison of the returned messages).

[0071] in,

[0072] Set separate transaction parameters for different transactions and perform comparison control on different fields for different transactions;

[0073] The transaction parameter table includes the fields that need to be compared.

[0074] Furthermore,

[0075] By using the service code, transaction type, and transaction code in the transaction parameters as the business primary key and configuring the transaction parameter table, different fields can be compared for different transactions. For example, transaction A only needs to compare the response code, but transaction B needs to satisfy multiple fields such as transaction amount and transaction account simultaneously. This can be achieved through field configuration.

[0076] Specifically,

[0077] Assemble the comparison expression based on the transaction parameter table, including:

[0078] Based on the fields to be compared configured in the transaction parameter table, the values ​​of each field are obtained from the new response message returned by the new core system and the response message returned by the old core system, and then assembled to obtain the comparison object.

[0079] S6. Configure and maintain statistical SQL, execute the statistical SQL in both the new core system and the old core system, and compare the statistical results.

[0080] in,

[0081] Using dates as the unit, multiple dimensions are set, and the transaction amount is summarized according to the comparison dimensions. The transaction amount under the same dimension in the new core system and the old core system is compared to see if they are the same. The dimensions include: institution, product, lending direction, currency, and reversal flag.

[0082] To mask the differences between tables in the new and old core systems, statistical SQL is configured and maintained. The statistical SQL is then loaded and executed in both the new and old core systems to obtain and compare statistical results in the same dimensions. The statistical results include: number of accounts opened and transaction requests.

[0083] Furthermore, regarding the institutional dimension, this includes:

[0084] Start the statistics SQL to summarize the number of transaction requests in the old core system and the new core system by institution, and compare whether the number of daily transaction requests for the same institution is the same.

[0085] Start the statistics SQL to summarize the transaction volume of the old core system and the new core system by institution, and compare whether the daily transaction volume of the same institution is the same.

[0086] Furthermore,

[0087] It also includes account comparison. During account comparison, the new response message returned by the new core system is parsed to obtain the account, and the account is updated to the account field of the account information table in the new core system.

[0088] It also includes comparing account balances, summarizing the account balances of the new core system and the old core system separately by institution, currency, and product, and comparing whether the account balances are equal.

[0089] like Figure 2 As shown, the present invention also provides a parallel playback system, including: a log file parsing module, a transaction playback module, a parameterized configuration module, and a comparison module;

[0090] The log file parsing module is used for:

[0091] Retrieve all gateway log files from the gateway log list, synchronize them to the playback system database, and record them all as newly entered.

[0092] Based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system.

[0093] The service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the replay system database.

[0094] The transaction replay module is used for:

[0095] All transactions corresponding to the gateway log files are segmented by time and replayed in chronological order. The original transaction data is obtained from the replay database, and a request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system.

[0096] The parameterized configuration module is used for:

[0097] Configure the transaction parameter table and assemble the comparison expression based on the transaction parameter table;

[0098] The comparison module is used for:

[0099] Compare the new response message returned by the new core system with the response message returned by the old core system;

[0100] Configure and maintain statistical SQL statements, execute the statistical SQL statements in both the new and old core systems, and compare the statistical results.

[0101] Advantages of this invention:

[0102] This invention supports the replay of non-homogeneous core systems (new and old) through a log parsing and replay scheme, without requiring message conversion or communication adaptation, and is non-intrusive to production. At the same time, the replay system includes a comparison module. After replay, business data factors and comparison dimensions can be flexibly set according to parameterized configuration to realize the replay and comparison functions. This can verify the accuracy of the results of the new core system. Verification through technical means also reduces the workload of manual testing.

[0103] This invention also employs a token scheme, which allows for parameterized configuration to control the playback order and improve the accuracy of comparison results.

[0104] The playback system of this invention is non-intrusive to the production system, relatively lightweight, and consumes few resources. The system includes multiple functional modules, such as log file parsing, message sending, and comparison. Each functional module can run and be deployed independently. The parameterized configuration of message field comparison and the comparison rules are of great significance for improving the comparison efficiency and the accuracy of the comparison results.

[0105] This invention features parameterized configuration for business data comparison, multi-dimensional comparison, summary comparison, and generation of comparison result files, resulting in a more comprehensive comparison and a more intuitive display of results.

[0106] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A parallel playback method, characterized in that, include: Retrieve all gateway log files from the gateway log list, synchronize them to the playback system database, and record them all as newly entered. Based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system. The service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the playback system database. All transactions corresponding to the gateway log files are segmented by time and replayed in chronological order. The original transaction data is obtained from the database of the replay system, and the request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system. Configure a transaction parameter table, assemble a comparison expression based on the transaction parameter table, and compare the new response message returned by the new core system with the response message returned by the old core system. Configure and maintain the statistical SQL, execute the statistical SQL in both the new and old core systems, and compare the statistical results.

2. The parallel playback method according to claim 1, characterized in that: When parsing the gateway log file, the customer information filing interface and account opening interface of the old core system are identified according to the transaction code. The customer number and account number returned by the customer information filing interface and account opening interface are registered in the intermediate table to form a piece of information, and the status of the piece of information is recorded as replaying. When the transaction corresponding to any piece of information in the intermediate table is successfully replayed, the status of that piece of information in the intermediate table is updated to "replay successful".

3. The parallel playback method according to claim 2, characterized in that: When replaying each transaction, the customer number and account number are used as tokens to query the intermediate table. If the query result is no record or the status is "replay successful", then continue replaying the transaction.

4. The parallel playback method according to claim 1, characterized in that: Set separate transaction parameters for different transactions and perform comparison control on different fields for different transactions; The transaction parameter table includes the fields that need to be compared.

5. The parallel playback method according to claim 1, characterized in that: Configure the transaction parameter table by using the service code, transaction type, and transaction code from the transaction parameters as the business primary key.

6. The parallel playback method according to claim 1, characterized in that: Assemble the comparison expression based on the transaction parameter table, including: Based on the fields to be compared configured in the transaction parameter table, the values ​​of each field are obtained from the new response message returned by the new core system and the response message returned by the old core system, and then assembled to obtain the comparison object.

7. The parallel playback method according to claim 1, characterized in that: Configure and maintain the statistical SQL, execute the statistical SQL in both the new and old core systems, and compare the statistical results, including: Using dates as the unit, multiple dimensions are set, and the transaction amounts are summarized according to the comparison dimensions. The transaction amounts of the new core system and the old core system under the same dimension are compared to see if they are the same. The dimensions include: institution, product, lending direction, currency, and reversal flag. The statistical SQL is executed in both the new and old core systems to obtain and compare statistical results in the same dimensions. The statistical results include: number of accounts opened and transaction requests.

8. The parallel playback method according to claim 7, characterized in that: For institutional dimensions, including: Start the statistics SQL to summarize the number of transaction requests in the old core system and the new core system by institution, and compare whether the number of daily transaction requests for the same institution is the same. Start the statistics SQL to summarize the transaction volume of the old core system and the new core system by institution, and compare whether the daily transaction volume of the same institution is the same.

9. The parallel playback method according to claim 1, characterized in that: This also includes account verification; Parse the new response message returned by the new core system, obtain the account, and update the account field of the account information table in the new core system.

10. A system for implementing the parallel playback method as described in any one of claims 1 to 9, characterized in that, include: Log file parsing module, transaction replay module, parameterized configuration module, and comparison module; The log file parsing module is used for: Retrieve all gateway log files from the gateway log list, synchronize them to the playback system database, and record them all as newly entered. Based on a specified date, multiple threads parse the gateway log file to obtain request information, request messages, response information, and response messages. During parsing, the status of the log file is changed to "parsing" in the playback system. The service code, transaction type, transaction code, channel, channel transaction details, transaction date, start time, end time, and response result are obtained from the request message in the gateway log file and registered in the playback system database. The transaction replay module is used for: All transactions corresponding to the gateway log files are segmented by time and replayed in chronological order. The original transaction data is obtained from the database of the replay system, and the request message is sent to the new core system through the replay system to obtain the new response message and response result returned by the new core system. The parameterized configuration module is used for: Configure the transaction parameter table, and assemble the comparison expression based on the transaction parameter table; The comparison module is used for: Compare the new response message returned by the new core system with the response message returned by the old core system; Configure and maintain the statistical SQL, execute the statistical SQL in both the new and old core systems, and compare the statistical results.

Images