A method and apparatus for determining message playback order

Abstract

This application provides a method and apparatus for determining the message playback order. The method includes: collecting multiple sets of historical transaction message data generated within a preset time period from a first business processing system; dividing a data table into regions according to a preset fragmentation strategy to determine multiple transaction data fragments and a first transmission relationship between each transaction data fragment; determining the corresponding transmission method between each transaction data fragment based on the first transmission relationship between each transaction data fragment; and sequentially sending the first request message corresponding to each set of historical transaction message data in each transaction data fragment to a second business processing system according to the message playback order formed by the corresponding transmission methods between each transaction data fragment, thereby completing the playback of multiple sets of historical transaction message data in the second business processing system. This application ensures the consistency of the execution timing by fragmenting the collected message data before performing message playback, thus facilitating the successful replacement of the core system subsequently.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for determining the message playback order. Background Technology

[0002] During the construction of a new core system to replace the original core system, the new core system needs to collaborate with the old core system to process request messages. In this process, the execution order of transaction messages in the new core system cannot be guaranteed to be consistent with the execution order in the original core system. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide at least one method and apparatus for determining the message playback order, which ensures the consistency of the execution timing by performing message playback after fragmenting the collected message data.

[0004] This application mainly includes the following aspects:

[0005] In a first aspect, embodiments of this application provide a method for determining the message playback order, the method comprising:

[0006] The system collects multiple sets of historical transaction message data generated within a preset time period from the first business processing system and stores these data in a data table. Each set of historical transaction message data includes a first request message and a corresponding first response message. The data table is divided into regions according to a preset sharding strategy to determine multiple transaction data shards and the first transmission relationship between each transaction data shard. Each transaction data shard includes at least one set of historical transaction message data. The first transmission relationship indicates whether there is a temporal correlation between the transaction data shards, and the preset sharding strategy indicates that the data table is divided into regions. The transmission method between each transaction data shard is determined based on the first transmission relationship between each transaction data shard. According to the message playback order formed by the corresponding transmission methods between each transaction data shard, the first request message corresponding to each set of historical transaction message data in each transaction data shard is sequentially sent to the second business processing system to complete the playback of multiple sets of historical transaction message data in the second business processing system.

[0007] In one possible implementation, the step of determining the corresponding transmission method between transaction data fragments based on the first transmission relationship between the transaction data fragments includes: setting multiple transaction data fragments that have a temporal correlation to a serial transmission method; and setting multiple transaction data fragments that do not have a temporal correlation to a parallel transmission method.

[0008] In one possible implementation, for each transaction data segment, at least one set of historical transaction message data within the transaction data segment is grouped intra-segment according to a preset grouping strategy to obtain at least one transaction data group. The preset grouping strategy indicates that the transaction data segment is divided according to the temporal correlation based on different dimensions of the data group. For each transaction data segment, a second transmission relationship between each transaction data group is determined according to the preset grouping strategy. The second transmission relationship indicates whether there is a temporal correlation between the transaction data groups. For each transaction data segment, the corresponding transmission method between each transaction data group within the transaction data segment is determined by the second transmission relationship between each transaction data group. Based on the transmission method corresponding to each transaction data segment and the corresponding transmission method between each transaction data group within each transaction data segment, a message playback order is formed.

[0009] In one possible implementation, the step of sending the first request message corresponding to each group of historical transaction message data within each transaction data segment to the second business processing system according to the message playback order formed by the corresponding sending methods between each transaction data segment includes: determining whether there is a preset replacement business field for the group of historical transaction message data based on the transaction type corresponding to each group of historical transaction message data; if there is no preset replacement business field for the group of historical transaction message data, then sending the first request message corresponding to each group of historical transaction message data within each transaction data segment to the second business processing system according to the message playback order formed by the corresponding sending methods between each transaction data segment.

[0010] In one possible implementation, for each group of historical transaction message data, the method further includes: when the group of historical transaction message data has a preset replacement service field, extracting a first target replacement service field corresponding to the preset replacement service field from the first response message corresponding to the group of historical transaction message data; adding the first target replacement service field to a reserved position in the first request message to which the group of historical transaction message data belongs in a preset manner to obtain the first request message corresponding to the group of historical transaction message data after the addition; and sending the first request message corresponding to each group of historical transaction message data in each transaction data segment to the second core business processing system in accordance with the message playback order formed by the corresponding sending methods between each transaction data segment.

[0011] In one possible implementation, the method further includes: parsing the added first request message using a second business processing system to parse out a first target replacement business field and at least one business request; obtaining the target business request corresponding to the first target replacement business field and determining the first target replacement business field as the response field corresponding to the target business request; for at least one business request other than the target business request, sequentially generating each corresponding response field in the business request according to the corresponding processing logic; forming a second response message from at least one response field; and returning the second response message to complete the return of multiple sets of historical transaction message data to the second core business processing system.

