Distributed transaction design method, apparatus, and storage medium based on heterogeneous systems

Abstract

This invention discloses a distributed transaction design method based on heterogeneous systems, relating to the field of communication technology. The method includes: an upstream system generating a new business document and notifying a downstream system; the downstream system receiving the notification from the upstream system, and according to its own load capacity, asynchronously retrieving the document data and performing corresponding business processing, checking whether the processing was successful; if the processing is successful, notifying the upstream system of successful synchronization; if the processing fails, notifying the upstream system of synchronization failure. This invention also provides a distributed transaction design device and storage medium based on heterogeneous systems. This invention adopts a "push-pull combination" approach, where the upstream system pushes a message, the downstream system pulls the data, and then confirms the data. This revolutionary improvement over simply pulling data or simply pushing messages enhances system stability and ensures the timeliness of business transmission.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a distributed transaction design method, apparatus, and storage medium based on heterogeneous systems. Background Technology

[0002] In production and daily life, most systems provide services and exchange data to meet various customer needs, especially ERP systems, where cross-system business data exchange is frequent. However, during the interaction of business documents, factors such as unstable network or server operating environments can cause important documents to fail to synchronize in a timely and effective manner. When document information is lost during its downward transmission, the current mainstream solutions are either for the upstream system to develop an interface for the downstream system to retrieve it, or for the upstream system to push messages to the downstream system, with success considered upon message arrival. These two methods can be simply described as a "pull" approach and a "push" approach.

[0003] However, both of these methods have certain drawbacks in business data exchange, affecting the timeliness and stability of business transmission, and ultimately impacting the user's product experience. These drawbacks are mainly manifested in the following aspects:

[0004] 1. When upstream systems directly expose their interfaces, such as Taobao and JD.com, downstream systems can only periodically poll to search for business data, which leads to a large number of invalid requests.

[0005] 2. Downstream systems open interfaces and directly push messages to upstream systems, such as Koubei and Meituan. The upstream system only guarantees that the message will be notified to the downstream system, but cannot guarantee that the entire business will be smooth.

[0006] 3. When upstream and downstream systems send document notifications, they only provide document numbers and do not include log tracking markers, making it impossible to accurately record each error.

[0007] 4. Business execution logs: Business personnel can only query logs related to documents from a massive amount of logs and then perform analysis, which affects the timeliness of business transmission. Summary of the Invention

[0008] The present invention provides a distributed transaction design method, apparatus and storage medium based on heterogeneous systems, which aims to solve the problems existing in the above-mentioned background art.

[0009] To achieve the above-mentioned technical objectives, the present invention mainly adopts the following technical solutions:

[0010] A distributed transaction design method based on heterogeneous systems, the method comprising:

[0011] The upstream system generates new business documents and notifies the downstream system.

[0012] The downstream system receives the notification from the upstream system, and according to its own load capacity, it asynchronously retrieves the document data, performs the corresponding business processing, and checks whether the processing is successful.

[0013] If the detection and processing are successful, the upstream system will be notified of successful synchronization; if the detection and processing fail, the upstream system will be notified of failed synchronization.

[0014] In this invention, the step of the upstream system generating a new business document and notifying the downstream system includes:

[0015] After the upstream system generates a new business document, the business document data is placed in the unnotified area of ​​the upstream business data pool.

[0016] A notification is sent from the unnotified area of ​​the upstream business data pool to the downstream system, indicating the existence of a new document, and the success of the transmission is checked.

[0017] If the detection notification is sent successfully, the document is placed in the cache queue for downstream systems to retrieve data; if the detection notification fails to be sent, it is retried a preset number of times, and if it still fails, it is placed in the synchronization error queue.

[0018] Furthermore, if a notification is successfully sent, the document is moved from an unnotified state to a notified state in the upstream business data pool; if a notification fails to send, the document is moved from an unnotified state to a notification failure state in the upstream business data pool.

[0019] Furthermore, when the downstream system detects the business processing received from the upstream system, if the detection process fails, it will still retry a certain number of times. If it still fails after the preset number of retries, it will notify the upstream system of the synchronization failure.

[0020] Furthermore, for notifications of successful detection and processing, the document's status is changed from "notified" to "confirmed successful" in the upstream business data pool; for notifications of failed detection and processing, the document's status is changed from "notified" to "confirmed failed" in the upstream business data pool.

