A transaction message processing method, device and system

Abstract

The present invention discloses a transaction message processing method, device, and system, relating to the field of automatic programming technology. A specific implementation of the method includes: receiving a transaction message sent by a transaction party, parsing multiple fields included in the transaction message and the data in each field; synchronously storing the first-class fields and their data in the original business table corresponding to the transaction message in a database using data processing SQL statements related to the first-class fields configured in a transaction interface; and, if a newly added second-class field with a read-only feature is present in the multiple fields included in the transaction message, writing the newly added second-class field into the transaction interface, publishing the data corresponding to the second-class field, the newly added second-class field, and the data of the newly added second-class field to a message middleware as a message body, and asynchronously storing the data in an extended business table in the database via the message middleware. This implementation effectively reduces computing resource consumption.

Description

Technical Field

[0001] The present invention relates to the technical field of automatic programming, and in particular to a transaction message processing method, device and system. Background Art

[0002] As the transaction methods, channels, and scenarios involved in financial services become increasingly complex and diverse, the number of transaction elements included in transaction messages continues to increase. This is to meet the needs of refined identification of transaction scenarios, precise transaction risk management, and transaction information statistics. Currently, a unified data table is used to maintain and manage the large number of transaction elements and their data in relevant transaction messages.

[0003] The existing method of managing a large number of transaction elements and data through a unified data table is that once there is a change in the transaction element or data, all data in the entire data table will be linked for insertion and update operations, resulting in a waste of computing resources. Summary of the Invention

[0004] In view of this, an embodiment of the present invention provides a transaction message processing method, device and system, which isolates transaction elements that are not involved in updates from transaction elements that are involved in updates, thereby greatly reducing the amount of data in the data table where the transaction elements involved in updates are located. Then, processing the data table where the transaction elements involved in updates are located can effectively reduce the loss of computing resources.

[0005] To achieve the above object, according to one aspect of an embodiment of the present invention, a transaction message processing method is provided, comprising:

[0006] Receiving a transaction message sent by a transaction party, parsing multiple fields included in the transaction message and data in each field;

[0007] Synchronously storing the first-category fields and their data in the original business table corresponding to the transaction message in the database through the data processing SQL statements related to the first-category fields configured in the transaction interface, wherein the first-category fields are fields with rewritable characteristics;

[0008] In the case that there is a newly added second-category field with a read-only feature among the multiple fields included in the transaction message, the newly added second-category field is written into the transaction interface, and based on the original second-category field with a read-only feature already written into the transaction interface and the newly added second-category field, the data corresponding to the original second-category field, the newly added second-category field and the data of the newly added second-category field are published in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category field and / or the newly added second-category field in the database through the message middleware.

[0009] Optionally,

[0010] After parsing the multiple fields included in the transaction message and the data of each field, the method further includes: storing the parsed multiple fields and the data of each field into a preset buffer area;

[0011] For the multiple fields stored in the cache area and the data of each of the fields, the step of synchronously storing the first-category fields and their data in the original business table corresponding to the transaction message in the database is performed, or the data corresponding to the original second-category fields, the newly added second-category fields and the data of the newly added second-category fields are published in the form of message bodies to the message middleware.

[0012] Optionally, publishing the data corresponding to the original second-category fields, the newly added second-category fields, and the data of the newly added second-category fields to the message middleware in the form of a message body, so that the message body is asynchronously stored in an extended business table related to the second-category fields and / or the newly added second-category fields in a database through the message middleware, includes:

[0013] For the original second-category field, generating a first message body corresponding to the data corresponding to the original second-category field;

[0014] For the newly added second-category fields, combining the newly added second-category fields and their data into the second message body;

[0015] The first message body and the second message body are published to the message middleware, so that the subscriber who subscribes to the first message body or the second message body obtains the first message body or the second message body from the message middleware, and stores the data in the first message body or the newly added second category fields and their data in the second message body in the extended business table related to the second category fields and / or the newly added second category fields.

[0016] Optionally, the message middleware is configured with a corresponding message queue for each extended service table, wherein one of the subscribers subscribes to the message queues corresponding to one or more extended service tables managed by it;

[0017] Publishing the message body to the message middleware includes:

[0018] The first message body is published to the message queue corresponding to the extended service table related to the first message body in the message middleware, and the second message body is published to the message queue corresponding to the extended service table related to the second message body in the message middleware.

[0019] Optionally,

[0020] Each of the message queues is configured with a topic;

[0021] Before publishing the first message body and the second message body to the message middleware, the method further includes: configuring topics for the first message body and the second message body respectively;

[0022] Publishing the first message body to the message queue corresponding to the extended business table related to the first message body in the message middleware, and publishing the second message body to the message queue corresponding to the extended business table related to the second message body in the message middleware, includes: publishing the first message body to the message queue in the message middleware with the same subject as the first message body, and publishing the second message body to the message queue in the message middleware with the same subject as the second message body.

[0023] Optionally, the transaction message processing method further includes:

[0024] Monitoring the subscriber via a message retry server;

[0025] When the message retry server monitors that the subscriber fails to obtain the first message body or the second message body from the message middleware, it sends a retry instruction for the message body to enable the subscriber to obtain the first message body or the second message body from the message middleware again.

[0026] Optionally, the transaction message processing method further includes:

[0027] When the message retry server monitors that the number of times the subscriber fails to obtain the same first message body or second message body from the message middleware reaches a preset number threshold, the message retry server records an error log for the subscriber to obtain the failed first message body or second message body, and records the failed first message body or second message body in the error log, so as to provide the user with fields and data that are not recorded in the extended business table through the error log.

[0028] Optionally, the transaction message processing method further includes:

[0029] The first message body or the second message body in the error log is resent to the message middleware or the subscriber through the message retry server, so as to re-store the first message body or the second message body in the extended service table.

[0030] Optionally,

[0031] The related original business tables and extended business tables are related to each other;