[0012] In one possible implementation, for each transaction data segment, the method further includes: if the first request message corresponding to any historical transaction message data in the transaction data segment fails to be sent, retransmitting the first request message corresponding to the historical transaction message data in real time and timing the retransmission; if the first request message corresponding to the historical transaction message data is successfully sent when the retransmission time is less than or equal to a first preset threshold, then sending the next historical transaction message data in the transaction data segment is executed; if the first request message corresponding to the historical transaction message data still fails to be sent when the retransmission time is greater than the first preset threshold, then storing the historical transaction message data in a pre-created sending failure array to complete the data storage of the historical transaction message data.

[0013] In one possible implementation, after completing the transmission of the first request message corresponding to the historical transaction message data within all transaction data fragments, the method further includes: extracting at least one group of previously failed first request messages from the transmission failure array; and retransmitting the at least one group of previously failed first request messages again according to a pre-specified transmission method until all first request messages are successfully transmitted.

[0014] In one possible implementation, the step of sending the first request message corresponding to each group of historical transaction message data to the first business processing system according to the corresponding sending method between each transaction data segment further includes: for the historical transaction message data in each transaction data segment, determining whether the historical transaction message data has a preset execution scenario; if the historical transaction message data has a preset execution scenario, then after completing the preset execution scenario, sending the first request message corresponding to each group of historical transaction message data to the second core business processing system according to the corresponding sending method between each transaction data segment.

[0015] Secondly, embodiments of this application also provide a device for determining the message playback order. The device includes: a collection module, used to collect multiple sets of historical transaction message data generated within a preset time period from a first business processing system, and store the multiple sets of historical transaction message data in a data table, each set of historical transaction message data including a first request message and a corresponding first response message; a sharding module, used to divide the data table into regions according to a preset sharding strategy, determine multiple transaction data shards and a first transmission relationship between each transaction data shard, each transaction data shard including at least one set of historical transaction message data, the first transmission relationship indicating whether there is a temporal correlation between the transaction data shards, and the preset sharding strategy indicating that the data table is split into regions; a determination module, used to determine the corresponding transmission method between each transaction data shard based on the first transmission relationship between each transaction data shard; and a playback module, used to sequentially send the first request message corresponding to each set of historical transaction message data in each transaction data shard to a second business processing system according to the message playback order formed by the corresponding transmission methods between each transaction data shard, so as to complete the playback of multiple sets of historical transaction message data in the second business processing system.

[0016] This application provides a method and apparatus for determining the message playback order. The method includes: collecting multiple sets of historical transaction message data generated within a preset time period from a first business processing system; dividing a data table into regions according to a preset fragmentation strategy to determine multiple transaction data fragments and a first transmission relationship between each transaction data fragment; determining the corresponding transmission method between each transaction data fragment based on the first transmission relationship between each transaction data fragment; and sequentially sending the first request message corresponding to each set of historical transaction message data in each transaction data fragment to a second business processing system according to the message playback order formed by the corresponding transmission methods between each transaction data fragment, thereby completing the playback of multiple sets of historical transaction message data in the second business processing system. This application ensures the consistency of the execution timing by fragmenting the collected message data before performing message playback. By fragmenting the collected message data before performing message playback, the consistency of the execution timing is ensured, facilitating the successful replacement of the core system subsequently.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for determining message playback order provided in an embodiment of this application is shown;

[0020] Figure 2 A schematic diagram of the structure of a method for determining the message playback order provided in an embodiment of this application is shown;

[0021] Figure 3 A schematic diagram of the structure of a message playback order determination device provided in an embodiment of this application is shown;

[0022] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0024] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] A bank's core system is crucial for the normal operation of its various businesses. Therefore, when the core system needs to be upgraded, in order to ensure the consistency and accuracy of bank data, the services corresponding to the original core system must first be stopped. Then, the data in the original core system must be synchronized to the new core system, and the correctness and validity of the data must be verified. Only then can the services of the new core system be restarted, thus completing the upgrade of the bank's core system.

[0026] In other words, during the construction of a new core system to replace the original core system, it is necessary to collect and execute transaction messages that have been run in the original core system and then replay them in the new core system. During this process, the execution order of transaction messages in the new core system cannot be guaranteed to be consistent with the execution order in the original core system.

