A message queue-based electronic bill transaction message distribution method and device

Abstract

The application provides a message queue-based electric bill exchange message distribution method and device, which comprises the following steps: subscribing to an outgoing message from a message sending queue and initializing a setting, wherein the setting field of the outgoing message comprises a message type, a message table ID, a delay processing time and a repeated processing number; performing system state checking according to the message type, if the checking is passed, then the next step is performed, otherwise, the current outgoing message to be sent is put back to the corresponding queue; performing transaction flow identification according to the message type, and completing message assembly and signing processing; pushing the outgoing message to a local queue through a short connection mode, and updating the state in the message table. The application divides the message channel into outgoing and incoming, and the message processing efficiency of the single channel is higher, meanwhile, the outgoing and incoming messages establish special message queues according to the message type, so that the system can efficiently distribute the messages, and realizes the automatic distribution of the messages based on the unified business scene.

Description

Technical Field

[0001] This invention relates to the field of electronic ticket message technology, and more specifically, to a method and apparatus for distributing electronic ticket messages based on message queues. Background Technology

[0002] In recent years, the construction of the bill business system has restructured the business architecture before bill discounting and reconstructed the business functions before bill discounting. While supporting the issuance of electronic bills in the traditional form, it has also enabled the issuance of bills in equal parts. Under the existing legal framework, it has realized the "change" function of bills, providing an important guarantee for bills to better serve the real economy and achieve higher-quality development.

[0003] The introduction of equal-rate bill issuance has significantly stimulated the demand for bill issuance across various business departments and boosted trading volume in the secondary market. However, it has also led to a surge in system message data volume, potentially reaching tens of thousands of TPS in extreme cases. This increasing data volume results in high-cost data processing; furthermore, in high-concurrency scenarios, message loss is frequent, requiring manual location and identification, leading to reduced system availability, long queuing times, and a poor user experience. Summary of the Invention

[0004] In view of the above problems, the present invention provides a method and apparatus for distributing electronic ticket messages based on message queues, which improves message distribution efficiency and reduces manual processing costs, while supporting on / off and retry configurations to meet various personalized customization needs.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a method for distributing electronic invoice messages based on a message queue, comprising the following steps: subscribing to outgoing messages from a message sending queue and initializing settings, wherein the settings fields of the outgoing messages include message type, message table ID, delay processing time, and number of repetitions; performing a system status check based on the message type, and if the check passes, proceeding to the next step; otherwise, returning the currently pending outgoing message to the corresponding queue; identifying the transaction process based on the message type and completing message assembly and signature processing; pushing the outgoing message to the local queue via a short connection and updating the status in the message table.

[0006] As a preferred embodiment, the method further includes: receiving incoming packets from a local queue; outputting the incoming packets to a log file and storing them in a packet log table; routing and distributing the incoming packets according to packet distribution switch parameters and packet distribution rules; performing signature verification and parsing processing on the incoming packets, storing the packets to be processed in a packet scheduling table, and placing them in a designated queue for incoming packet business logic processing; determining whether the incoming packet business logic processing is successful, and if so, deleting the corresponding packet information in the packet scheduling table; otherwise, updating the processing exception information and exception processing count in the packet scheduling table, and re-accessing the queue for queuing processing.

[0007] As a preferred embodiment, the message sending queue includes a ticket registration queue, a receipt queue, a ticket collection queue, a ticket cancellation application queue, and a common queue. Messages are assigned to different queues according to their type and traffic volume, and messages with a traffic volume of less than 50 TPS are uniformly placed in the common queue.

[0008] As a preferred embodiment, the process of completing message assembly and signing includes: obtaining the message type and message code according to the transaction components set in the transaction process document, generating a code service according to the message type and message code, and completing the assembly and signing of the message.

[0009] As a preferred option, if the message log table data fails to be saved, the incoming message will be saved as a single file to the server's abnormal message storage directory.

[0010] As a preferred embodiment, the message distribution switch parameter is msgDistributeFlag. When msgDistributeFlag = true, routing and distribution are performed according to the pre-specified message distribution rules. The configuration information of the message distribution rules includes: rule ID, rule name, business type, distribution object, distribution method, distribution count, task type, and timeout. During specific distribution, customer information is first obtained based on the original application business type to determine whether to distribute. Then, the distribution task type and the specific distribution method are determined based on the transaction type. Incoming messages that meet the rules are stored in a local distribution temporary queue.