[0032] The method further includes: upon receiving a data query request sent by a querying party, acquiring data corresponding to the data query request from the associated original service table and the extended service table, and providing the queried data to the querying party.

[0033] Optionally, the fields included in the transaction message are marked with a first identifier for indicating a first type of field or a second identifier for indicating a second type of field; and the transaction message processing method further includes:

[0034] Writing the field into the transaction interface;

[0035] When it is identified that a field included in the transaction message is marked with a first identifier, determining that the field is a first-category field, and filling the field with a corresponding data processing SQL statement;

[0036] When it is identified that a field included in the transaction message is marked with a second identifier, it is determined that the field is a second type field.

[0037] In a second aspect, an embodiment of the present invention provides a transaction message processing device, comprising: a parsing module, a storage management module, and a message middleware, wherein:

[0038] The parsing module is configured to receive a transaction message sent by a transaction party, and parse multiple fields included in the transaction message and the data in each field;

[0039] The storage management module is configured to, if a newly added second-category field with a read-only feature exists among the multiple fields included in the transaction message, write the newly added second-category field into the transaction interface, and based on the original second-category field with a read-only feature already written into the transaction interface and the newly added second-category field, publish the data corresponding to the original second-category field, the newly added second-category field, and the data of the newly added second-category field in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category field and / or the newly added second-category field in the database through the message middleware.

[0040] In a third aspect, an embodiment of the present invention provides a transaction message processing system, comprising: a transaction subsystem, a database storing an original business table and an extended business table, and a transaction message processing device provided by the second aspect and its related embodiments, wherein:

[0041] The transaction subsystem is used to send transaction messages to the transaction message processing device;

[0042] The transaction message processing device is used to synchronously store the first-category fields and their data among the multiple fields in the original business table corresponding to the transaction message, and when there is a newly added second-category field with a read-only feature among the multiple fields included in the transaction message, write the newly added second-category field into the transaction interface, and based on the original second-category fields with read-only features and the newly added second-category fields already written into the transaction interface, publish the data corresponding to the original second-category fields, the newly added second-category fields and the data of the newly added second-category fields in the form of message body publishing to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or the newly added second-category fields in the database through the message middleware.

[0043] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, including:

[0044] one or more processors;

[0045] a storage device for storing one or more programs,

[0046] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any one of the above embodiments.

[0047] According to another aspect of the embodiments of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described in any one of the above embodiments is implemented.

[0048] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the method described in any one of the above embodiments is implemented.

[0049] One embodiment of the above invention has the following advantages or beneficial effects: through the data processing SQL statements related to the first-category fields configured in the transaction interface, the first-category fields and their data with rewritable characteristics parsed from the transaction message are synchronously stored in the original business table of the transaction message, and the second-category fields and their data with read-only characteristics are published to the configured message middleware in the form of message body publishing, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or newly added second-category fields in the database through the message middleware, thereby isolating existing or newly added transaction elements that do not involve data updates (second-category fields and their data) from transaction elements that involve data updates (first-category fields and their data), and eliminating the need to generate SQL statements for the second-category fields. The data volume of the data table containing the transaction elements involved in the update is greatly reduced, simplifying the transaction elements in the original business table. Therefore, processing the data table containing the transaction elements involved in the update, such as update, modification, and insertion, can effectively reduce computing resource loss.

[0050] In addition, the message body is asynchronously stored in the extended business table related to the second category fields and / or the newly added second category fields in the database through the message middleware, so that the data of the second category fields that are not involved in data updates does not affect the processing of the original business table. That is, in the process of asynchronously storing the message body in the extended business table related to the second category fields and / or the newly added second category fields in the database through the message middleware, the original business table can still be processed continuously and will not be locked, which can effectively improve the efficiency of data processing.

[0051] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.

[0053] Figure 1 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;

[0054] Figure 2 1 is a schematic diagram of the main process of a transaction message processing method according to an embodiment of the present invention;

[0055] Figure 3 is a schematic diagram of the main process of storing the second type of fields and their data in the extended service table corresponding to the transaction message through asynchronous storage according to an embodiment of the present invention;

[0056] Figure 4 Schematic diagram of the relationship between message middleware and message queues according to an embodiment of the present invention;

[0057] Figure 5 2 is a schematic diagram of the main process of retrying to store a message body according to an embodiment of the present invention;

[0058] Figure 6 is a schematic diagram of the main process of recording error logs according to an embodiment of the present invention;

[0059] Figure 7 is a schematic diagram of the main process of a transaction message processing method according to another embodiment of the present invention;

[0060] Figure 8 is a schematic diagram of main modules of a transaction message processing device according to an embodiment of the present invention;

[0061] Figure 9 is a schematic diagram of main devices of a transaction message processing system according to an embodiment of the present invention;

[0062] Figure 10 It is a structural diagram of a computer system of a terminal device or a transaction message processing server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0063] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0064] In the transaction messages generated during the transaction process, some transaction elements (fields and their data, such as name, gender, identity information, account number, etc.) will not be changed or processed once stored. Some transaction elements (such as transaction amount, transaction type, balance, transaction time, etc.) will change in each transaction message generated. If the transaction elements that have changed are stored together with the transaction elements that have not changed, the transaction elements that have not changed (i.e., read-only fields) will be inserted and updated in conjunction with each other, resulting in a waste of computing resources. In other words, many fields in the existing business tables that store transaction data only store records for query purposes and do not participate in the logical function judgment and modification in the transaction process. These fields that are not updated need to be updated in conjunction with each other during the business table update process, resulting in an increase in computing resources and time-consuming updates. In addition, existing transaction elements that have changed are stored together with those that have not changed, and fields are frequently added, involving a large scope of modification (each time a field is added to a business table, regardless of whether the field is read-only, the transaction message interface and the database statements for inserting, updating, and various queries for the added field need to be modified. This requires modification of all fields, resulting in a large amount of modification content and prone to errors. It also affects a wide range of businesses, especially some business-related fields, which are only used for subsequent queries and warehousing and do not involve accounting or business logic judgment. However, they still require the addition of business table-related updates), posing a production safety risk. In addition, because the database storage itself takes longer to complete with the addition of columns, it will affect write and read efficiency, transaction response time, and database performance.