[0027] Furthermore, for a given request message, the original core system will generate a corresponding response message according to its processing logic. When the new core system replays the request message, it will also generate a response message corresponding to the request message by applying its own new processing logic. However, due to the difference in processing logic within the core system, it is impossible to guarantee that a transaction that was successfully executed in the original core system will be consistent with the processing result of the original core system when it is replayed in the new core system.

[0028] Based on this, embodiments of this application provide a method and apparatus for determining the message playback order. By fragmenting the collected message data and then performing message playback, the consistency of the execution timing is ensured, facilitating the successful replacement of the core system subsequently. The details are as follows:

[0029] Please see Figure 1 , Figure 1 A flowchart illustrating a method for determining message playback order according to an embodiment of this application is shown. Please refer to... Figure 2 , Figure 2 This diagram illustrates the structure of a method for determining message playback order according to an embodiment of this application. Figure 1 and Figure 2 As shown, the method for determining the message playback order provided in this application embodiment can be applied to a server and includes the following steps:

[0030] S100: Collect multiple sets of historical transaction message data generated within a preset time period from the first business processing system, and store the multiple sets of historical transaction message data in a data table.

[0031] The first business processing system can be the bank's original core system, and the corresponding second business processing system can be the bank's new core system. Multiple sets of historical transaction message data collected will be stored in the database in the form of data tables. Each set of historical transaction message data includes a first request message and a corresponding first response message, and the set of historical transaction message data represents the data of transactions successfully completed in the first business processing system.

[0032] In practice, the preset time can be one trading day. Before collecting multiple sets of historical transaction message data generated within the preset time from the first business processing system, it is necessary to collect multiple sets of historical transaction message data from the trading day before the preset time from the first business processing system to lay the data foundation in the second business processing system before reading the data. The purpose of laying the data foundation is to align the historical transaction message data generated by the first business processing system and the second core business processing system.

[0033] S200: Divide the data table into regions according to the preset sharding strategy, and determine multiple transaction data shards and the first transmission relationship between each transaction data shard.

[0034] Each transaction data fragment includes at least one set of historical transaction message data, and the first transmission relationship indicates whether there is a temporal correlation between the transaction data fragments.

[0035] In practical implementation, multiple sets of historical transaction message data can be read according to a preset time level, and the read sets of historical transaction message data can be sharded according to a preset sharding strategy. The preset sharding strategy indicates the region splitting of the data table and indicates the sharding attributes used.

[0036] The preset sharding strategies include, but are not limited to, time sharding strategies, transaction processing institution sharding strategies, transaction processing personnel sharding strategies, and any combination of the above preset sharding strategies. Taking the time sharding strategy as an example, the time sharding strategy means that the transaction reception time is used as the splitting attribute to divide multiple sets of historical transaction message data in the data table into regions to obtain multiple transaction data shards.

[0037] In one specific embodiment, multiple sets of historical transaction message data generated within the target transaction day can be extracted from the first business processing system at the second level. For example, sets ① to ⑩ of historical transaction message data are extracted in the first second. If a time-slicing strategy is adopted to divide the sets ① to ⑩ of historical transaction message data, the time-slicing strategy here is to divide according to the reception time of the first request message, resulting in two transaction data slices corresponding to reception time 1 and reception time 2 as shown in Table 1, where reception time 1 is earlier than reception time 2.

[0038] Table 1:

[0039] First request message reception time Reception time 1 Reception time 2 Historical transaction message data ①②④⑦⑧ ③⑥⑤⑨⑩

[0040] As shown in Table 1, the two transaction data fragments are composed of historical transaction message data ①②④⑦⑧ and ③⑥⑤⑨⑩ extracted in the first second, respectively. For example, the transaction data fragment corresponding to receiving time 1 includes historical transaction message data ①②④⑦⑧.

[0041] The first transmission relationship indicates whether there is a temporal correlation between transaction data fragments. The first transmission relationship can be divided into dependency relationship and independence relationship in terms of temporal sequence. As shown in Table 1, since the reception time 1 is earlier than the reception time 2, the historical transaction message data ①②④⑦⑧ under the transaction data fragment corresponding to the reception time 1 must be earlier than the historical transaction message data ③⑥⑤⑨⑩ under the transaction data fragment corresponding to the reception time 2. That is, there is a temporal correlation between the two transaction data fragments, that is, the transaction data fragment corresponding to the reception time 2 depends on the transaction data fragment corresponding to the reception time 1.

[0042] In one specific embodiment, if the transaction processing institution fragmentation strategy is adopted to divide the historical transaction message data of groups ① to ⑩, the transaction processing institution fragmentation strategy is to divide according to the reception time of the first request message, resulting in three transaction data fragments under transaction processing institution A, transaction processing institution B and transaction processing institution C as shown in Table 2.