[0011] As a preferred embodiment, the routing distribution according to the pre-specified message distribution rules includes: if the incoming message is a general forwarding message, then the receiving party customer information is obtained from different fields according to the original business application message type in the general forwarding message, and then the gray / white list customers are determined according to the receiving party customer information. If the customer is a gray list customer, the message is distributed in a gray scale; if the incoming message is a general confirmation message, general reply message, general cancellation message, or general notification message, then the original business message is queried in the message log table according to the original message identifier and message direction. If the message does not exist, the customer is determined to be a gray list customer, and the message is distributed in a gray scale; if the message is a clearing failure message, then the general confirmation message is searched in the message log table according to the original message identifier and message direction, and the original business message is searched in the message log table. If a business application message does not exist, the customer is identified as a gray-list customer and the message is distributed in a gray-scale manner. If it is a settlement result notification message, it is determined whether the settlement result notification message is a reply to a general reply message. If so, the general reply message is searched for in the message log table based on the original message identifier and message direction. If it does not exist, the customer is identified as a gray-list customer and the message is distributed in a gray-scale manner. If not, the cancellation application message, information registration confirmation message, payment reminder application message, and overdue payment reminder application message are searched for in the message log table based on the original message identifier and message direction. If they do not exist, the customer is identified as a gray-list customer and the message is distributed in a gray-scale manner. If it is a system management message or a business verification message, it is processed uniformly, without gray-scale distribution, and is directly distributed.

[0012] As a preferred solution, the incoming message is processed for signature verification and parsing, including: performing asymmetric signature verification based on the public key provided by the server, and simultaneously using Serializable for deserialization to complete message parsing.

[0013] The present invention also provides a message queue-based electronic ticket message distribution device, comprising: a subscription module for subscribing to and initializing messages from a message sending queue, wherein the message settings include message type, message table ID, delay processing time, and number of repetitions; a checking module for performing system status checks based on message type; if the check passes, proceeding to the next step; otherwise, returning the currently pending message to the corresponding queue; an assembly and signing module for identifying the transaction process based on message type and completing message assembly and signing; and a push update module for pushing the messages to the local queue via a short connection and updating the status in the message table.

[0014] As a preferred embodiment, the system further includes a receiving module for receiving incoming packets from a local queue; an output saving module for outputting the incoming packets to a log file and saving them in a packet log table; a routing and distribution module for routing and distributing the incoming packets according to packet distribution switch parameters and packet distribution rules; a logic processing module for performing signature verification and parsing processing on the incoming packets, saving the packets to be processed to a packet scheduling table, and placing them in a designated queue for incoming packet business logic processing; and a result judgment module for judging whether the incoming packet business logic processing is successful. If successful, the corresponding packet information in the packet scheduling table is deleted; otherwise, the processing error information and error processing count are updated in the packet scheduling table, and the queue is accessed again for re-queueing processing.

[0015] Compared with existing technologies, the beneficial effects of this invention include: dividing the message channel into outgoing and incoming messages, resulting in higher message processing efficiency compared to a single channel; and establishing dedicated message queues for outgoing and incoming messages based on message type, enabling the system to efficiently allocate messages and achieve unified, business-scenario-based automated message distribution. In high-concurrency scenarios, it ensures that the message queue will not experience blocking exceptions and supports re-queue processing in case of message processing errors, guaranteeing that messages are not lost. Attached Figure Description

[0016] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings, the same reference numerals are used to refer to the same parts. Wherein:

[0017] Figure 1 This is a schematic diagram of the reporting process according to an embodiment of the present invention;

[0018] Figure 2 This is a schematic diagram of the report processing flow according to an embodiment of the present invention. Detailed Implementation

[0019] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

[0020] This invention provides a method for distributing electronic ticket messages based on message queues, which is divided into outgoing message sending processing and incoming message receiving processing.

[0021] See Figure 1 The above-mentioned report sending process includes the following steps:

[0022] 1) Subscribe to outgoing messages from the message sending queue and initialize settings.