[0065] In order to solve the problem of storing transaction elements in existing transaction messages, embodiments of the present invention provide a transaction message processing method, device, and system. The transaction message processing method and device can be implemented on a server.

[0066] Figure 1 An exemplary system architecture 100 is shown to which a transaction message processing method or a transaction message processing apparatus according to an embodiment of the present invention may be applied.

[0067] like Figure 1As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, a transaction message processing server 105, transaction message generation servers 106 and 107, a database 108, and a message retry server 109. Different transaction systems are run in transaction message generation servers 106 and 107. Network 104 is used to provide a medium for communication links between terminal devices 101, 102, and 103 and transaction message processing server 105, between transaction message generation servers 106 and 107 and transaction message processing server 105, between transaction message generation server 106 and transaction message generation server 107, between terminal devices 101, 102, and 103 and transaction message generation servers 106 and 107, between transaction message generation server 106 and database 108, between transaction message processing server 105 and message retry server 109, and between database 108 and message retry server 109. The network 104 may include various connection types, such as wired, wireless communication links, fiber optic cables, and the like.

[0068] Users can use terminal devices 101, 102, and 103 to interact with transaction message processing server 105 via network 104, sending transaction messages generated by terminal devices 101, 102, and 103 to transaction message processing server 105 for processing, and can also send query information to transaction message processing server 105. Users can also use terminal devices 101, 102, and 103 to interact with transaction message generation servers 105, 106, and 107 via network 104 to conduct online transactions. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as banking applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (for example only).

[0069] In addition, the transaction message generation servers 106 and 107 may also interact with the transaction message processing server 105 via the network 104 to send transaction messages generated by the transaction message generation servers 106 and 107 to the transaction message processing server 105 for processing. The transaction message generation servers 105, 106, and 107 may be installed with various systems used for transactions, such as a bank transaction system, a shopping platform system, etc. (for example only).

[0070] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0071] The transaction message processing server 105 can be a server that provides various services, such as a backend management server that supports transaction messages generated by terminal devices or transaction systems (for example only). The backend management server can parse the transaction messages and store the parsed fields and data in the database 108.

[0072] The message retry server 109 monitors the transaction message processing server 105 and, if the transaction message processing server 105 fails to store the message body, sends a retry instruction to the transaction message processing server 105, causing the transaction message processing server 105 to re-store the message body. Furthermore, the message retry server 109 records any message body storage failures in an error log to ensure data consistency.

[0073] It should be understood that Figure 1 The number of terminal devices, networks, transaction message processing servers, transaction message generation servers, and databases in the embodiment is merely illustrative. Any number of terminal devices, networks, transaction message processing servers, transaction message generation servers, and databases may be used as required.

[0074] The schematic diagram of the main process of the transaction message processing method implemented by the transaction message processing server can be shown as follows: Figure 2 As shown. Figure 2 As shown, the transaction message processing method may include the following steps:

[0075] Step S201: Receive a transaction message sent by a transaction party, and parse the multiple fields included in the transaction message and the data in each field;

[0076] Transaction messages are messages used to transmit transaction information across systems and modules within the Spring framework, typically in XML and JSON formats. Therefore, the transaction message processing servers and transaction message generation servers (e.g., e-commerce platforms and banking systems) relied upon to implement the methods of the present invention are all implemented within the same Spring framework.

[0077] For example, when a user makes a purchase at a mall, restaurant, or online, a financial transaction is generated. This financial transaction carries information related to the purchase and is then processed by various intermediate systems or platforms to transfer the user's purchase amount to the merchant's account. Financial transactions are typically exchanged via internationally standardized messages, such as those used by organizations like UnionPay, MasterCard, and VISA. Based on this, the transaction message includes information about the type of transaction (consumption, withdrawal, repayment, return, etc.), verification data, and the purchase amount that should be submitted for each transaction. For example, fields may include user name, transaction amount, and transaction account number.

[0078] Step S202: Using the data processing SQL statements related to the first-category fields configured in the transaction interface, the first-category fields and their data among the multiple fields are synchronously stored in the original business table corresponding to the transaction message in the database, wherein the first-category fields are fields with rewritable characteristics;

[0079] A field with rewritable properties is one whose data is used for logical processing such as transaction verification and transaction judgment. For example, fields with rewritable properties may include transaction amount and transaction type.

[0080] Step S203: In the case that a newly added second-category field with a read-only feature exists in the multiple fields included in the transaction message, the newly added second-category field is written into the transaction interface, and based on the original second-category field with a read-only feature already written into the transaction interface and the newly added second-category field, the data corresponding to the original second-category field, the newly added second-category field, and the data of the newly added second-category field are published in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category field and / or the newly added second-category field in the database through the message middleware.

[0081] The second type of read-only field refers to fields whose data does not participate in logical processing such as transaction verification and transaction judgment, and is only provided for query. For example, fields with read-only characteristics may include user name, full name, age, identity information, account number, etc.

[0082] The newly added second type of fields generally refer to fields that have a read-only feature and do not exist in the existing extended business table.

[0083] It can be understood that for the second type of fields with read-only characteristics, there is no need to configure data processing SQL statements for the second type of fields in the transaction interface, which effectively reduces the transaction interface SQL statements.

[0084] Since the second type of fields and their data with read-only characteristics only need to be stored and processed without waiting for processing results, they can be consumed and processed in an asynchronous storage manner to improve production efficiency and user experience.

[0085] Among them, before the above-mentioned step S203, it can also be determined whether the second-category fields with read-only characteristics and their data have been stored in the extended business table corresponding to the transaction message. If they have been stored, the second-category fields with read-only characteristics and their data are directly deleted to avoid repeated storage of the second-category fields with read-only characteristics and their data; if they have not been stored, the above-mentioned step S203 is executed.