[0043] Table 2:

[0044]

[0045] As shown in Table 2, the three transaction data segments are composed of historical transaction message data extracted in the first second, namely ①②④③⑥, ⑤⑦, and ⑧⑨⑩. For example, the transaction data segment corresponding to transaction processing institution A includes historical transaction message data ①②④③⑥.

[0046] As shown in Table 2, since transaction processing institution A, transaction processing institution B and transaction processing institution C are three independent transaction processing institutions, their data processing timing is only related to the data processing within their own institutions. However, the data processing between the transaction processing institutions is independent of each other. Therefore, the corresponding transmission relationship between the three transaction data fragments is independent.

[0047] This application can further group each data shard according to actual needs. Specifically, after obtaining the transaction data shards, the method also includes:

[0048] For each transaction data segment, at least one set of historical transaction message data within the transaction data segment is grouped intra-segment according to a preset grouping strategy to obtain at least one transaction data group. For each transaction data segment, a second transmission relationship between each transaction data group is determined according to the preset grouping strategy. The second transmission relationship indicates whether there is a temporal correlation between the transaction data groups. For each transaction data segment, the corresponding transmission method between each transaction data group within the transaction data segment is determined by the second transmission relationship between each transaction data group. Based on the transmission method corresponding to each transaction data segment and the corresponding transmission method between each transaction data group within each transaction data segment, a message replay order is formed.

[0049] Furthermore, the specific implementation of step S200, which involves dividing the data table into regions according to a preset sharding strategy and determining multiple transaction data shards and the first transmission relationship between each transaction data shard, can also be as follows:

[0050] For each transaction data shard, at least one set of historical transaction message data within the transaction data shard is grouped within the shard according to a preset grouping strategy to obtain at least one transaction data group. The preset grouping strategy indicates that the transaction data shard is divided according to the temporal correlation based on different dimensions of data grouping.

[0051] For each transaction data slice, a second transmission relationship is determined between each transaction data packet according to a preset grouping strategy. The second transmission relationship indicates whether there is a temporal correlation between the transaction data packets.

[0052] For each transaction data segment, the second transmission relationship between each transaction data group determines the corresponding transmission method between each transaction data group within that transaction data segment.

[0053] The message replay order is formed based on the sending method corresponding to each transaction data fragment and the sending methods between the transaction data groups within each transaction data fragment.

[0054] Specifically, the preset grouping strategy indicates different dimensions of data grouping, dividing transaction data into shards according to temporal relationships. The preset grouping strategies include time grouping strategy, transaction dependency grouping strategy, transaction processing personnel grouping strategy, scenario triggering grouping strategy, and any combination of the above preset sharding strategies.

[0055] Specifically, before grouping, it is necessary to determine the splitting attributes corresponding to the preset sharding strategy. If the splitting attributes are the same as the dimensions corresponding to the preset grouping strategy, no grouping is performed. If the splitting attributes are different from the dimensions corresponding to the preset grouping strategy, each transaction data shard is further grouped according to the preset grouping strategy.

[0056] For example, if the preset sharding strategy is a time-based sharding strategy, and its corresponding splitting attribute is time, and the preset grouping strategy is a time-based grouping strategy, and its corresponding grouping dimension is also time, then no grouping will be performed.

[0057] In one specific embodiment, if time slicing is performed first according to Table 1 and then the historical transaction message data in each transaction data slice is grouped again according to the transaction processing personnel grouping strategy, it can be seen that 6 transaction data groups as shown in Table 3 can be obtained.

[0058] Table 3:

[0059]

[0060] As shown in Table 3, the first request message reception time includes reception time 1 and reception time 2, which are the corresponding two transaction data fragments. The transaction processing personnel pepole includes teller a, teller b and teller c, which are the specific grouping methods corresponding to the transaction processing personnel grouping strategy. As shown in Table 3, a total of 6 transaction data groups were obtained.

[0061] These are composed of historical transaction message data ①②④, ⑦, ⑧, ③⑥, ⑤ and ⑨⑩ respectively. For example, under the transaction data segment of receiving time 1, the transaction data can be divided according to teller a, teller b and teller c to obtain the transaction data grouping under the transaction data segment of receiving time 1.

[0062] It can also be divided according to any combination of preset sharding strategies, such as in Table 3. Furthermore, a transaction dependency grouping strategy can be introduced to group the data again. Transaction dependency means that there is a sequential processing order between historical transaction message data. For example, for a transaction data group consisting of historical transaction message data ①②④, historical transaction message data ①② belong to account opening transactions, while historical transaction message data ④ belongs to non-account opening transactions. Logically, the account opening transaction should be executed first, followed by subsequent transactions after account opening. In this case, historical transaction message data ①②, which are both account opening transactions, can be further grouped into the same transaction data group, while historical transaction message data ④ is itself a separate transaction data group.