[0021] In this invention, the upstream system also periodically scans the cache queue of failed document synchronization. If there are any unsynchronized documents, it will automatically notify the relevant management personnel to handle the problem. After the problem is successfully resolved, the business documents will be resent to the downstream system through the backend system.

[0022] The present invention also provides a distributed transaction design device based on heterogeneous systems, the distributed transaction design device based on heterogeneous systems comprising:

[0023] Upstream system: The upstream system includes a message pusher, a message receiver, a timer, and an upstream business data pool;

[0024] The message pusher pushes the newly generated business documents to the downstream system;

[0025] The message receiver receives a notification from the downstream system regarding whether the detection result of the business processing was successfully sent.

[0026] The timer is used to periodically scan the cache queue of documents that have failed to synchronize.

[0027] The business data processing pool collects and processes data information from the message pusher, message receiver, and timer, modifies the notification status of business documents within the business data processing pool, and can re-feed back unsynchronized document information successfully processed by relevant personnel to the message pusher.

[0028] Downstream system: The downstream system includes a message receiver, a message receipt unit, and a service processor;

[0029] The message receiver receives business document data information pushed from the upstream system;

[0030] The message receipt is used to send a notification to the message receiver of the upstream system, indicating whether the detection result of the business processing in the downstream system has been successfully sent.

[0031] The business processor is used to process business document data received by the message receiver of the downstream system and send the detection results of the business processing to the message receipt.

[0032] Furthermore, the upstream system also includes system monitoring, which is an interactive platform used by administrators to process confirmed failed business documents and perform retry operations.

[0033] Furthermore, the upstream system and the downstream system also include a log collector, which collects information tracking tags generated by the upstream system or the downstream system when pushing messages.

[0034] Furthermore, to achieve the above objectives, the present invention also provides a storage medium storing a distributed transaction design program based on a heterogeneous system, wherein when the distributed transaction design program based on a heterogeneous system is executed by a processor, it implements the steps of the distributed transaction design method based on a heterogeneous system as described above.

[0035] Compared with the prior art, the present invention has the following beneficial effects:

[0036] (1) The present invention adopts a "push-pull combination" approach in which the upstream system pushes messages first, the downstream system pulls data, and then confirms the data. This approach revolutionizes the simple data pulling and simple message pushing methods and enhances the stability of the system.

[0037] (2) By setting up a log collector, the upstream system will generate a log tag when it sends a notification. This tag can be used as a log retrieval index in the upstream system. The downstream system will also record logs based on this log retrieval string and collect and store them on the log collector. This ensures that every communication between the upstream and downstream systems has a trace that runs through the entire process. Relevant personnel can easily and quickly find the logs based on the background management system and perform analysis, ensuring the timeliness of business transmission. Attached Figure Description

[0038] Figure 1 This is a flowchart of a distributed transaction design method based on heterogeneous systems according to the present invention.

[0039] Figure 2 The flowchart of the upstream system of this invention generates new business documents and notifies the downstream system.

[0040] Figure 3 This is a flowchart of the downstream system of the present invention when detecting the service processing received from the upstream system.

[0041] Figure 4 This is a flowchart illustrating the operation of the timer in this invention;

[0042] Figure 5 This is a schematic diagram of the structure of a distributed transaction design device based on heterogeneous systems according to the present invention. Detailed Implementation

[0043] The technical solution of the present invention will be further explained and described below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present invention and are not intended to limit the present invention.

[0044] like Figure 5 As shown, Figure 5 This is a schematic diagram of a distributed transaction design device based on heterogeneous systems according to the present invention.

[0045] One of the distributed transaction design devices based on heterogeneous systems includes:

[0046] Upstream system: The upstream system includes a message pusher, a message receiver, a timer, and an upstream business data pool;

[0047] The upstream system is mainly used to connect to the backend server, communicate data with the backend server, and connect the data information of the backend server to the downstream system for data communication.

[0048] The message pusher pushes the newly generated business documents to the downstream system;

[0049] The message receiver receives a notification from the downstream system regarding whether the detection result of the business processing was successfully sent.

[0050] The timer is used to periodically scan the cache queue of failed document synchronizations; such as Figure 4 As shown, it is mainly responsible for scanning the data in the notification failure and confirmation failure areas of the business data pool to determine whether there are any documents that have failed to synchronize. If not, the scan ends; if so, the relevant management personnel are notified, and the cause of the error is checked through system monitoring to troubleshoot the problem and reissue the document.