[0086] Among them, the fields included in the transaction message are marked with a first identifier for indicating a first type of field or a second identifier for indicating a second type of field; accordingly, the above-mentioned transaction message processing method may further include: writing the field into the transaction interface; when it is identified that the field included in the transaction message is marked with the first identifier, determining that the field is a first type of field and filling the field with its corresponding data processing SQL statement; when it is identified that the field included in the transaction message is marked with the second identifier, determining that the field is a second type of field. Through this process, fields are automatically added to the transaction interface, which reduces manual participation and enables the entire transaction message processing process to be completed automatically. Figure 2 In the illustrated embodiment, the first-category fields and their data with rewritable characteristics parsed from the transaction message are synchronously stored in the original business table of the transaction message through the data processing SQL statements related to the first-category fields configured in the transaction interface, and the second-category fields and their data with read-only characteristics are published to the configured message middleware in the form of message body publishing, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or newly added second-category fields in the database through the message middleware, thereby isolating existing or newly added transaction elements that do not involve data updates (second-category fields and their data) from transaction elements that involve updates (first-category fields and their data), and eliminating the need to generate SQL statements for the second-category fields. This greatly reduces the amount of data in the data table where the transaction elements involved in the update are located, simplifies the transaction elements in the original business table, and processes the data table where the transaction elements involved in the update are located, such as update, modification, and insertion operations, which can effectively reduce computing resource loss.

[0087] In addition, the message body is asynchronously stored in the extended business table related to the second category fields and / or the newly added second category fields in the database through the message middleware, so that the data of the second category fields that are not involved in data updates does not affect the processing of the original business table. That is, in the process of asynchronously storing the message body in the extended business table related to the second category fields and / or the newly added second category fields in the database through the message middleware, the original business table can still be processed continuously and will not be locked, which can effectively improve the efficiency of data processing.

[0088] In addition, through the above-mentioned processing of transaction messages, the asynchronous storage method can effectively and safely undertake the second type of fields and their data with read-only characteristics while maintaining the stability of the transaction system performance and the unchanged time consumption of financial transactions, greatly reducing the scope of transformation and facilitating subsequent maintenance and transformation of the system. The second type of fields and their data with read-only characteristics are not lost, which significantly improves the user consumption experience.

[0089] In an embodiment of the present invention, after parsing the multiple fields included in the transaction message and the data of each field, the method further includes: storing the parsed multiple fields and the data of each field in a preset cache area; and, for the multiple fields and the data of each field stored in the cache area, executing the step of synchronously storing the first-category fields and their data in the original business table corresponding to the transaction message in the database, or publishing the data corresponding to the original second-category fields, the newly added second-category fields, and the data of the newly added second-category fields in the form of message bodies to the message middleware. By setting up the cache area, the requirements of synchronous storage and asynchronous storage can be met at the same time, and the loss of unstored data can be avoided to ensure data consistency.

[0090] In the embodiment of the present invention, Figure 3 As shown, the specific implementation method of publishing the data corresponding to the original second-category fields, the newly added second-category fields, and the data of the newly added second-category fields in the form of message bodies to the message middleware, so as to asynchronously store the message bodies in the extended business table related to the second-category fields and / or the newly added second-category fields in the database through the message middleware includes the following steps:

[0091] Step S301: for the original second-category fields, generate a first message body corresponding to the data corresponding to the original second-category fields; for the newly added second-category fields, combine the newly added second-category fields and their data into a second message body;

[0092] This step may involve encapsulating individual data into a message body, combining a single second-category field and its data into a message body, or combining multiple second-category fields and their data belonging to the same extended service table into a message body. In a preferred embodiment, multiple second-category fields and their data belonging to the same extended service table are combined into a message body, thereby effectively improving data processing efficiency.

[0093] The second message body, created by combining the first message body or the newly added second-category fields and their data, ensures that the first or second message body received by the subscriber from the message middleware is readable. Furthermore, by combining the newly added second-category fields and their data with the message body, the newly added second-category fields and their data are bound, facilitating management and effectively improving the accuracy of asynchronous storage.

[0094] Step S302: Publish the first message body and the second message body to the message middleware, so that the subscriber who subscribes to the first message body or the second message body obtains the first message body or the second message body from the message middleware, and stores the data in the first message body or the newly added second-category fields and their data in the second message body into the extended business table related to the second-category fields and / or the newly added second-category fields.

[0095] The message middleware is configured with a corresponding message queue for each extended service table, wherein: Figure 4 The diagram shows the relationship between message middleware and message queue. Figure 4 As shown, the message middleware may include multiple message queues, such as message queue 1, message queue 2, and message queue 3. Each message queue corresponds to an extended service table. For example, extended service table A corresponds to message queue 1, extended service table B corresponds to message queue 2, and extended service table C corresponds to message queue 3. A subscriber subscribes to the message queues corresponding to one or more extended service tables it manages. Accordingly, a specific implementation of publishing a message body to the message middleware may include publishing a first message body to the message queue corresponding to the extended service table associated with the first message body in the message middleware, and publishing a second message body to the message queue corresponding to the extended service table associated with the second message body in the message middleware. This enables management of different types of message bodies or different types of second-category fields and their data through message queue classification, facilitating subscriptions for subscribers. Multiple threads or multiple subscribers can simultaneously retrieve first or second message bodies from multiple message queues, effectively improving the efficiency of asynchronous storage.

[0096] Among them, the subscriber generally refers to a thread or processor or server corresponding to the extended business table that can read the first message body or the second message body stored in the message queue or message middleware, and can store the data parsed from the first message body or the second type of field and its data parsed from the second message body in the corresponding extended business table.