[0063] On the other hand, the scenario-triggered grouping strategy refers to grouping historical transaction message data according to the execution scenario associated with the historical transaction message data, so that when sending this type of transaction data group, the historical transaction message data in the group can be processed according to the processing mechanism corresponding to the associated scenario.

[0064] Different preset grouping strategies indicate the second transmission relationship between the obtained transaction data packets. The second transmission relationship includes dependency relationship and independence relationship. Taking the above embodiment as an example, in Table 3, under the condition that the transaction data fragments under different first request message reception times have a time dependency relationship, further, taking the transaction data fragment under reception time 1 as an example, the three transaction data packets contained therein do not have a processing time conflict because they are grouped according to different transaction processing personnel. Therefore, the three transaction data packets under the transaction data fragment corresponding to reception time 1 are independent of each other, and the historical transaction data ①②④⑦⑧ can be transmitted in parallel.

[0065] Furthermore, the processing method for grouping the obtained transaction data is the same as that for sharding the transaction data, and the repetitive parts will not be repeated.

[0066] S300: Determine the corresponding transmission method between each transaction data fragment based on the first transmission relationship between each transaction data fragment.

[0067] The transmission methods include serial transmission and parallel transmission.

[0068] In a preferred embodiment, the step of determining the corresponding transmission method between transaction data fragments based on the first transmission relationship between the transaction data fragments includes:

[0069] Multiple transaction data fragments that have a temporal correlation are segmented and sent serially, while multiple transaction data fragments that do not have a temporal correlation are segmented and sent in parallel.

[0070] S400. According to the message playback order formed by the corresponding sending methods between each transaction data segment, the first request message corresponding to each group of historical transaction message data in each transaction data segment is sent to the second business processing system in sequence to complete the playback of multiple groups of historical transaction message data in the second business processing system.

[0071] In a preferred embodiment, the step of sending the first request message corresponding to each group of historical transaction message data within each transaction data segment to the second business processing system according to the message playback order formed by the corresponding sending methods between each transaction data segment includes:

[0072] Based on the transaction type corresponding to each group of historical transaction message data, determine whether there is a preset replacement business field for that group of historical transaction message data. If there is no preset replacement business field for that group of historical transaction message data, then according to the message playback order formed by the corresponding sending methods between each transaction data segment, send the first request message corresponding to each group of historical transaction message data in each transaction data segment to the second business processing system.

[0073] Specifically, the preset replacement business field can be a business field related to the serial number or a business field generated based on the serial number. The business field related to the serial number includes, but is not limited to, number, receipt number, and serial number. In this application, the first request message may include multiple business requests. The business processing system responds to each business request contained in the received first request message in sequence and forms a response message corresponding to the first request message. The transaction type refers to the type corresponding to each business request. The transaction type indicates whether each business request contains a preset replacement business field that needs to be replaced.

[0074] In a preferred embodiment, for each set of historical transaction message data, the method further includes:

[0075] When a set of historical transaction message data contains a preset replacement business field, the first target replacement business field corresponding to the preset replacement business field is extracted from the first response message corresponding to the set of historical transaction message data. The first target replacement business field is added to the reserved position in the first request message to which the set of historical transaction message data belongs in a preset manner to obtain the first request message corresponding to the set of historical transaction message data after the addition. According to the message playback order formed by the corresponding sending methods between each transaction data segment, the first request message corresponding to each set of historical transaction message data in each transaction data segment is sent to the second core business processing system.

[0076] Because the processing logic of the first and second business processing systems differs, the responses related to sequence numbers in the received unified request messages may differ in meaning between the two systems. For example, if the first request message is for retrieving the customer name corresponding to customer number 001, the first business processing system will determine the corresponding customer name as "Zhang San" according to its original business processing logic and return it to the customer in the first response message. However, when the second business processing system replays the response, for the same customer number 001, the correspondence between multiple customer numbers and multiple customer names may differ from that in the first business processing system. This could result in the customer name in the second response message for the same customer number 001 being "Li Si," which is inconsistent with the first response message, leading to errors in the response information.