[0023] The settings fields for the reported message include message type, message table ID, delay time, and number of repetitions. See the table below:

[0024]

[0025] When sending a message, a distribution record is first inserted into the database, and the status is set to initialization. The delay processing time setting allows for customization of the message queuing time, prioritizing the sending of important messages while allowing non-business messages to be queued appropriately to ensure business processing efficiency. The retransmission count setting ensures that messages are not lost; multiple processing failures are directly converted into failed messages, requiring manual completion. Retransmission is prohibited until feedback is received.

[0026] The Electronic Bill Front-End Service (ECDP) system uses a message queue listening method to subscribe to corresponding forward and backward messages from the message sending queue of the corresponding ECDS bill system. The message sending queue includes a ticket issuance registration queue, a presentation for acceptance queue, a presentation for receipt queue, a cancellation application queue, and a common queue. Messages are assigned to different queues according to their type and transaction volume. Messages with a transaction volume of less than 50 TPS are uniformly placed in the common queue XXXX.SEND.COMM.

[0027] 2) Perform a system status check based on the message type. If the check passes, proceed to the next step. Otherwise, if the current system status does not allow the message to be sent, return the currently pending message to the corresponding queue for queuing processing. For example, the current system status includes operating status and non-operating status. The operating status allows the sending of business application messages, while the non-operating status does not.

[0028] 3) Identify the transaction process based on the message type, and complete message assembly and signature processing.

[0029] Specifically, the message assembly and signing process includes: obtaining the message type and message code according to the transaction components set in the transaction process document, generating code service according to the message type and message code, and assembling and signing the message.

[0030] For example: The client initiates a transaction request message -002; the transaction component adopts the factory pattern, first obtains the message type (transaction request) and message code (002), generates the 002ServiceImpl code service according to the message type and message code, assembles the request message and signs it; pushes the message to the local queue (ECDS.SEND.002).

[0031] 4) Push the message to the local queue via a short connection and update the status in the message table. The system will determine the IBM MQ local send queue based on the message type and place the assembled message into the corresponding queue.

[0032] See Figure 2 The above-mentioned incoming report receiving and processing process includes the following steps:

[0033] 1) Receive incoming messages from the local queue. The electronic ticket front-end service system is responsible for interfacing with IBM MQ and receiving ECDS incoming messages from local queues XXXXXXXXXX_5 and XXXXXXXXXX_6.

[0034] The settings fields for incoming messages include message type, message table ID, message identifier, original message ID, delay processing time, and message reception time. See the table below:

[0035]

[0036]

[0037] 2) Output the incoming message to the log file and save it in the message log table.

[0038] The electronic ticket pre-service system first outputs the complete message to a log file, and then saves the incoming message to the message log table MSG_MESSAGELOG. If saving the message log table data fails, the incoming message is saved as a single file in the server's error message storage directory, with the file naming format: ErrMsg_yyyyMMddHHmmssSSS.txt.

[0039] 3) Based on the message distribution switch parameters and message distribution rules, route and distribute incoming messages.

[0040] The message distribution switch parameter is msgDistributeFlag. The electronic ticket front-end service system judges the message distribution switch parameter. When msgDistributeFlag=true, it performs routing distribution according to the pre-specified message distribution rules.

[0041] The configuration information for message distribution rules includes: rule ID, rule name, business type, distribution object, distribution method, distribution frequency, task type, and timeout. During distribution, customer information is first obtained based on the original application business type to determine whether distribution is necessary. Then, the distribution task type and specific distribution method are determined based on the transaction type. Messages conforming to the rules are stored in a local temporary distribution queue. The electronic invoice front-end service system by default distributes incoming information from XXXXXXXXXX_5 to queue XXXXXXXXXX_51 and incoming information from XXXXXXXXXX_6 to queue XXXXXXXXXX_61.

[0042] In this embodiment of the invention, the message types include the following categories:

[0043] 1. General Information Classes: General Reply Message-031; General Cancellation Message-032; General Confirmation Message-033; General Forward Message-034; General Failure Reply Message-035; General Result Notification Message-036.

[0044] 2. Transaction application types: Ticket issuance registration message-002; Acceptance message-003; Receipt message-010; Cancellation application message-011; Information registration confirmation message-012; Transfer endorsement message-017; Payment application message-020; Overdue payment application message-021, etc.