[0051] The business data processing pool collects and processes data information from the message pusher, message receiver, and timer. The business data processing pool is divided into five areas: no notification, notification, notification failure, confirmation success, and confirmation failure. These areas are used to store business documents in different states, modify the notification status of business documents in the business data processing pool, and can re-feed back unsynchronized document information that has been successfully processed by relevant personnel to the message pusher.

[0052] Downstream system: The downstream system includes a message receiver, a message receipt unit, and a service processor;

[0053] The message receiver receives business document data information pushed from the upstream system;

[0054] The message receipt is used to send a notification to the message receiver of the upstream system, indicating whether the detection result of the business processing in the downstream system has been successfully sent.

[0055] The business processor is used to process business document data received by the message receiver of the downstream system and send the detection results of the business processing to the message receipt.

[0056] Furthermore, the upstream system also includes system monitoring, which is an interactive platform used by administrators to process confirmed failed business documents and perform retry operations.

[0057] Furthermore, the upstream system and the downstream system also include a log collector, which collects information tracking tags generated by the upstream system or the downstream system when pushing messages.

[0058] Because every time a message is pushed, the upstream system generates an information tracking tag. Both upstream and downstream systems use this tracking tag for logging. When an error occurs, this tag is recorded along with the document on the log collector, so every synchronization and every error is traceable.

[0059] Specifically, when an upstream system issues a notification, it generates a log tag, which can be used as a log retrieval index within the upstream system. The downstream system also records logs based on this log retrieval string and collects and stores them on the log collector, ensuring that every communication between the upstream and downstream systems has a traceable link. Relevant personnel can easily and quickly find the logs through the backend management system for analysis, ensuring the timeliness of business transmission.

[0060] In addition, to achieve the above objectives, the present invention also provides a storage medium storing a distributed transaction design program based on a heterogeneous system, wherein when the distributed transaction design program based on a heterogeneous system is executed by a processor, it implements the steps of the distributed transaction design method based on a heterogeneous system as described above.

[0061] The design method based on the above-mentioned distributed transaction design device for heterogeneous systems is as follows: Figures 1-3 As shown.

[0062] in, Figure 1 This is a flowchart of a distributed transaction design method based on heterogeneous systems according to the present invention.

[0063] The diagram discloses the distributed transaction design method based on heterogeneous systems, including:

[0064] S1: The upstream system generates a new business document and notifies the downstream system;

[0065] This step is as follows Figure 2 As shown, it includes:

[0066] After the upstream system generates a new business document, the business document data is placed in the unnotified area of ​​the upstream business data pool.

[0067] A notification is sent from the unnotified area of ​​the upstream business data pool to the downstream system, indicating the existence of a new document, and the success of the transmission is checked.

[0068] If the detection notification is sent successfully, the document is placed in the cache queue for downstream systems to retrieve data; if the detection notification fails to be sent, it is retried a preset number of times, and if it still fails, it is placed in the synchronization error queue.

[0069] Furthermore, if a notification is successfully sent, the document is moved from an unnotified state to a notified state in the upstream business data pool; if a notification fails to send, the document is moved from an unnotified state to a notification failure state in the upstream business data pool.

[0070] S2: The downstream system receives the notification from the upstream system, and according to its own load capacity, pulls asynchronous document data, performs corresponding business processing, and checks whether the processing is successful.

[0071] S3: If the detection and processing is successful, notify the upstream system that the synchronization was successful; if the detection and processing fails, notify the upstream system that the synchronization failed.

[0072] Specifically, when a downstream system checks a business process received from an upstream system, if the check fails, it will retry a certain number of times. If the process still fails after a preset number of retries, the downstream system will notify the upstream system of the failure. Furthermore, for successful checks, the upstream business data pool will change the document's status from "notified" to "confirmed success"; for failed checks, the upstream business data pool will change the document's status from "notified" to "confirmed failure".

[0073] In this invention, the upstream system also periodically scans the cache queue of failed document synchronizations using a timer. If there are any unsynchronized documents, it will automatically notify the relevant management personnel to handle the problem. After the problem is successfully resolved, the business documents will be resent to the downstream system through the backend system.