[0077] Therefore, before the second business processing system replays the corresponding first request message, if it is identified that the first request message contains a preset replacement business field that needs to be responded to according to the sequence number, it is necessary to extract the first target replacement business field corresponding to the preset replacement business field from the first response message corresponding to the first request message in the first business processing system. The first target replacement business field is the response field of the preset replacement field. For example, if there is a business request in the first request message to obtain the customer name corresponding to customer number 001, then the preset replacement business field is the customer name determined according to 001. Then, the first target replacement business field corresponding to the customer name determined according to 001 is extracted from the first response message as "Li Si". "Li Si" is directly added to the reserved position in the first request message sent to the second business processing system. Then, according to the message replay order formed by the corresponding sending method between each transaction data segment, the first request message corresponding to each group of historical transaction message data in each transaction data segment is sent to the second core business processing system for further processing.

[0078] In a preferred embodiment, the method further includes:

[0079] Based on the corresponding transmission methods between each transaction data fragment, the message playback order corresponding to the first request message for each group of historical transaction data can be formed. For example, as shown in Table 4, according to the transaction processing personnel fragmentation strategy, three transaction data fragments corresponding to teller a, teller b, and teller c are obtained under the transaction processing personnel pepole. The three transaction data fragments are transmitted in parallel. Furthermore, according to the time grouping strategy, under the receiving time time, each transaction data fragment obtains two transaction data groups corresponding to receiving time 1 and receiving time 2, as shown in Table 4. A total of 6 transaction data groups are obtained. Since receiving time 2 is later than receiving time 1, in the transaction data fragment corresponding to teller a, the historical transaction data ① and ⑦ are transmitted serially, first ① and then ⑦. In this way, the message playback order corresponding to the first request message for each group of historical transaction data can be formed.

[0080] Table 4:

[0081]

[0082] In a preferred embodiment, the step of sending the first request message corresponding to each group of historical transaction message data to the first business processing system according to the corresponding sending method between each transaction data fragment further includes:

[0083] For each transaction data segment containing historical transaction messages, determine whether the historical transaction message contains a preset execution scenario. If the historical transaction message contains a preset execution scenario, after completing the preset execution scenario, send the first request message corresponding to each group of historical transaction messages to the second business processing system according to the corresponding sending method between each transaction data segment.

[0084] Specifically, the preset execution scenario refers to the historical transaction message data being associated with other execution processes. It is necessary to obtain the corresponding process completion results after the completion of other processes in order to continue the current replay process.

[0085] For example, when sending a historical transaction message requires other online processing, the sending process of the historical transaction message needs to be briefly blocked. After the other processing is completed, the sending process of the historical transaction message can be restarted to continue.

[0086] In a preferred embodiment, the method further includes:

[0087] In another preferred embodiment, after receiving the first request message, the method of the second service processing system further includes:

[0088] The first request message after addition is parsed to extract the first target replacement business field and at least one business request. The target business request corresponding to the first target replacement business field is obtained, and the first target replacement business field is determined as the response field corresponding to the target business request. For at least one business request other than the target business request, each corresponding response field in the business request is generated in sequence according to the corresponding processing logic. The second response message is formed by at least one response field and returned to complete the playback of multiple sets of historical transaction message data in the second core business processing system.

[0089] In one specific embodiment, when the second core business processing system responds to the received first request message, it needs to parse the first request message to extract at least one business request and determine whether a first target replacement business field exists. If a first target replacement business field exists, the target business request associated with the first target replacement business field is determined from the at least one business request. The second business processing system does not need to respond to the target business request and directly uses the first target replacement business field as its own response field for the target business request. For other business requests, it directly responds according to its own logic and obtains the corresponding response field. This avoids the need for new processing logic within the second business processing system to be generated based on the preset replacement field. This ensures that the relevant business fields generated by the first and second business processing systems based on the same sequence number remain consistent, thus successfully completing the playback of the first request message.

[0090] For example, if the first request message is to obtain the customer name corresponding to customer number 001, the preset replacement business field is "001" and the first target replacement business field is "Li Si". "Li Si" is directly added to the first request message sent to the second business processing system according to the preset rules to generate the second request message. Then, after the second business processing system receives the second request message, it directly uses "Li Si" as the second response request.

[0091] Optionally, the transmission methods also include group retransmission, end-of-transmission retransmission, data storage, and scenario execution.

[0092] In a preferred embodiment, for each transaction data shard, the method further includes:

[0093] If the first request message corresponding to any historical transaction message in the transaction data segment fails to be sent, the first request message corresponding to the historical transaction message is retransmitted in real time, and the retransmission time is timed. If the first request message corresponding to the historical transaction message is successfully sent when the retransmission time is less than or equal to a first preset threshold, the next historical transaction message in the transaction data is sent. If the first request message corresponding to the historical transaction message still fails to be sent when the retransmission time is greater than the first preset threshold, the historical transaction message data is stored in a pre-created sending failure array to complete the data storage of the historical transaction message data.