[0097] In an embodiment of the present invention, each message queue is configured with a topic; accordingly, before publishing the first message body and the second message body to the message middleware, the method may further include: configuring topics for the first message body and the second message body respectively; publishing the first message body to the message queue corresponding to the extended business table related to the first message body in the message middleware, and publishing the second message body to the message queue corresponding to the extended business table related to the second message body in the message middleware, including: publishing the first message body to the message queue in the message middleware that is consistent with the topic of the first message body, and publishing the second message body to the message queue in the message middleware that is consistent with the topic of the second message body. By configuring the topic, the first message body and the second message body are selected according to the topic of the message queue, which can ensure the convenience and accuracy of placing the first message body and the second message body into the message queue.

[0098] In the embodiment of the present invention, Figure 5 As shown, the transaction message processing method may further include the following steps:

[0099] Step S501: monitoring the subscriber through the message retry server;

[0100] Step S502: When the message retry server monitors that the subscriber fails to obtain the first message body or the second message body from the message middleware, it sends a retry instruction for the message body to enable the subscriber to obtain the first message body or the second message body from the message middleware again.

[0101] By setting up a message retry server, the monitoring process is isolated from subscribers and data providers (bank systems, trading platforms, and other systems that provide transaction messages), ensuring the independence of monitoring and facilitating the management of the monitoring process. At the same time, it can implement a mechanism for subscribers to obtain message retries, thereby improving the robustness of transaction message processing.

[0102] In the embodiment of the present invention, Figure 6 As shown, the transaction message processing method may further include the following steps:

[0103] Step S601: When the message retry server monitors that the number of times a subscriber fails to obtain the same first message body or second message body from the message middleware reaches a preset number threshold, the message retry server records an error log for the subscriber's failed acquisition of the first message body or second message body;

[0104] By controlling the number threshold, the subscriber can be prevented from falling into an infinite loop, thereby ensuring that the first message body or the second message body subsequently stored in the message queue can be correctly stored.

[0105] Step S602: Record the failed first message body or the failed second message body in the error log, so as to provide the user with fields and data that are not recorded in the extended service table through the error log.

[0106] By recording the failed first or second message body in the error log, users can easily view the data in the first message body or the second category fields and their data in the second message body that were not stored in the error log. In addition, when a user queries data, the message retry server can also read data related to the user's query from the error log. If the data is read, it can be provided to the user, preventing data loss and ensuring data consistency.

[0107] In an embodiment of the present invention, the transaction message processing method may further include: resending the first or second message body in the error log to the message middleware or subscriber via a message retry server, thereby re-storing the first or second message body in the extended service table. This ensures the consistency of asynchronous storage and maximizes the successful storage of read-only information in the extended service table. This process further automates the storage of data that failed to be stored, effectively improving the integrity of the data in the extended service table.

[0108] In an embodiment of the present invention, the original business table and the extended business table are associated with each other; accordingly, the transaction processing method may further include: upon receiving a data query request from a querying party, obtaining data corresponding to the data query request from the associated original business table and the extended business table, and providing the queried data to the querying party. The original business table and the extended business table may be associated via a primary key. During a user's data query, data corresponding to the data query request is obtained from both the original business table and the extended business table, respectively, to ensure the integrity of the query data provided to the querying party.

[0109] The following example uses the client installed on a user's terminal device to make an online payment through a third-party payment platform, and then processes the transaction messages generated by the terminal device, the third-party payment platform, and the bank system to explain the transaction message processing method in detail. Figure 7 As shown, the transaction message processing method may include the following steps:

[0110] Step S701: The transaction message processing server receives transaction messages sent by the terminal device, the third-party payment platform, and the bank system respectively, and parses the multiple fields included in the transaction message and the data in each field;

[0111] For example, the transaction message sent by the terminal device may include the following fields: user name registered on the client, terminal device identification, payee information, selected bank card account, payment amount, payment type, etc.; the transaction message sent by the third-party payment platform may include the following fields: user name, payee information, selected bank, bank card account, transaction amount, transaction type, etc.; the transaction message sent by the bank system may include the following fields: payer bank card account, payee account, payee payment amount, payer balance, payee receipt amount, payee balance, etc.

[0112] Among them, the terminal device identifier included in the transaction message sent by the terminal device can determine whether the user's bank card account has been stolen after the terminal device identifier corresponding to the user name has changed, thereby reducing the risk of the user paying through a third party.

[0113] Step S702: The transaction message processing server stores the parsed multiple fields and the data of each field into a preset buffer area;

[0114] Step S703: The transaction message processing server uses the data processing SQL statements related to the first-category fields configured in the transaction interface to synchronously store the first-category fields and their data among the multiple fields stored in the buffer into the original business table corresponding to the transaction message in the database. The first-category fields are rewritable fields.

[0115] Since the original business table only stores fields with rewritable characteristics and their data, in the transaction interface, only relevant data processing SQL statements can be configured for fields with rewritable characteristics (i.e., first-category fields), such as SQL statements involving data insertion, data update, data modification and other operations.

[0116] For example, among the fields included in the transaction message of the above-mentioned terminal device, the payee information, payment amount, payment type, etc. belong to the first category of fields; among the fields included in the transaction message of the third-party payment platform, the payee information, the selected bank, the transaction amount, the transaction type, etc. belong to the first category of fields; in the transaction message of the banking system, the payer payment amount, the payer balance, the payee receipt amount, the payee balance, etc. belong to the first category of fields.

[0117] Step S704: The transaction message processing server generates a first message body from the data of the second type fields already existing in the extended business table among the multiple fields stored in the buffer area, and combines the newly added second type fields with read-only characteristics and their data into the second message body;

[0118] For example, in the transaction message sent by the terminal device, the user name registered on the client, the terminal device identifier, the selected bank card account, etc. belong to the second category of fields; in the transaction message sent by the third-party payment platform, the payee information, the selected bank, the transaction amount, the transaction type, etc. belong to the existing second category of fields or the newly added second category of fields; in the transaction message sent by the banking system, the payee bank card account number, the payee account number, etc. belong to the existing second category of fields or the newly added second category of fields.

[0119] Step S705: The transaction message processing server configures topics for the first message body and the second message body;

[0120] For example, the topic can be configured according to different sources of information, such as terminal device information, third-party payment platform information, bank system information, etc., or it can be configured according to the type of information, such as payer information, payee information, etc.