[0045] 3. System Management: There are a total of 16 message types, namely 051-->067.

[0046] 4. Business verification type: There are a total of 9 types of messages, namely 071-->079.

[0047] In this embodiment of the invention, the local queue type includes the following categories:

[0048] 1. Reporting queue naming: ECDS.SEND.001 - Ticket issuance registration queue; ECDS.SEND.002 - Acceptance notification queue; ECDS.SEND.003 - Ticket receipt notification queue; ECDS.SEND.004 - Ticket cancellation application queue; ECDS.SEND.COMM - Other application queues.

[0049] 2. Incoming Report Queue Naming: ECDS.RECEIVE.031 - General Reply Queue; ECDS.RECEIVE.032 - General Cancellation Queue; ECDS.RECEIVE.033 - General Acknowledgment Queue; ECDS.RECEIVE.034 - General Forwarding Queue; ECDS.RECEIVE.COMM - Other General Queues.

[0050] In this embodiment of the invention, the local distribution temporary queue generation rule is as follows: the outgoing reporting queue is named as follows: XXXXXXXX_1 is generated incrementally, where XXXXXXXX is the bank institution code; the incoming reporting queue is named as follows: XXXXXXXX_11 corresponds to the outgoing temporary reporting queue XXXXXXXX_1, and by analogy, XXXXXXXX_21 corresponds to the outgoing temporary reporting queue XXXXXXXX_2.

[0051] This includes routing and distributing messages according to pre-specified message distribution rules, including:

[0052] If the incoming message is a general forwarding message, the acceptor customer information is obtained from different fields according to the original business application message type in the general forwarding message. Then, the gray and white list customers are determined based on the acceptor customer information. If it is a gray list customer, the message is distributed in a gray scale; if it is a white list customer, it is directly placed in the queue for distribution.

[0053] If the incoming message is a general confirmation message, a general reply message, a general cancellation message, or a general notification message, then according to the original message identifier and message direction, check whether the original business message exists in the message log table. If it does not exist, the customer is identified as a gray list customer, and then the message is distributed in a gray scale.

[0054] If the message is a clearing failure message, the general confirmation message is searched in the message log table according to the original message identifier and message direction. The original business application message is then searched in the message log table to see if it exists. If it does not exist, the customer is identified as a gray list customer and the message is distributed in a gray scale.

[0055] If it is a clearing result notification message, then determine whether the clearing result notification message is a reply to the general reply message. If so, then search the message log table for the existence of the general reply message based on the original message identifier and message direction. If it does not exist, the customer is identified as a gray-list customer, and the message is distributed in a gray-scale manner. If not, then search the message log table for the cancellation application message, information registration confirmation message, payment reminder application message, and overdue payment reminder application message. If they do not exist, the customer is identified as a gray-list customer, and the message is distributed in a gray-scale manner.

[0056] If the message is a system management message or a business verification message, it will be processed uniformly, without gray-scale testing, and directly distributed.

[0057] 4) Verify and parse incoming messages, save the messages to be processed to the message scheduling table, and place them in a designated queue for incoming business logic processing. The electronic ticket front-end service system retrieves incoming business processing messages from the designated receiving queue and obtains the corresponding business processing service according to the message type for business logic processing.

[0058] The process of verifying and parsing incoming messages includes: performing asymmetric verification based on the public key provided by the server, and using Serializable for deserialization to complete message parsing.

[0059] After message parsing is complete, ECDP first saves the messages to be processed to the message scheduling table [MSG_RECDISPATCH], and places the messages that need to be processed for business logic into the designated queue, and then hands them over to the ECDM service for incoming message business logic processing. The fields of the incoming message business processing message are: msgType (message type), msgTabId (message table ID), msgIdNo (message identifier), creDtTm (message reception time), and delayTime (delay processing time).

[0060] 5) Determine whether the incoming business logic processing was successful. If so, delete the corresponding message information in the message scheduling table [MSG_RECDISPATCH]. Otherwise, update the exception information and exception processing count in the message scheduling table and re-access the queue for queuing processing.