[0074] This invention adopts a "push-pull combination" approach, where the upstream system pushes messages first, the downstream system pulls data, and then confirms the data. This approach represents a revolutionary improvement over simply pulling data or simply pushing messages, and enhances the stability of the system.

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

[0076] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which can be a fixed terminal, such as an Internet of Things smart device, including smart air conditioners, smart lights, smart power supplies, smart routers and other smart home devices; or a mobile terminal, including smartphones, wearable networked AR / VR devices, smart speakers, autonomous vehicles and many other networked devices) to execute the methods described in the various embodiments of the present invention.

[0078] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A distributed transaction design method based on heterogeneous systems, characterized in that, The distributed transaction design method based on heterogeneous systems includes: The upstream system generates new business documents and notifies the downstream system. The downstream system receives the notification from the upstream system, and according to its own load capacity, pulls asynchronous document data, performs corresponding business processing, and checks whether the processing is successful. If the detection and processing are successful, notify the upstream system that the synchronization was successful; if the detection and processing fail, notify the upstream system that the synchronization failed. The steps of the upstream system generating a new business document and notifying the downstream system include: After the upstream system generates a new business document, the business document data is placed in the unnotified area of ​​the upstream business data pool. A notification is sent from the unnotified area of ​​the upstream business data pool to the downstream system, indicating the existence of a new document, and the success of the transmission is checked. If the detection notification is sent successfully, the document is placed in the cache queue for downstream systems to retrieve data; if the detection notification fails to be sent, it is retried a preset number of times, and if it still fails, it is placed in the synchronization error queue. The upstream system also periodically scans the cache queue of failed document synchronization. If there are any unsynchronized documents, it will automatically notify the relevant management personnel to handle the problem. After the problem is successfully resolved, the business documents will be resent to the downstream system through the backend system.

2. The distributed transaction design method based on heterogeneous systems according to claim 1, characterized in that: Upon successful detection of the notification, the document is moved from an unnotified state to a notified state in the upstream business data pool. If a notification fails to be sent, the document will be moved from the "notified" state to the "notified failed" state in the upstream business data pool.

3. The distributed transaction design method based on heterogeneous systems according to claim 2, characterized in that, When a downstream system detects a service received from an upstream system, if the detection fails, it will retry a certain number of times. If the retry still fails after reaching a preset number of times, it will notify the upstream system of the synchronization failure.

4. The distributed transaction design method based on heterogeneous systems according to claim 3, characterized in that: Upon successful detection and processing, the document is moved from the "notified" status to the "confirmed success" status in the upstream business data pool. When a notification of a failed detection process is received, the document's status is changed from "notified" to "confirmed failure" in the upstream business data pool.

5. A distributed transaction design device based on heterogeneous systems, characterized in that: The distributed transaction design device based on heterogeneous systems includes: Upstream system: The upstream system includes a message pusher, a message receiver, a timer, and an upstream business data pool; The message pusher will push the generated new business documents to the downstream system; The message receiver receives a notification from the downstream system regarding whether the detection result of the business processing was successfully sent. The timer is used to periodically scan the cache queue of documents that have failed to synchronize. The upstream business data pool collects and processes data information from the message pusher, message receiver, and timer, modifies the notification status of business documents in the upstream business data pool, and can re-feed back unsynchronized document information that has been successfully processed by relevant personnel to the message pusher. Downstream system: The downstream system includes a message receiver, a message receipt unit, and a service processor; The message receiver receives business document data information pushed from the upstream system; The message receipt is used to send a notification to the message receiver of the upstream system, indicating whether the detection result of the business processing in the downstream system has been successfully sent. The business processor is used to process business document data received by the message receiver of the downstream system and send the detection results of the business processing to the message receipt.

6. The distributed transaction design device based on heterogeneous systems according to claim 5, characterized in that: The upstream system also includes system monitoring, which is an interactive platform used by administrators to process confirmed failed business documents and perform retry operations.

7. The distributed transaction design device based on heterogeneous systems according to claim 5, characterized in that: The upstream system and the downstream system also include a log collector, which collects information tracking tags generated when the upstream system or the downstream system pushes messages.

8. A storage medium, characterized in that: The storage medium stores a distributed transaction design program based on heterogeneous systems. When the distributed transaction design program based on heterogeneous systems is executed by the processor, it implements the steps of the distributed transaction design method based on heterogeneous systems as described in any one of claims 1-4.

Images