[0121] The following takes the example of a subject configured according to different information sources, such as terminal device information, third-party payment platform information, and bank system information. In the transaction message sent by the terminal device, the subject of the message body composed of the fields belonging to the second category, such as the user name registered on the client, the terminal device identifier, and the selected bank card account number, and their data, is configured as the terminal device identifier; in the transaction message sent by the third-party payment platform, the subject of the message body composed of the fields belonging to the second category, such as the payee information, the selected bank, the transaction amount, and the transaction type, and their data, is configured as the third-party payment platform identifier; in the transaction message sent by the bank system, the subject of the message body composed of the fields belonging to the second category, such as the payee bank card account number and the payee account number, and their data, is configured as the bank system identifier, etc.

[0122] Step S706: The transaction message processing server publishes the first message body and the second message body to the message queue in the message middleware that matches the subject of the first message body and the second message body;

[0123] The message middleware is configured with a corresponding message queue for each extended service table, wherein a subscriber (the subscriber may be a thread, manager, or server of the extended service table) subscribes to the message queues corresponding to one or more extended service tables it manages; each message queue is configured with a topic;

[0124] For example, configure the message body with the terminal device identifier as the subject and send it to the message queue corresponding to the terminal device. Figure 4 The message queue 1 shown in FIG. 1 is configured to send the message body whose subject is the identifier of the third-party payment platform to the message queue corresponding to the third-party payment platform. Figure 4The message queue 2 shown in the figure is configured with the message body of the bank system identifier and sent to the message queue corresponding to the bank system. Figure 4 Message queue 3 is shown.

[0125] Step S707: The subscriber of the subscribed message body obtains the first message body and / or the second message body from the message middleware, and monitors the subscriber through the message retry server. If the monitoring detects that the first message body and / or the second message body are obtained successfully, step S708 is executed; if the monitoring detects that the first message body and / or the second message body are obtained unsuccessfully, step S911 is executed.

[0126] Step S708: The subscriber of the subscribed message body stores the second type of fields and their data in the second message body into the extended business table associated with the second type of fields, and determines whether the data in the first message body already exists in the extended business table of the transaction message. If yes, execute step S709; otherwise, execute step S710.

[0127] Step S709: The subscriber of the subscribed message body deletes the first message body retrieved from the message middleware and ends the current process;

[0128] Step S710: The subscriber who subscribes to the message body stores its data in the first message body into the extended business table related to the second type of field, and ends the current process;

[0129] The original business table and the extended business table may both be configured with a primary key, and the related original business table and the extended business table may be associated with each other through the primary key.

[0130] Step S711: the message retry server sends a retry instruction for the first message body and / or the second message body to the subscriber;

[0131] Step S712: The subscriber obtains the first message body and / or the second message body from the message middleware again;

[0132] Step S713: When the message retry server monitors that the number of times the subscriber fails to obtain the same message body from the message middleware reaches a preset number threshold, the message retry server records an error log for the subscriber's failed acquisition of the first message body and / or the second message body, and records the failed first message body and / or the failed second message body in the error log;

[0133] Step S714: the message retry server resends the first message body and / or the second message body in the error log to the message middleware or the subscriber, so that the first message body and / or the second message body are re-stored in the extended service table;

[0134] Step S715: The message retry server provides the user with fields and data that are not recorded in the extended service table through the error log.

[0135] It's worth noting that the "first category" and "second category" in the aforementioned first and second category fields refer to whether the fields are rewritable or read-only, and do not limit the number or order of the fields. The "first" and "second" in the first and second message bodies refer to different types of message bodies, and do not limit the number or order of the fields.

[0136] Figure 8 The embodiment of the present invention provides a transaction message processing device 800, which may include: a parsing module 801, a storage management module 802 and a message middleware 803, wherein:

[0137] The parsing module 801 is used to receive a transaction message sent by a transaction party and parse the multiple fields included in the transaction message and the data in each field;

[0138] The storage management module 802 is used to write the newly added second-category fields into the transaction interface when there are newly added second-category fields with read-only characteristics among the multiple fields included in the transaction message, and based on the original second-category fields with read-only characteristics and the newly added second-category fields already written into the transaction interface, publish the data corresponding to the original second-category fields, the newly added second-category fields, and the data of the newly added second-category fields in the form of message bodies to the configured message middleware 803, so that the message bodies are asynchronously stored in the extended business table related to the second-category fields and / or the newly added second-category fields in the database through the message middleware 803.

[0139] In an embodiment of the present invention, the storage management module 802 is further used to store the parsed multiple fields and the data of each field into a preset cache area, and for the multiple fields and their data stored in the cache area, execute the step of synchronously storing the first category of fields and their data in the original business table corresponding to the transaction message in the database, or the step of publishing the data corresponding to the original second category of fields, the newly added second category fields, and the data of the newly added second category fields into the message middleware in the form of message body publishing.

[0140] In an embodiment of the present invention, the storage management module 802 is further used to generate a first message body corresponding to the data corresponding to the original second-category field; for the newly added second-category field, combine the newly added second-category field and its data into the second message body; publish the first message body and the second message body to the message middleware, so that the subscriber who subscribes to the first message body or the second message body obtains the first message body or the second message body from the message middleware, and stores the data in the first message body or the newly added second-category field and its data in the second message body in the extended business table related to the second-category field and / or the newly added second-category field.

[0141] In an embodiment of the present invention, the message middleware 803 is configured with a corresponding message queue for each extended business table, wherein a subscriber subscribes to the message queue corresponding to one or more extended business tables managed by it; accordingly, the storage management module 802 is further used to publish the first message body to the message queue corresponding to the extended business table related to the first message body in the message middleware, and publish the second message body to the message queue corresponding to the extended business table related to the second message body in the message middleware.