[0061] This invention provides a message queue-based method for distributing electronic ticket messages. When receiving an incoming message, a message queue is used for scheduling among multiple incoming message processing services. The message parsing logic is adjusted to support multi-threaded, multi-service processing, improving the message parsing and processing capabilities. First, an incoming message record is inserted into the database, with its status set to initialization. Fields include message type, message table ID, message identifier, original message ID, original message identifier, delay processing time, and message reception time. Based on the message type, the corresponding service (Service) is retrieved for specific logic processing. The service first determines whether the message needs to be queued. If not, business logic processing is performed directly. If queuing is required (because the message has an unprocessed preceding message), no business logic processing is performed; instead, the message execution message is saved as JSON data to the out-of-order queuing table. Finally, the message distribution record status is updated, modifying the status field to "processed," and the message distribution count field to the number of entries entered into the database.

[0062] The present invention also provides a message queue-based electronic ticket message distribution device, comprising:

[0063] The subscription module is used to subscribe to outgoing messages from the message sending queue and initialize settings. The settings fields for outgoing messages include message type, message table ID, delay processing time and number of repetitions.

[0064] The inspection module is used to perform system status checks based on the message type. If the check passes, the next step is performed; otherwise, the message to be sent is returned to the corresponding queue.

[0065] The assembly and signature module is used to identify the transaction process based on the message type and complete the message assembly and signature processing; the push update module is used to push the message to the local queue via a short connection and update the status in the message table.

[0066] It also includes a receiving module for receiving incoming messages from a local queue;

[0067] The output saving module is used to output future messages to a log file and save them in the message log table;

[0068] The routing and distribution module is used to route and distribute incoming packets according to packet distribution switch parameters and packet distribution rules;

[0069] The logic processing module is used to verify and parse incoming messages, save the incoming messages to be processed to the message scheduling table, and put them into a designated queue for incoming business logic processing.

[0070] The result judgment module is used to determine whether the business logic processing of the incoming report is successful. If it is, the corresponding message information is deleted from the message scheduling table. Otherwise, the processing exception information and exception processing count are updated in the message scheduling table, and the queue is accessed again for re-queue processing.

[0071] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0072] In summary, the beneficial effects of this invention include: dividing the message channel into outgoing and incoming messages, resulting in higher message processing efficiency compared to a single channel; and establishing dedicated message queues for outgoing and incoming messages based on message type, enabling the system to efficiently allocate messages and achieve unified, business-scenario-based automated message distribution. In high-concurrency scenarios, it ensures that the message queue will not experience blocking exceptions and supports re-queue processing in case of message processing errors, guaranteeing that messages are not lost.

[0073] The advantages of this invention are: (1) If the system sends a message and encounters network packet loss, the server communication is interrupted and the message is not received, the system supports retransmission; (2) It can provide feedback on error information: After the server parses the message, the system receives error feedback and displays it to the user, which facilitates problem location and handling; (3) Performance considerations: If the system sends a message and does not receive result feedback, it does not allow retransmission, but supports retry and resending.

[0074] It should be understood that if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or 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 the present invention. 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.

[0075] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. A method for distributing electronic ticket exchange messages based on a message queue, characterized in that, The steps include the following: Subscribe to outgoing messages from the message sending queue and initialize settings, wherein the settings fields of the outgoing messages include message type, message table ID, delay processing time and number of repetitions; The system status is checked according to the message type. If the check passes, the next step is performed; otherwise, the message to be sent is put back into the corresponding queue. The transaction process is identified based on the message type, and message assembly and signature processing are completed. The message is pushed to the local queue via a short connection and its status is updated in the message table. It also includes: receiving incoming messages from a local queue; outputting the incoming messages to a log file and storing them in a message log table; routing and distributing the incoming messages according to message distribution switch parameters and message distribution rules; performing signature verification and parsing on the incoming messages, saving the messages to be processed to a message scheduling table, and placing them in a designated queue for incoming message business logic processing; determining whether the incoming message business logic processing is successful, and if so, deleting the corresponding message information from the message scheduling table, otherwise updating the processing exception information and exception processing count to the message scheduling table, and re-accessing the queue for queuing processing.