[0094] In another preferred embodiment, after sending the first request message corresponding to the historical transaction message data within all transaction data fragments, the method further includes:

[0095] Extract at least one set of first request messages that previously failed to be sent from the failed sending array, and resend them again according to the pre-specified sending method until all first request messages are successfully sent.

[0096] Specifically, firstly, data is retransmitted for the first request message that fails to be sent in each transaction data segment. Then, after all the first request messages in all transaction data segments have been sent, all the corresponding first request messages in all transaction data segments are retransmitted again to ensure that all first request messages are eventually sent successfully.

[0097] Based on the same application concept, this application also provides a message playback device corresponding to the message playback method provided in the above embodiments. Since the principle of the device in this application is similar to the message playback method in the above embodiments of this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0098] Please see Figure 3 , Figure 3 This illustration shows a structural schematic diagram of a device for determining the message playback order according to an embodiment of this application. Figure 2 As shown, the message playback device includes:

[0099] The acquisition module 600 is used to acquire multiple sets of historical transaction message data generated within a preset time from the first business processing system, and store the multiple sets of historical transaction message data in a data table. Each set of historical transaction message data includes a first request message and a corresponding first response message.

[0100] The sharding module 610 is used to shard the data table according to a preset sharding strategy, determine multiple transaction data shards and the first transmission relationship between each transaction data shard, each transaction data shard includes at least one set of historical transaction message data, the first transmission relationship indicates whether there is a temporal dependency relationship between the transaction data shards, and the preset sharding strategy indicates the sharding attribute used to split the data table.

[0101] The second determining module 620 is used to determine the corresponding sending method between each transaction data segment based on the first sending relationship between each transaction data segment.

[0102] The playback module 630 is used to send the first request message corresponding to each group of historical transaction message data in each transaction data segment to the second business processing system in sequence according to the message playback order formed by the corresponding sending methods between each transaction data segment, so as to complete the playback of multiple groups of historical transaction message data in the second business processing system.

[0103] Based on the same application concept, please refer to Figure 4 , Figure 4 This illustration shows a schematic diagram of an electronic device 700 provided in an embodiment of this application. The electronic device 700 includes a processor 710, a memory 720, and a bus 730. The memory 720 stores machine-readable instructions executable by the processor 710. When the electronic device 700 is running, the processor 710 and the memory 720 communicate through the bus 730. When the machine-readable instructions are executed by the processor 710, the steps of the message playback order determination method as described in any of the above embodiments are executed.

[0104] Based on the same concept, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when run by a processor, executes the steps of the message playback order determination method provided in the above embodiments.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0106] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0108] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A method for determining a packet playback order, characterized by, The method includes: The system collects multiple sets of historical transaction message data generated within a preset time period from the first business processing system and stores the multiple sets of historical transaction message data in a data table. Each set of historical transaction message data includes a first request message and a corresponding first response message. The data table is divided into regions according to a preset sharding strategy, and multiple transaction data shards and a first transmission relationship between each transaction data shard are determined. Each transaction data shard includes at least one set of historical transaction message data. The first transmission relationship indicates whether there is a temporal correlation between the transaction data shards. The preset sharding strategy indicates that the data table is split into regions. The preset sharding strategy includes a time sharding strategy, a transaction processing institution sharding strategy, a transaction processing personnel sharding strategy, and any combination of the above preset sharding strategies. The transmission method between each transaction data segment is determined by the first transmission relationship between each transaction data segment, and the transmission method includes serial transmission method and parallel transmission method; According to the message playback order formed by the corresponding sending methods between each transaction data segment, the first request message corresponding to each group of historical transaction message data in each transaction data segment is sent to the second business processing system in sequence to complete the playback of multiple groups of historical transaction message data in the second business processing system.

2. The method of claim 1, wherein, The step of determining the corresponding transmission method between each transaction data fragment based on the first transmission relationship between each transaction data fragment includes: Multiple transaction data that have a temporal correlation are fragmented and set to be sent serially; Multiple transaction data that are not related in time sequence are fragmented and set to be sent in parallel.

3. The method of claim 1, wherein, The method further includes: For each transaction data shard, at least one set of historical transaction message data within the transaction data shard is grouped within the shard according to a preset grouping strategy to obtain at least one transaction data group. The preset grouping strategy indicates that the transaction data shard is divided according to the temporal correlation based on different dimensions of data grouping. The preset grouping strategy includes time grouping strategy, transaction dependency grouping strategy, transaction processing personnel grouping strategy, scenario triggering grouping strategy, and any combination of the above preset sharding strategies. For each transaction data slice, a second transmission relationship is determined between each transaction data packet according to a preset grouping strategy. The second transmission relationship indicates whether there is a temporal correlation between the transaction data packets. For each transaction data segment, the second transmission relationship between each transaction data group determines the corresponding transmission method between each transaction data group within that transaction data segment. The message replay order is formed based on the sending method corresponding to each transaction data fragment and the sending methods between the transaction data groups within each transaction data fragment.