[0142] In an embodiment of the present invention, each message queue in the message middleware 803 is configured with a topic; accordingly, the storage management module 802 is further used to configure topics for the first message body and the second message body respectively; the first message body is published to the message queue in the message middleware 803 that matches the topic of the first message body, and the second message body is published to the message queue in the message middleware 803 that is consistent with the topic of the second message body.

[0143] In the embodiment of the present invention, the related original business table and the extended business table are associated with each other; the transaction message processing device 800 further includes: a query module 804, wherein,

[0144] The query module 804 is configured to, upon receiving a data query request from a querying party, obtain data corresponding to the data query request from the associated original service table and extended service table, and provide the queried data to the querying party.

[0145] like Figure 9 As shown, the embodiment of the present invention provides a transaction message processing system 900, which may include: one or more transaction subsystems 901, a database 902 storing the original business table and the extended business table, and the above-mentioned Figure 8 The transaction message processing device 800 shown, wherein,

[0146] The transaction subsystem 901 is used to send transaction messages to the transaction message processing device 800;

[0147] The transaction message processing device 800 is used to synchronously store the first-category fields and their data among the multiple fields into the original business table corresponding to the transaction message, and when there is a newly added second-category field with a read-only feature among the multiple fields included in the transaction message, write the newly added second-category field into the transaction interface, and based on the original second-category fields with read-only features and the newly added second-category fields already written into the transaction interface, publish the data corresponding to the original second-category fields, the newly added second-category fields and the data of the newly added second-category fields in the form of message body publishing to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or the newly added second-category fields in the database through the message middleware.

[0148] In an embodiment of the present invention, the transaction message processing system 900 may further include: a message retry server 903, wherein:

[0149] The message retry server 903 is used to monitor the subscriber; when it is monitored that the subscriber fails to obtain the first message body or the second message body from the message middleware, a retry instruction for the first message body or the second message body is sent to enable the subscriber to obtain the first message body or the second message body from the message middleware again.

[0150] In an embodiment of the present invention, the message retry server 903 is further used to record an error log for the subscriber to obtain the failed first message body or second message body when the message retry server monitors that the number of times the subscriber fails to obtain the same first message body or second message body from the message middleware reaches a preset number threshold, and record the failed first message body or second message body in the error log, so as to provide the user with fields and data that are not recorded in the extended business table through the error log.

[0151] Reference below Figure 10 , which shows a structural diagram of a computer system 1000 suitable for implementing a terminal device or a transaction message processing server according to an embodiment of the present invention. Figure 10 The computer system 1000 shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0152] like Figure 10As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage unit 1008 into a random access memory (RAM) 1003. Various programs and data required for the operation of the system 1000 are also stored in the RAM 1003. The CPU 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0153] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1008 including a hard disk; and a communication section 1009 including a network interface card such as a LAN card or a modem. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1010 as needed, so that computer programs read therefrom can be installed into the storage section 1008 as needed.

[0154] In particular, according to the embodiments disclosed herein, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed herein include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1009, and / or installed from a removable medium 1011. When the computer program is executed by the central processing unit (CPU) 1001, the above-mentioned functions defined in the system of the present invention are performed.

[0155] It should be noted that the computer-readable medium described in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0157] The modules described in the embodiments of the present invention may be implemented via software or hardware. The modules described may also be located within a processor. For example, a processor may be described as comprising a parsing module and a storage management module. The names of these modules do not, in some cases, limit the modules themselves. For example, a parsing module may also be described as "a module that parses multiple fields included in a transaction message and the data in each field."

[0158] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The computer-readable medium carries one or more programs. When the one or more programs are executed by a device, the device includes: receiving a transaction message sent by a transaction party, parsing multiple fields included in the transaction message and the data of each field; synchronously storing the first-category fields and their data in the original business table corresponding to the transaction message in a database through data processing SQL statements related to the first-category fields configured in the transaction interface, wherein the first-category fields are fields with rewritable characteristics; when there is a newly added second-category field with a read-only characteristic among the multiple fields included in the transaction message, writing the newly added second-category field to the transaction interface, and based on the original second-category field with a read-only characteristic already written into the transaction interface and the newly added second-category field, publishing the data corresponding to the original second-category field, the newly added second-category field, and the data of the newly added second-category field in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category field and / or the newly added second-category field in the database through the message middleware.

[0159] As another aspect, an embodiment of the present invention further provides a computer program product, including a computer program, which implements the method described in any of the above embodiments when executed by a processor.

[0160] According to the technical solution of an embodiment of the present invention, the first-category fields and their data with rewritable characteristics parsed from the transaction message are synchronously stored in the original business table of the transaction message through the data processing SQL statements related to the first-category fields configured in the transaction interface, and the second-category fields and their data with read-only characteristics are published to the configured message middleware in the form of message body publishing, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or newly added second-category fields in the database through the message middleware, thereby isolating existing or newly added transaction elements that do not involve data updates (second-category fields and their data) from transaction elements that involve data updates (first-category fields and their data), and there is no need to generate SQL statements for the second-category fields, so that the amount of data in the data table where the transaction elements involved in the update are located is greatly reduced, and the transaction elements in the original business table are simplified. Therefore, processing the data table where the transaction elements involved in the update are located, such as update, modification, insertion and other operations, can effectively reduce the loss of computing resources.

[0161] In addition, through the above-mentioned processing of transaction messages, the asynchronous storage method can effectively and safely undertake the second type of fields and their data with read-only characteristics while maintaining the stability of the transaction system performance and the unchanged time consumption of financial transactions, greatly reducing the scope of transformation and facilitating subsequent maintenance and transformation of the system. The second type of fields and their data with read-only characteristics are not lost, which significantly improves the user consumption experience.

[0162] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A transaction message processing method, characterized in that: include: Receiving a transaction message sent by a transaction party, parsing multiple fields included in the transaction message and data in each field; Synchronously storing the first-category fields and their data in the original business table corresponding to the transaction message in the database through the data processing SQL statements related to the first-category fields configured in the transaction interface, wherein the first-category fields are fields with rewritable characteristics; In the case that there is a newly added second-category field with a read-only feature among the multiple fields included in the transaction message, the newly added second-category field is written into the transaction interface, and based on the original second-category field with a read-only feature already written into the transaction interface and the newly added second-category field, the data corresponding to the original second-category field, the newly added second-category field and the data of the newly added second-category field are published in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category field and / or the newly added second-category field in the database through the message middleware.