2. The method for distributing electronic ticket exchange messages based on message queues according to claim 1, characterized in that, The message sending queue includes a ticket registration queue, a receipt queue, a ticket collection queue, a ticket cancellation application queue, and a public queue. Messages are assigned to different queues according to their type and traffic volume, and messages with a traffic volume of less than 50 TPS are uniformly placed in the public queue.

3. The method for distributing electronic ticket exchange messages based on message queues according to claim 1, characterized in that, The process of completing message assembly and signing includes: obtaining the message type and message code according to the transaction components set in the transaction process document, generating code service according to the message type and message code, and completing message assembly and signing.

4. The method for distributing electronic ticket exchange messages based on message queues according to claim 1, characterized in that, If the message log table data fails to be saved, the incoming message will be saved as a single file in the server's error message storage directory.

5. The method for distributing electronic ticket exchange messages based on message queues according to claim 1, characterized in that, The message distribution switch parameter is msgDistributeFlag. When msgDistributeFlag=true, routing is performed according to the pre-specified message distribution rules. The configuration information of the message distribution rule includes: rule ID, rule name, business type, distribution object, distribution method, number of distributions, task type and timeout. During the specific distribution, the customer information is first obtained according to the original application business type to determine whether to distribute. Then, the distribution task type and the specific distribution method are determined according to the transaction type. Messages that meet the rules are stored in the local distribution temporary queue.

6. The method for distributing electronic ticket exchange messages based on message queues according to claim 5, characterized in that, The routing distribution according to the pre-specified message distribution rules includes: If the incoming message is a general forwarding message, the acceptor customer information is obtained from different fields according to the original business application message type in the general forwarding message. Then, the gray and white list customers are determined according to the acceptor customer information. If it is a gray list customer, the message is distributed in gray scale. If the incoming message is a general confirmation message, a general reply message, a general cancellation message, or a general notification message, then according to the original message identifier and message direction, check whether the original business message exists in the message log table. If it does not exist, the customer is identified as a gray list customer, and then the message is distributed in a gray scale. If the message is a clearing failure message, the general confirmation message is searched in the message log table according to the original message identifier and message direction. The original business application message is then searched in the message log table to see if it exists. If it does not exist, the customer is identified as a gray list customer and the message is distributed in a gray scale. If it is a clearing result notification message, then determine whether the clearing result notification message is a reply to the general reply message. If so, then search the message log table for the existence of the general reply message based on the original message identifier and message direction. If it does not exist, the customer is identified as a gray-list customer, and the message is distributed in a gray-scale manner. If not, then search the message log table for the cancellation application message, information registration confirmation message, payment reminder application message, and overdue payment reminder application message. If they do not exist, the customer is identified as a gray-list customer, and the message is distributed in a gray-scale manner. If the message is a system management message or a business verification message, it will be processed uniformly, without gray-scale testing, and directly distributed.

7. The method for distributing electronic ticket exchange messages based on message queues according to claim 1, characterized in that, The incoming message is processed for signature verification and parsing, including: performing asymmetric signature verification based on the public key provided by the server, and using Serializable for deserialization to complete message parsing.

8. A message queue-based electronic ticket message distribution device, characterized in that, include: The subscription module is used to subscribe to outgoing messages from the message sending queue and initialize settings. The settings fields of the outgoing messages include message type, message table ID, delay processing time and number of repetitions. The inspection module is used to perform system status checks based on the message type. If the check passes, the next step is performed; otherwise, the message to be sent is returned to the corresponding queue. The assembly and signing module is used to identify the transaction process based on the message type and complete the message assembly and signing process. The push update module is used to push outgoing messages to the local queue via short connections and update the status in the message table. Also includes: The receiving module is used to receive incoming messages from the local queue; The output and storage module is used to output the incoming message to a log file and store it in the message log table; The routing and distribution module is used to route and distribute the incoming packets according to the packet distribution switch parameters and packet distribution rules; The logic processing module is used to verify and parse the incoming messages, save the incoming messages to be processed to the message scheduling table, and put them into a designated queue for incoming message business logic processing. The result judgment module is used to determine whether the incoming business logic processing is successful. If it is, the corresponding message information in the message scheduling table is deleted. Otherwise, the processing error information and the number of error processing times are updated in the message scheduling table, and the queue is accessed again for queuing processing.

Images