4. The method according to claim 1, characterized in that, The steps of sending the first request message corresponding to each group of historical transaction message data within each transaction data segment to the second business processing system according to the message playback order formed by the corresponding sending methods between each transaction data segment include: Determine whether there is a preset replacement business field in each group of historical transaction message data based on the transaction type corresponding to that group of historical transaction message data; If the set of historical transaction message data does not have a preset replacement business field, the first request message corresponding to each set of historical transaction message data in each transaction data segment is sent to the second business processing system according to the message playback order formed by the corresponding sending methods between each transaction data segment.

5. The method according to claim 4, characterized in that, For each set of historical transaction message data, the method further includes: When the set of historical transaction message data contains a preset replacement business field, extract the first target replacement business field corresponding to the preset replacement business field from the first response message corresponding to the set of historical transaction message data; The first target replacement business field is added to the reserved position in the first request message to which the group of historical transaction message data belongs in a preset manner to obtain the first request message corresponding to the group of historical transaction message data after the addition; According to the message playback order formed by the corresponding sending methods between each transaction data segment, the first request message corresponding to each group of historical transaction message data in each transaction data segment is sent to the second business processing system.

6. The method according to claim 5, characterized in that, The method further includes: The second business processing system is used to parse the added first request message to extract the first target replacement business field and at least one business request. Obtain the target business request corresponding to the first target replacement business field, and determine the first target replacement business field as the response field corresponding to the target business request; For at least one of the business requests other than the target business request, generate each corresponding response field in the business request in sequence according to the corresponding processing logic; The second response message is formed by at least one response field; Return a second response message to complete the playback of multiple sets of historical transaction message data in the second business processing system.

7. The method according to claim 1, characterized in that, For each transaction data shard, the method further includes: If the first request message corresponding to any historical transaction message in the transaction data segment fails to be sent, the first request message corresponding to the historical transaction message will be retransmitted in real time, and the retransmission time will be counted. If the first request message corresponding to the historical transaction message data is successfully sent when the retransmission time is less than or equal to the first preset threshold, then the next historical transaction message data within the transaction data will be sent. If the retransmission time exceeds the first preset threshold and the first request message corresponding to the historical transaction message data still fails to be sent, the historical transaction message data is stored in a pre-created sending failure array to complete the data storage of the historical transaction message data.

8. The method according to claim 7, characterized in that, After completing the transmission of the first request message corresponding to the historical transaction message data within all transaction data fragments, the method further includes: Extract at least one set of first request messages that previously failed to be sent from the failed send array; According to the pre-specified sending method, resend at least one group of first request messages that failed to be sent previously until all first request messages are sent successfully.

9. The method according to claim 1, characterized in that, The step of sending the first request message corresponding to each group of historical transaction message data to the first business processing system according to the corresponding sending method between each transaction data fragment also includes: For each transaction data segment containing historical transaction messages, determine whether the historical transaction message data contains a preset execution scenario; If the historical transaction message data has a preset execution scenario, then after the preset execution scenario is completed, the first request message corresponding to each group of historical transaction message data is sent to the second business processing system according to the corresponding sending method between each transaction data fragment.

10. A device for determining the message playback order, characterized in that, The device includes: The acquisition module is used to acquire multiple sets of historical transaction message data generated within a preset time from the first business processing system, and store the multiple sets of historical transaction message data in a data table. Each set of historical transaction message data includes a first request message and a corresponding first response message. The sharding module is used to divide the data table into regions according to a preset sharding strategy, determine multiple transaction data shards and a first transmission relationship between each transaction data shard, each transaction data shard includes at least one set of historical transaction message data, the first transmission relationship indicates whether there is a temporal correlation between transaction data shards, the preset sharding strategy indicates that the data table is split into regions, the preset sharding strategy includes time sharding strategy, transaction processing institution sharding strategy, transaction processing personnel sharding strategy and any combination of the above preset sharding strategies; The determination module is used to determine the corresponding transmission method between each transaction data segment based on the first transmission relationship between each transaction data segment, wherein the transmission method includes serial transmission method and parallel transmission method; The playback module is used to send the first request message corresponding to each group of historical transaction message data in each transaction data segment to the second business processing system in the order of message playback formed by the corresponding sending methods between each transaction data segment, so as to complete the playback of multiple groups of historical transaction message data in the second business processing system.

Images