2. The method according to claim 1, characterized in that After parsing the multiple fields included in the transaction message and the data of each field, the method further includes: storing the parsed multiple fields and the data of each field into a preset buffer area; For the multiple fields and their data stored in the cache area, the step of synchronously storing the first category fields and their data in the multiple fields into the original business table corresponding to the transaction message in the database is performed, or the step of publishing the data corresponding to the original second category fields, the newly added second category fields and the data of the newly added second category fields into the message middleware in the form of message body publication is performed.

3. The method according to claim 1, characterized in that Publishing the data corresponding to the original second-category fields, the newly added second-category fields, and the data of the newly added second-category fields to the message middleware in the form of a message body, so that the message body is asynchronously stored in an extended business table related to the second-category fields and / or the newly added second-category fields in a database through the message middleware, includes: For the original second-category field, generating a first message body corresponding to the data corresponding to the original second-category field; For the newly added second-category fields, combining the newly added second-category fields and their data into the second message body; The first message body and the second message body are published to the message middleware, so that a subscriber who subscribes to the first message body or the second message body obtains the first message body or the second message body from the message middleware, and stores the data in the first message body or the newly added second-category fields and their data in the second message body in an extended business table related to the second-category fields and / or the newly added second-category fields.

4. The method according to claim 3, characterized in that The message middleware is configured with a corresponding message queue for each extended service table, wherein one of the subscribers subscribes to the message queues corresponding to one or more extended service tables managed by it; Publishing the message body to the message middleware includes: The first message body is published to the message queue corresponding to the extended service table related to the first message body in the message middleware, and the second message body is published to the message queue corresponding to the extended service table related to the second message body in the message middleware.

5. The method according to claim 4, characterized in that Each of the message queues is configured with a topic; Before publishing the first message body and the second message body to the message middleware, the method further includes: configuring topics for the first message body and the second message body respectively; Publishing the first message body to the message queue corresponding to the extended business table related to the first message body in the message middleware, and publishing the second message body to the message queue corresponding to the extended business table related to the second message body in the message middleware, includes: publishing the first message body to the message queue in the message middleware with the same subject as the first message body, and publishing the second message body to the message queue in the message middleware with the same subject as the second message body.

6. The method according to any one of claims 3 to 5, characterized in that: Also includes: Monitoring the subscriber via a message retry server; When the message retry server monitors that the subscriber fails to obtain the first message body or the second message body from the message middleware, it sends a retry instruction for the message body to enable the subscriber to obtain the first message body or the second message body from the message middleware again.

7. The method according to claim 6, characterized in that Also includes: When the message retry server monitors that the number of times the subscriber fails to obtain the same first message body or second message body from the message middleware reaches a preset number threshold, the message retry server records an error log for the subscriber to obtain the failed first message body or second message body, and records the failed first message body or second message body in the error log, so as to provide the user with fields and data that are not recorded in the extended business table through the error log.

8. The method according to claim 7, characterized in that Also includes: The first message body or the second message body in the error log is resent to the message middleware or the subscriber through the message retry server, so as to re-store the first message body or the second message body in the extended service table.

9. The method according to claim 1, characterized in that The related original business tables and extended business tables are related to each other; The method further includes: upon receiving a data query request sent by a querying party, acquiring data corresponding to the data query request from the associated original service table and the extended service table, and providing the queried data to the querying party.

10. The transaction message processing method according to claim 1, characterized in that: The fields included in the transaction message are marked with a first identifier for indicating a first type of field or a second identifier for indicating a second type of field; The transaction message processing method further includes: Writing the field into the transaction interface; When it is identified that a field included in the transaction message is marked with a first identifier, determining that the field is a first-category field, and filling the field with a corresponding data processing SQL statement; When it is identified that a field included in the transaction message is marked with a second identifier, it is determined that the field is a second type field.

11. A transaction message processing device, characterized in that: It includes: parsing module, storage management module and message middleware, among which, The parsing module is configured to receive a transaction message sent by a transaction party, and parse multiple fields included in the transaction message and the data in each field; The storage management module is configured to, if a newly added second-category field with a read-only characteristic exists among the multiple fields included in the transaction message, write the newly added second-category field into the transaction interface, and based on the original second-category field with a read-only characteristic and the newly added second-category field already written into the transaction interface, publish the data corresponding to the original second-category field, the newly added second-category field, and the data of the newly added second-category field in the form of a message body to the configured message middleware, so that the message body is asynchronously stored in an extended business table in a database related to the second-category field and / or the newly added second-category field through the message middleware; The storage management module is further used to synchronously store the first category of fields and their data among the multiple fields in the original business table corresponding to the transaction message in the database through data processing SQL statements related to the first category of fields configured in the transaction interface, wherein the first category of fields are fields with rewritable characteristics.

12. A transaction message processing system, characterized in that: include: A transaction subsystem, a database storing an original business table and an extended business table, and a transaction message processing device according to claim 11, wherein: The transaction subsystem is used to send transaction messages to the transaction message processing device; The transaction message processing device is used to synchronously store the first-category fields and their data among the multiple fields in the original business table corresponding to the transaction message, and when there is a newly added second-category field with a read-only feature among the multiple fields included in the transaction message, write the newly added second-category field into the transaction interface, and based on the original second-category fields with read-only features and the newly added second-category fields already written into the transaction interface, publish the data corresponding to the original second-category fields, the newly added second-category fields and the data of the newly added second-category fields in the form of message body publishing to the configured message middleware, so that the message body is asynchronously stored in the extended business table related to the second-category fields and / or the newly added second-category fields in the database through the message middleware.

13. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 10.

14. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images