CN117011058A

CN117011058A - Cross-system transaction method, device, equipment and storage medium

Info

Publication number: CN117011058A
Application number: CN202310996023.1A
Authority: CN
Inventors: 王梦迪; 马丽贤; 邓惠月; 刘瑞静; 叶蓉
Original assignee: Bank of China Ltd
Current assignee: Bank of China Ltd
Priority date: 2023-08-08
Filing date: 2023-08-08
Publication date: 2023-11-07

Abstract

The application provides a method, a device, equipment and a storage medium for cross-system transaction, which can be used in the financial field or other fields. The method comprises the following steps: after receiving the transaction request, the master modulator system classifies the transaction into a high risk level or a low risk level according to the transaction request; if the transaction is of a high risk level, waiting for the return confirmation message of the called party in an equal return mode, and not receiving the confirmation message returned by the called party within a preset duration range after the first message is sent, and sending a positive flushing message to the called party system in an unequal return mode; the regulated party performs the positive flushing treatment according to the positive flushing message; and the master party and the called party send the transaction records generated by the whole transaction to the reconciliation system for reconciliation. In this way, for high-risk transactions, a confirmation message processed by the called party transaction needs to be waited, so that the situation that the high-risk transactions are inconsistent in a period of time can be avoided, and the consistency of the cross-system transactions is ensured.

Description

Cross-system transaction method, device, equipment and storage medium

Technical Field

The present application relates to the financial field or other fields, and in particular, to a method, apparatus, device, and storage medium for cross-system transactions.

Background

In a distributed business scenario, the master and the called parties to a transaction are typically located on different nodes of a distributed system, and thus ensuring the consistency of the transactions of the master and the called parties is an important challenge.

In the prior art, when a master modulator transmits a transaction request to a target system, the master modulator does not continuously wait for the response of the target system and then performs other processing, but converts the transmitted transaction request into a message, puts the message into a corresponding message queue and waits for being processed, and at the moment, the master modulator can continue to perform other tasks. However, message queues may cause message loss due to network failure, system breakdown, etc., or repeated message transmission may occur, which affects data consistency.

Currently, transactions are revised by way of subsequent reconciliation, but for some important transactions, the discrepancy in the transaction data of the master and the called parties for a long period of time can have serious consequences.

Disclosure of Invention

The application provides a method, a device, equipment and a storage medium for cross-system transaction, which are used for solving the problem that transaction data of a master party and a called party are inconsistent.

In a first aspect, the present application provides a method of cross-system trading, comprising:

Acquiring a transaction request, wherein the transaction request comprises a service field and a transaction type field;

determining a transaction called party system according to the transaction type field;

determining a risk level of the transaction request according to the service field, wherein the risk level is a high risk level or a low risk level;

if the risk level of the transaction request is a high risk level, generating a first message according to the transaction request and sending the first message to the transaction called party system, wherein the first message is used for indicating the transaction called party system to conduct transaction processing;

terminating transaction processing if a confirmation message returned by the transaction called party system is not received within a preset duration range after the first message is sent, and sending a first positive flushing message to the transaction called party system, wherein the first positive flushing message comprises a transaction identifier and a positive flushing processing mode, the first positive flushing message is used for indicating the transaction called party system to correct the transaction, and the confirmation message is used for indicating whether the transaction is successful in the transaction called party system;

generating a first transaction record according to the first positive flushing message, and sending the first transaction record to a reconciliation system, wherein the first transaction record comprises all transaction states and results generated in the transaction master modulator system in the process from acquiring the transaction request to sending the first positive flushing message.

Optionally, the method further comprises:

if the confirmation message is received within the preset duration range after the first message is sent, and the confirmation message indicates that the transaction is successful in the transaction called party system, continuing to perform transaction processing according to the transaction request, and generating a transaction processing result, wherein the transaction processing result is used for indicating whether the transaction is successful in the transaction master party system;

if the transaction processing result indicates that the transaction is successful in the transaction master modulator system, generating a second transaction record, and sending the second transaction record to the reconciliation system, wherein the second transaction record comprises all transaction states and results generated in the transaction master modulator system in the process from the acquisition of the transaction request to the successful transaction;

if the transaction processing result indicates that the transaction fails in the transaction master dispatching system, a second positive flushing message is sent to the transaction dispatched system, wherein the second positive flushing message comprises a transaction identifier and a positive flushing processing mode, and the second positive flushing message is used for indicating the transaction dispatched system to correct the transaction;

and generating a third transaction record according to the second positive flushing message and sending the third transaction record to the reconciliation system, wherein the third transaction record comprises all transaction states and results generated in the transaction master modulator system in the process from acquiring the transaction request to sending the second positive flushing message.

Optionally, the method further comprises:

and stopping transaction processing if the confirmation message is received within the preset duration range after the first message is sent and the confirmation message indicates that the transaction fails in the transaction of the transaction called party system.

Optionally, the method further comprises:

and after the first message is sent, waiting for receiving the confirmation message within the preset time length range, and not carrying out transaction processing operation within the preset time length range.

Optionally, the method further comprises:

if the risk level of the transaction request is a low risk level, generating a second message according to the transaction request, wherein the second message is used for indicating the transaction called party system to conduct transaction processing;

and after the transaction processing is carried out by the transaction master modulator system and the transaction processing is successful, the second message is sent to message middleware, and the message middleware is used for forwarding the second message to the transaction modulator system.

In a second aspect, the present application provides a method for cross-system transactions, applied to a transaction called party system, the method comprising:

receiving a first message sent by a transaction master modulator system, wherein the first message is used for indicating a transaction modulated system to process a transaction, and the first message comprises a transaction identifier, transaction data and transaction time;

Carrying out transaction processing on the transaction corresponding to the transaction identifier according to the transaction data, and generating a confirmation message, wherein the confirmation message is used for indicating whether the transaction is successful in the transaction called party system;

sending the confirmation message to the transaction master modulator system;

receiving a first positive flushing message sent by the transaction master modulator system, wherein the first positive flushing message comprises a transaction identifier and a positive flushing processing mode, and the first positive flushing message is a message which is generated by the transaction master modulator system after the confirmation message is not received, and is used for indicating the transaction to be processed by the transaction modulated system after the transaction is terminated;

conducting positive punching processing on the transaction corresponding to the transaction identifier according to the positive punching processing mode, and generating a positive punching processing result;

and generating a first positive record according to the positive processing result, and sending the first positive record to a reconciliation system, wherein the first positive record comprises an identifier that the transaction is positive by the first positive message.

Optionally, the performing the positive processing on the transaction corresponding to the transaction identifier according to the positive processing manner, and generating a positive processing result, includes:

searching an original transaction according to the transaction identifier;

If the original transaction is not found, generating a result of failure of the flushing processing;

if the original transaction is found, executing the flushing operation according to the flushing processing mode, and generating a successful result of the flushing processing.

Optionally, the first positive record includes an indication that the positive success is unknown or that the positive failure is unknown.

Optionally, the method further comprises:

receiving a second positive flushing message sent by the transaction master modulator system, wherein the second positive flushing message comprises a transaction identifier and a positive flushing processing mode, and the second positive flushing message is a message which is generated when the transaction of the transaction master modulator system fails and is used for indicating the transaction modified by the transaction modulator system;

processing the transaction corresponding to the transaction identifier according to the positive flushing processing mode;

and generating a second positive record according to the second positive message, and sending the second positive record to a reconciliation system, wherein the second positive record comprises an identifier of the transaction positive by the second positive message.

Optionally, the method further comprises:

receiving a second message forwarded by a message middleware, wherein the second message is used for indicating the transaction called party system to conduct transaction processing, and the transaction called party system subscribes to a specific message queue of the message middleware in advance;

And carrying out transaction processing according to the second message.

In a third aspect, the present application provides a method of cross-system transactions, for use in a reconciliation system, the method comprising:

receiving transaction records sent by a transaction master party system and a transaction called party system, wherein the transaction records comprise all transaction states and results generated in a transaction processing process;

matching the transaction records of the transaction master party system and the transaction called party system according to serial numbers in the transaction records;

and checking the transaction states and results of the transaction records of the transaction master party system and the transaction called party system to generate a checking result.

In a fourth aspect, the present application provides an apparatus for cross-system transactions, the apparatus comprising:

the system comprises an acquisition module, a transaction module and a transaction module, wherein the acquisition module is used for acquiring a transaction request, and the transaction request comprises a business field and a transaction type field;

the processing module is used for determining a transaction called party system according to the transaction type field;

the transaction grading module is used for determining the risk grade of the transaction request according to the service field, wherein the risk grade is a high risk grade or a low risk grade;

the message center module is used for generating a first message according to the transaction request and sending the first message to the transaction called party system if the risk level of the transaction request is high, wherein the first message is used for indicating the transaction called party system to process the transaction;

The receiving module is used for terminating transaction processing if a confirmation message returned by the transaction called party system is not received within a preset duration range after the first message is sent, and sending a first positive flushing message to the transaction called party system, wherein the first positive flushing message comprises a transaction identifier and a positive flushing processing mode, the first positive flushing message is used for indicating the transaction called party system to correct the transaction, and the confirmation message is used for indicating whether the transaction is successful in the transaction called party system;

the generation module is used for generating a first transaction record according to the first positive flushing message and sending the first transaction record to the reconciliation system, wherein the first transaction record comprises all transaction states and results generated in the transaction master modulator system in the process from the acquisition of the transaction request to the sending of the first positive flushing message.

In a fifth aspect, the present application provides an apparatus for cross-system transactions, the apparatus comprising:

the system comprises a receiving module, a transaction processing module and a transaction processing module, wherein the receiving module is used for receiving a first message sent by a transaction master party system, the first message is used for indicating a transaction called party system to conduct transaction processing, and the first message comprises a transaction identifier, transaction data and transaction time;

The processing module is used for carrying out transaction processing on the transaction corresponding to the transaction identifier according to the transaction data, and generating a confirmation message which is used for indicating whether the transaction is successful in the transaction called party system;

the sending module is used for sending the confirmation message to the transaction master modulator system;

the receiving module is further configured to receive a first positive flushing message sent by the transaction master modulator system, where the first positive flushing message includes a transaction identifier and a positive flushing processing manner, and the first positive flushing message is a message generated after the transaction master modulator system does not receive the confirmation message, and terminates a transaction and is used to instruct the transaction modulated system to perform positive flushing processing on the transaction;

the positive processing module is used for carrying out positive processing on the transaction corresponding to the transaction identifier according to the positive processing mode and generating a positive processing result;

the generation module is used for generating a first positive record according to the positive processing result and sending the first positive record to the reconciliation system, wherein the first positive record comprises an identifier that the transaction is positive by the first positive message.

In a sixth aspect, the present application provides an apparatus for cross-system transactions, the apparatus comprising:

The receiving module is used for receiving transaction records sent by the transaction master party system and the transaction called party system, wherein the transaction records comprise all transaction states and results generated in the transaction processing process;

the matching module is used for matching the transaction records of the transaction master party system and the transaction called party system according to serial numbers in the transaction records;

and the checking module is used for checking the transaction states and results of the transaction records of the transaction master party system and the transaction called party system and generating checking results.

In a seventh aspect, the present application provides a server comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any one of the first to third aspects.

In an eighth aspect, the present application provides a computer-readable storage medium having stored therein computer-executable instructions for implementing the method according to any of the first to third aspects when executed by a processor.

In a ninth aspect, the present application provides a computer program product comprising a computer program for implementing the method according to any one of the first to third aspects when the computer program is executed by a processor.

The application provides a method, a device, equipment and a storage medium for cross-system transaction, wherein the method comprises the following steps: after receiving the transaction request, the master modulator system classifies the transaction into a high risk level or a low risk level according to the transaction request; if the transaction is of a high risk level, waiting for the return confirmation message of the called party in an equal return mode, and not receiving the confirmation message returned by the called party within a preset duration range after the first message is sent, and sending a positive flushing message to the called party system in an unequal return mode; the regulated party system performs positive flushing treatment according to the positive flushing message; and the master party and the called party send the transaction records generated by the whole transaction to the reconciliation system for reconciliation. In this way, for high-risk transactions, a confirmation message processed by the called party transaction needs to be waited, so that the situation that the high-risk transactions are inconsistent in a period of time can be avoided, and the consistency of the cross-system transactions is ensured.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

FIG. 1 is a schematic diagram of an application scenario of a method for cross-system transaction provided by the present application;

FIG. 2 is a flow chart of a first embodiment of a method for cross-system transactions provided by the present application;

FIG. 3 is a flow chart of a second embodiment of a method for cross-system transactions provided by the present application;

FIG. 4 is a flow chart of a third embodiment of a method for cross-system transactions provided by the present application;

FIG. 5 is a schematic diagram of a cross-system transaction device according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a second embodiment of a cross-system transaction device according to the present application;

FIG. 7 is a schematic diagram of a third embodiment of a cross-system transaction device according to the present application;

fig. 8 is a schematic structural diagram of a server according to the present application.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

It should be noted that, the user information (including, but not limited to, user transaction information, user equipment information, user personal information, etc.) and the data (including, but not limited to, data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards, and provide a corresponding operation entry for the user to select authorization or rejection.

It should be noted that the method, apparatus, device and storage medium for cross-system transaction of the present application may be used in the financial field, and may also be used in any field other than the financial field.

First, the terms related to the present application will be explained:

transaction master: a transaction master refers to a party that initiates a transaction request and invokes other systems (transaction called parties) to process the transaction. In a cross-system transaction scenario, a transaction master is typically the party initiating the transaction request, responsible for sending the transaction request and receiving the transaction response.

Transaction callee: the transaction called party refers to a system or service that receives transaction requests sent by the transaction master party and is responsible for processing these transactions. In a cross-system transaction scenario, the transaction callee is typically the party that handles the transaction request, is responsible for receiving the transaction request, handling the transaction, and returning a transaction response to the transaction host.

Positive message punching: refers to a message for revoking or correcting a transaction that has been previously performed. In financial and payment systems, correction can be made by sending a flush message if an erroneous transaction occurs or an operation prior to revocation is required. The flush message contains information about the undo transaction, which, when received, will cause the prior transaction operation to be undone.

Message Queue (MQ): refers to a middleware technology for passing messages between applications. It is a mode of asynchronous communication that can send messages into a message queue and then be retrieved from the queue and processed by other applications. The message queue has the advantages of decoupling the dependency relationship among the application programs and improving the scalability and reliability of the system.

Fig. 1 is a schematic diagram of an application scenario of a cross-system transaction method provided by the present application, as shown in fig. 1, in the application scenario of the cross-system transaction, a master party and a called party of the transaction are usually located on different system nodes, and two systems need to communicate to complete a transaction, and the transaction is processed on each side. While transaction failure or communication failure may occur on both sides, ensuring the consistency of the transactions of the master and the called parties is an important challenge.

To ensure transaction consistency, the following methods are generally adopted in the prior art:

first mode

The transaction consistency is ensured by the positive message, and when an error or abnormal condition occurs, the transaction operation before the transaction operation is timely cancelled or corrected, so that the consistency and the correctness of the data are maintained.

However, while passing positive messages can be used to ensure consistency of transactions, it has some drawbacks:

increasing the number of interactions, using a punch-through message means that multiple interactions may be required in processing the transaction. First, an original transaction request is sent and then a response from the party to whom the transaction was made is awaited. If the transaction processing fails, a flush message is sent to cancel or correct the previous transaction. Such interaction increases the number of communications between systems and may affect the response time and performance of the transaction.

Second mode

By ensuring transaction consistency through message queues and post-reconciliation, each transaction system can place transaction requests and responses in the message queues, and other systems can asynchronously consume the messages and process the messages accordingly. This reduces the number of interactions and increases the concurrent processing capacity of the system.

However, although the response speed of the transaction is improved by a message queue mode, various reasons such as network faults can cause the situation that the transaction main calling party and the called party are inconsistent, and the rollback operation can only be carried out on the transaction by a post-accounting mode.

In summary, in the cross-system transaction, if the method of flushing the message is uniformly adopted, the interaction times are increased, and the reaction speed is slow, and if the method of message queue is uniformly adopted, the situation that the transaction data of the master party and the called party are inconsistent for a long time is caused.

In view of the above problems, the inventors found in the research process in the field that, for transactions in which the system is not important, for transactions in which the consistency requirement in the time limit is not high, the processing resources are wasted by using a method of flushing messages, and the speed of processing the transactions by the system is reduced, so that for transactions in which the consistency requirement is not high in a short time, the method of adopting MQ messages does not need to wait for the response of the party to be regulated, and the processing speed of the system is improved. And for the trade with high consistency requirement in the time limit, the trade consistency needs to be ensured as much as possible, so after the trade is sent to the regulated party, the regulated party waits for processing and then carries out subsequent trade, if the trade fails, a positive flushing message is sent, and the trade consistency in the time limit can be ensured. Based on the above, the application provides a method, a device, equipment and a storage medium for cross-system transaction.

In the application, the transaction master party system, the transaction master party and the master party are all the same reference, and the transaction called party system, the called party system and the called party are all the same reference.

The following describes the technical scheme of the present application and how the technical scheme of the present application solves the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a flowchart of a first embodiment of a method for cross-system transaction according to the present application, as shown in fig. 2, including the following steps:

s101, a transaction master modulator system acquires a transaction request, wherein the transaction request comprises a service field and a transaction type field.

In the scheme, a user operates through an interface of a transaction master modulator system, fills in transaction related information such as transaction type, amount, collection account and the like, and then submits a transaction request. The transaction host caller system may provide an application programming (Application Programming Interface, simply: API) interface that allows other systems or applications to submit transaction requests through API calls. The transaction request includes a transaction field (e.g., remittance, loan, repayment, etc.), a transaction type field (e.g., deposit, purchase of a financial product, credit card consumption, etc.), a transaction identifier, a transaction related account number, a transaction time, a transaction amount, etc.

In one possible implementation, the transaction master modulator system may also obtain the transaction request through any manner of internet (Web) interface, socket (Socket) communication, message queue, and the like.

S102, determining a transaction called party system according to the transaction type field.

In one implementation, a transaction master modulator system queries a configuration table of preset mapping rules according to a transaction type field to obtain an address of a transaction modulated system, which is used to determine to which transaction modulated system the transaction request should be sent.

S103, determining the risk level of the transaction request according to the service field, wherein the risk level is a high risk level or a low risk level.

In one possible implementation manner, a risk level table with a preset mapping rule of risk levels corresponding to each service is queried according to a service field, and the risk level of the transaction request is determined.

In one possible implementation, the business fields are input into a classification model that outputs the risk level of the transaction request, which is a neural network model that is trained beforehand through labeled business fields.

Optionally, all transactions involving the outflow of money from the transaction master call system are pre-set to a high risk level, and all transactions involving no inflow of money are pre-set to a low risk level.

And S104, if the risk level of the transaction request is a high risk level, generating a first message according to the transaction request, and sending the first message to a transaction called party system.

In this step, a first message in a preset format is generated according to the information in the transaction request, where the first message includes detailed information of the transaction, such as a transaction identifier, a transaction type, transaction data, account information, and the like, and is used to instruct the transaction called party system to perform transaction processing. The preset format may be defined according to specific service requirements and technical options, which are not limited herein.

Specifically, the transaction master call system uses a remote procedure call (Remote Producer Call, abbreviated as RPC) or hypertext transfer protocol (Hypertext Transfer Protocol, abbreviated as HTTP) to send the first message to the called party in a synchronous manner under the equal return mode.

Optionally, the transaction master modulator system waits for the response of the modulator after sending the message, and does not continue the subsequent processing until the response is received.

It should be noted that, when the first message is sent, the master modulator system has not completed the transaction processing yet.

Correspondingly, a first message sent by a transaction master modulator system is received.

S105, the transaction called party system carries out transaction processing on the transaction corresponding to the transaction identification according to the transaction data, and generates a confirmation message which is used for indicating whether the transaction is successful in the transaction called party system.

In this step, the transaction identifier is typically a unique identifier for identifying each transaction, and the called party system first identifies the corresponding transaction based on the transaction identifier. The called party system executes corresponding transaction processing logic according to the transaction data, and the specific transaction processing logic is different according to the transaction type and the service requirement. Illustratively, for a payoff transaction, the transferee system updates the loan account balance and the transaction status.

After the transaction is completed, the called party system generates a confirmation message according to the transaction result. The confirmation message may include the result of the transaction process, such as the success or failure of the transaction, and may include other relevant information, such as a transaction time stamp, error code, etc.

S106, sending the confirmation message to the transaction master modulator system.

Optionally, after the confirmation message is sent to the transaction master modulator system, a transaction record of the modulator is generated according to the result of transaction processing, wherein the transaction record comprises a transaction identifier, a transaction state and a result and is sent to the reconciliation system.

And S107, if the transaction master modulator system does not receive the confirmation message returned by the transaction slave modulator system within the preset time range after the first message is sent, ending the transaction processing.

In this step, after the transaction master party system sends the message, it continuously detects whether the confirmation message of the called party is received, if the confirmation message is not received within the preset time range because the service speed of the called party system is slow or the network reason in the process of sending the confirmation message is caused, the transaction master party considers that the transaction of the called party fails, the subsequent processing of the transaction in the master party is terminated, and the transaction fails.

Optionally, the host sends a message of transaction failure to the terminal device used by the user.

S108, generating a first positive flushing message and sending the first positive flushing message to the transaction called party system.

The first positive flushing message comprises a transaction identifier and a positive flushing processing mode and is used for indicating the transaction called party system to correct the transaction.

In this step, the master party does not terminate the transaction, the transaction fails, and the party to be transferred has two conditions of successful transaction or failed transaction, so that the transaction of the party to be transferred needs to be corrected in order to prevent the inconsistent transaction of the master party and the party to be transferred. The master party system generates a first transaction message including a transaction identifier for uniquely identifying the transaction and a transaction correction processing mode for indicating what transaction correction mode the transaction party system should take to correct the transaction.

In one implementation, the first positive message is sent by way of an MQ queue without waiting for the result of the first positive message.

In another possible implementation, the master modulator waits for the response message returned by the first positive flushing message to be processed by the modulator.

S109, the transaction master modulator system generates a first transaction record according to the first positive flushing message and sends the first transaction record to the reconciliation system.

Wherein the first transaction record includes all transaction states and results generated at the transaction master system from the time the transaction request is acquired to the time the first transaction confirmation message is sent.

In this step, in order to ensure consistency of the transaction, after the transaction abnormality occurs and the transaction confirmation message is sent, a transaction record needs to be generated, and the user confirms the transaction by checking accounts later.

It should be noted that, after sending the positive flushing message, the master modulator does not need to wait for the return message of the positive flushing message to continue processing other transactions.

S110, conducting the positive punching processing on the transaction corresponding to the transaction identifier according to the positive punching processing mode, and generating a positive punching processing result.

In the step, in the transaction called party system, a corresponding original transaction record is found according to the transaction identifier according to the received first positive flushing message. And carrying out corresponding flushing processing according to the flushing processing mode appointed in the first flushing message, and correcting errors or anomalies occurring before.

If the corresponding transaction record is found, and the alignment is successful, generating an alignment processing success result; if the called party does not complete the transaction and cannot find the corresponding transaction, the positive punching fails, and a positive punching processing failure result is generated.

S111, generating a first positive punching record according to the positive punching processing result, and sending the first positive punching record to a reconciliation system.

The first positive record comprises an identification of the transaction being positively processed by the first positive message, and comprises a positive processing result of which the positive success is not known or the positive failure is not known.

S112, receiving transaction records sent by the transaction master party system and the transaction called party system, wherein the transaction records comprise all transaction states and results generated in the transaction processing process.

In this step, the accounting system receives all transaction records sent by the transaction master party system and the transaction called party system in a transaction process, wherein the transaction records also comprise transaction records including transaction identifications, transaction times, transaction states and transaction results.

S113, matching the transaction records of the transaction master party system and the transaction called party system according to the serial numbers in the transaction records.

In this step, the accounting system matches the transaction records at a preset time of day according to the serial numbers or other identifications in the transaction records. Through matching of serial numbers, corresponding transaction records of the main party and the called party can be associated.

S114, checking the transaction states and results of the transaction records of the transaction master party system and the transaction called party system to generate a checking result.

In the step, the matched transaction records are checked, and the purpose of the check is to ensure that the transaction states and results of the transaction master party system and the transaction called party system are consistent. And comparing the transaction states and results of the master party and the called party, and checking whether inconsistent conditions exist. If the transaction record states and the results of the two sides are completely consistent, the check results are consistent. If the state or result of a transaction in the system of the master and the called parties is not consistent, further investigation and processing are carried out according to actual conditions, and manual intervention or other operations can be involved to achieve consistency of transaction records.

The embodiment provides a method for cross-system transaction, wherein a main modulator system classifies transactions into high risk level or low risk level after receiving transaction requests; if the transaction is of a high risk level, waiting for the return confirmation message of the called party in an equal return mode, and not receiving the confirmation message returned by the called party within a preset duration range after the first message is sent, and sending a positive flushing message to the called party system in an unequal return mode; the regulated party performs the positive flushing treatment according to the positive flushing message; and the master party and the called party send the transaction records generated by the whole transaction to the reconciliation system for reconciliation. In this way, for high-risk transactions, a confirmation message processed by the called party transaction needs to be waited, so that the situation that the high-risk transactions are inconsistent in a period of time can be avoided, and the consistency of the cross-system transactions is ensured.

The first embodiment is a scenario in which the transaction is classified as a high risk transaction and the master party does not receive the acknowledgement message returned by the called party, and the following describes in detail, with an embodiment, the processing scheme in the scenario in which the master party receives the acknowledgement message.

Fig. 3 is a flow chart of a second embodiment of a method for cross-system transaction provided by the present application, as shown in fig. 3, including the following steps:

s201, receiving a confirmation message within a preset duration range.

In this step, a preset time range is set in the transaction master-side system, and the transaction slave-side system waits for a confirmation message to be returned in the time range. The preset duration can be set according to system requirements and service conditions, and is usually a reasonable time window, so that the confirmation message can be timely received.

S202, judging whether the transaction processing of the called party system is successful or not according to the confirmation message.

After receiving the confirmation message, the transaction master modulator system judges whether the transaction processing of the transaction slave modulator system is successful according to the processing result information contained in the confirmation message. The acknowledgement message may include a processing result field, typically indicating whether the transaction was successful or failed.

If the confirmation message indicates that the transaction fails in the transaction called party system, step S203 is executed;

If the confirmation message indicates that the transaction is successful in the transaction called party system, step S204 is executed;

s203, stopping transaction processing.

If the confirmation message indicates that the transaction fails in the transaction by the transaction partner system, the transaction master system will cease to proceed with the transaction processing. This means that the transaction called party system cannot successfully process the transaction, and the master party system records detailed information of the transaction failure, including failure reasons, failure time, transaction information, etc., and sends the transaction record to the reconciliation system.

S204, continuing to conduct transaction processing according to the transaction request, and generating a transaction processing result.

In this step, if the confirmation message indicates that the transaction is successful in the transaction called party system, the transaction master party system will continue to perform subsequent transaction processing according to the specific situation and service logic of the transaction, execute the corresponding transaction processing step, and generate a transaction processing result, where the transaction processing result is used to indicate whether the transaction is successful in the transaction master party system.

If the transaction processing result indicates that the transaction is successful in the transaction master modulator system, step S205 is executed.

If the transaction processing result indicates that the transaction fails in the transaction master modulator system, step S206 is executed.

S205, generating a second transaction record and sending the second transaction record to the reconciliation system.

Wherein the second transaction record includes all transaction states and results generated at the transaction master modulator system from the time of acquiring the transaction request to the time of successful transaction.

S206, sending a second positive flushing message to the transaction called party system.

In the step, the master party fails to conduct subsequent transactions, and a second positive flushing message is generated to ensure that the transactions of the called party system are consistent with the master party, wherein the second positive flushing message comprises a transaction identifier and a positive flushing processing mode and is used for indicating the transaction of the called party system to conduct correction processing on the transactions.

S207, generating a third transaction record according to the second positive flushing message and sending the third transaction record to the reconciliation system.

In this step, the master transaction fails, and a third transaction record is generated, including all transaction states and results generated at the transaction master system from the time the transaction request was acquired to the time the second transaction message was sent.

S208, receiving a second positive flushing message sent by the transaction master modulator system.

The second positive flushing message comprises a transaction identifier and a positive flushing processing mode, and is a message which is generated when the transaction of the transaction master party system fails and is used for indicating the transaction called party system to correct the transaction.

S209, processing the transaction corresponding to the transaction identifier according to the positive flushing processing mode.

S210, generating a second positive record according to the second positive message, and sending the second positive record to the reconciliation system.

Wherein the second positive record includes an indication that the transaction was positively processed by the second positive message.

The embodiment provides a cross-system transaction method, wherein transactions are classified into transactions with high risk levels, and a master modulator can continue to process the transactions after receiving a confirmation message; uploading the transaction record to the account checking system after the transaction is successfully processed; and when the transaction processing fails, sending a positive flushing message to the regulated party. The called party performs the positive flushing processing based on the positive flushing message, and uploads the positive flushing processing record to the account checking system. By the method, when the master modulator processes high-risk transactions, problems can be solved, and the transaction consistency of the master modulator and the modulated party can be ensured through the positive flushing message.

In the first and second embodiments described above, the transaction is classified as a high risk transaction, and a processing scheme in which the transaction is classified as a low risk transaction will be described in detail below in one embodiment.

Fig. 4 is a flow chart of a third embodiment of a method for cross-system transaction provided by the present application, as shown in fig. 4, including the following steps:

S301, generating a second message according to the transaction request, wherein the format of the second message accords with the format of the MQ queue.

In this step, the second message includes information such as a transaction processing result, a transaction state, a transaction processing manner, a transaction identifier, etc., so that the party to be tuned can obtain the latest state of the transaction in time. The second message may be in a structured data format, such as a lightweight data interchange format (JavaScript Object Notation, abbreviated as JSON) or extensible markup language (eXtensible Markup Language, abbreviated as XML) for ease of parsing and processing. The specific format and content of the message is determined by the actual business requirements and system design.

S302, after the transaction processing is carried out by the transaction master modulator system and the transaction processing is successful, the second message is sent to the message middleware.

In this step, the low risk transaction is set to the synchronization attribute, i.e. a second message indicating the processing of the party being tuned is sent out at the point in time when the master party system transaction is completed. At the time of processing of the low risk transaction, the second message is sent to the MQ message queue of the message middleware.

It should be noted that MQ messages are used to implement the publishing and subscribing of messages. In a system of MQ message middleware, a publisher (sender) of a message sends the message to a particular topic or topic queue, and a subscriber (receiver) of the message can subscribe to this topic or topic queue to receive all messages under the topic.

Optionally, after sending the second message, a transaction record is generated, the transaction record including all transaction states and results of the transaction, and sent to the reconciliation system.

And S303, the message middleware receives the second message and forwards the second message to the transaction called party system.

In this step, the message middleware, as a transfer station for the message, receives a second message sent by the transaction master modulator system. The message middleware then forwards the message to the transaction called party system that previously reserved the particular message queue.

S304, the transaction called party system receives the second message forwarded by the message middleware.

In this step, the transaction callee system receives a second message forwarded by the message middleware from a particular message queue to which the message middleware subscribes.

S305, the transaction called party system carries out transaction processing according to the second message.

Optionally, the transaction called party system generates a transaction record according to the transaction processing result and sends the transaction record to the reconciliation system.

The embodiment provides a method for cross-system transaction, when the transaction is classified as low-risk transaction, a synchronization attribute is set, and after the transaction of a main party is successful, a second message indicating the transaction processing of the party to be transferred is sent to the party to be transferred through an MQ queue. The system can be decoupled in an MQ mode, interfaces are not required to be directly called by both sides, and the low-risk transaction does not need to wait for a confirmation message returned by a called party to directly carry out other transactions, so that the concurrency processing capability of the system is improved.

The following describes the solution of the present application in detail with a few specific examples.

Example one

Suppose that the transaction master modulator system is an e-commerce platform and the transaction slave modulator system is a payment system. The user performs a shopping transaction on the e-commerce platform, and needs to perform payment operation.

Step 1, the e-commerce platform acquires a transaction request, wherein the transaction request comprises shopping commodity information and the transaction type is shopping payment.

And 2, determining a transaction called party system according to the transaction type field, wherein the transaction called party system is determined to be a payment system.

And step 3, determining the risk level of the transaction request according to the shopping commodity information and the like.

In this example, the commodity price is greater than a preset value, here set to a high risk.

And 4, converting the transaction request into a message by adopting a return mode and sending the message to a payment system through an API (application program interface) because the transaction is a high-risk transaction.

And step 5, the payment system receives the message and starts to carry out payment processing.

And 6, the payment system performs payment operation according to the shopping commodity information and the balance of the user account, and generates a confirmation message to indicate whether the payment process is successful or not.

And 7, the payment system sends a confirmation message back to the e-commerce platform to indicate the payment processing result.

And 8, receiving a confirmation message of the payment system by the e-commerce platform within a preset duration range.

And 9, judging whether the transaction processing of the payment system is successful or not according to the confirmation message.

Step 10, if the confirmation message indicates that the payment system transaction fails, the e-commerce platform stops subsequent transaction processing.

And step 11, if the confirmation message indicates that the payment system transaction is successful, the e-commerce platform continues to process the subsequent transaction according to the shopping request.

And step 12, the e-commerce platform updates the shopping order state and the inventory information of the user according to the shopping commodity information.

And 13, generating a transaction processing result by the e-commerce platform, wherein the transaction processing result represents that the shopping transaction is successfully processed in the e-commerce platform system.

And step 14, the e-commerce platform sends the transaction processing result to the reconciliation system.

And 15, receiving a transaction processing result by the account checking system and recording the processing state of the shopping transaction.

In this example, the e-commerce platform acts as a transaction master modulator system, sending a shopping transaction request to the payment system as a transaction modulated system. And the payment system performs payment processing and returns a payment result to the e-commerce platform through a confirmation message. And the E-commerce platform judges the processing result of the payment system according to the confirmation message, if the processing result is successful, the E-commerce platform continues to carry out subsequent processing according to the transaction request, and generates a transaction processing result. Finally, the transaction processing result is sent to a reconciliation system for recording and reconciling the status of the shopping transaction. Therefore, the consistency of transaction processing results of the e-commerce platform and the payment system can be ensured, and the correctness and consistency of the transaction are ensured.

Example two

Assume a scenario where a user pays back, where the loan system is the master and the credit system is the slave.

Step 1, a user repayment transaction occurs in a loan system, and the loan system receives a user repayment request, wherein the user repayment request comprises transaction request information such as user ID, repayment amount and the like.

And 2, judging that the transaction is a low-risk transaction according to the repayment field of the transaction type by the loan system, and then generating a first message and converting the first message into a message conforming to the MQ queue format.

And 3, the loan system performs user repayment processing in the system of the loan system, so that transaction processing is ensured to be completed.

And 4, in the last step of processing the transaction by the transaction master, the loan system generates a processing message and sets the processing message to be in an unequal return mode. The processing message may include information such as the final result of the transaction, the transaction number, etc.

Optionally, the loan system generates a transaction record and sends the transaction record to the reconciliation system.

And 5, the loan system sends the processing information to the MQ queue and sends the information to the transaction called party (the credit system).

And 6, subscribing the specific theme for receiving the user repayment message in the MQ in advance by the credit system.

And 7, the credit system receives the processing information forwarded in the MQ, judges the final result of the user repayment according to the information content, carries out the user repayment processing according to the user ID, the repayment amount and other information in the processing information, and confirms that the transaction is successful.

Optionally, the credit system generates a transaction record and sends the transaction record to the reconciliation system.

By way of this example, user payouts interact as low risk transactions using MQ messages. The loan system is used as a master modulator, the user repayment request is converted into MQ information and is sent to the credit system as a modulated party, the credit system processes the information after receiving the information, and confirmation information is returned to the loan system through the MQ information, so that the consistency and reliability of the transaction are ensured. The way enables the loan system and the quota system to be decoupled and to be in asynchronous communication, and improves the concurrency processing capacity and flexibility of the system.

Fig. 5 is a schematic structural diagram of an embodiment one of a device for cross-system transaction provided by the present application, as shown in fig. 5, the device 400 includes:

an obtaining module 411, configured to obtain a transaction request, where the transaction request includes a service field and a transaction type field;

a processing module 412, configured to determine a transaction called party system according to the transaction type field;

a transaction ranking module 413, configured to determine a risk level of the transaction request according to the service field, where the risk level is a high risk level or a low risk level;

the message center module 414 is configured to generate a first message according to the transaction request and send the first message to the transaction called party system, where the first message is used to instruct the transaction called party system to perform transaction processing if the risk level of the transaction request is a high risk level;

A receiving module 415, configured to terminate transaction processing if a confirmation message returned by the transaction called party system is not received within a preset duration range after the first message is sent, and send a first positive flushing message to the transaction called party system, where the first positive flushing message includes a transaction identifier and a positive flushing processing manner, the first positive flushing message is used to instruct the transaction called party system to perform correction processing on a transaction, and the confirmation message is used to instruct whether the transaction is successful in the transaction called party system;

a generating module 416, configured to generate a first transaction record according to the first positive flushing message, and send the first transaction record to a reconciliation system, where the first transaction record includes all transaction states and results generated at the transaction master modulator system from the process of obtaining the transaction request to sending the first positive flushing message.

Optionally, the processing module 412 is further configured to:

The device for cross-system transaction provided in this embodiment is used for executing the method for cross-system transaction described on the transaction master side in any of the above method embodiments, and its implementation principle and technical effects are similar, and will not be described here again.

Fig. 6 is a schematic structural diagram of a second embodiment of a device for cross-system transaction according to the present application, as shown in fig. 6, the device includes:

a receiving module 511, configured to receive a first message sent by a transaction master modulator system, where the first message is used to instruct a transaction slave system to perform transaction processing, and the first message includes a transaction identifier, transaction data, and transaction time;

A processing module 512, configured to perform transaction processing on a transaction corresponding to the transaction identifier according to the transaction data, and generate a confirmation message, where the confirmation message is used to indicate whether the transaction is successful in the transaction called party system;

a sending module 513, configured to send the confirmation message to the transaction master modulator system;

the receiving module 511 is further configured to receive a first positive message sent by the transaction master modulator system, where the first positive message includes a transaction identifier and a positive processing manner, and the first positive message is a message generated by the transaction master modulator system after the confirmation message is not received, and after the transaction is terminated, the message is used to instruct the transaction slave modulator system to perform positive processing on a transaction;

the positive processing module 514 is configured to perform positive processing on the transaction corresponding to the transaction identifier according to the positive processing manner, and generate a positive processing result;

and a generating module 515, configured to generate a first positive record according to the positive processing result, and send the first positive record to the reconciliation system, where the first positive record includes an identifier that the transaction is positive by the first positive message.

Optionally, the positive punching processing module 514 is specifically configured to:

Searching an original transaction according to the transaction identifier;

Optionally, the receiving module 511 is further configured to receive a second positive flushing message sent by the transaction master modulator system, where the second positive flushing message includes a transaction identifier and a positive flushing processing manner, and the second positive flushing message is a message generated when the transaction of the transaction master modulator system fails and used to instruct the transaction callee system to perform correction processing on a transaction;

optionally, the positive processing module 514 is further configured to process the transaction corresponding to the transaction identifier according to the positive processing manner.

Optionally, the generating module 515 is further configured to generate a second positive record according to the second positive message, and send the second positive record to the reconciliation system, where the second positive record includes an identifier that the transaction is positive by the second positive message.

Optionally, the receiving module 511 is further configured to receive a second message forwarded by the message middleware, where the second message is used to instruct the transaction called party system to perform transaction processing, and the transaction called party system subscribes to a specific message queue of the message middleware in advance.

Optionally, the processing module 512 is further configured to perform transaction processing according to the second message.

The device for cross-system transaction provided in this embodiment is used for executing the method for cross-system transaction described on the side of the party to be transacted in any of the above method embodiments, and its implementation principle and technical effects are similar, and will not be described here again.

Fig. 7 is a schematic structural diagram of a third embodiment of a device for cross-system transaction according to the present application, as shown in fig. 7, where the device includes:

a receiving module 611, configured to receive transaction records sent by the transaction master party system and the transaction slave party system, where the transaction records include all transaction states and results generated in a transaction processing process;

a matching module 612, configured to match the transaction records of the transaction master party system and the transaction called party system according to serial numbers in transaction records;

a checking module 613, configured to check the transaction states and results of the transaction records of the transaction master modulator system and the transaction slave modulator system, and generate a checking result.

The device for cross-system transaction provided in this embodiment is used for executing the method for cross-system transaction described in the reconciliation system side in any of the above method embodiments, and its implementation principle and technical effects are similar, and will not be described here again.

Fig. 8 is a schematic structural diagram of a server according to the present application, as shown in fig. 8, the server 700 includes:

a processor 711, a memory 712 communicatively coupled to the processor, and a communication interface 713 for interacting with other devices;

the memory 712 stores computer-executable instructions;

the processor 711 executes the computer-executable instructions stored in the memory to implement the method of cross-system transactions described in any of the method embodiments described above.

Alternatively, the above-mentioned devices of the server 700 may be connected through a system bus.

The memory 712 may be a separate memory unit or may be a memory unit integrated into the processor 711. The number of processors 711 is one or more.

It is to be appreciated that the processor 511 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

The system bus may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The system bus may be classified into an address bus, a data bus, a control bus, and the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus. The memory may include random access memory (random access memory, RAM) and may also include non-volatile memory (NVM), such as at least one disk memory.

All or part of the steps for implementing the method embodiments described above may be performed by hardware associated with program instructions. The foregoing program may be stored in a readable memory. The program, when executed, performs steps including the method embodiments described above; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid state disk, magnetic tape, floppy disk, optical disk (optical disc), and any combination thereof.

The server provided by the embodiment of the present application is used for implementing the method for cross-system transaction described in any one of the foregoing method embodiments, and the implementation principle and technical effects are similar, and are not described herein.

The application also provides a computer readable storage medium having stored therein computer executable instructions which when executed by a processor are for implementing a method of cross-system transactions as in any of the preceding method embodiments.

It will be appreciated that the memory in embodiments of the application may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and direct memory bus RAM (DR RAM). It should be noted that the above-referenced memories are intended to comprise, without being limited to, these and any other suitable types of memories.

Embodiments of the present application also provide a computer program product comprising a computer program stored in a computer readable storage medium, from which at least one processor can read the computer program, the at least one processor executing the computer program implementing a method of cross-system transactions according to any of the preceding method embodiments.

Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It is to be understood that the application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method of cross-system trading, for use with a trading master system, the method comprising:

2. The method according to claim 1, wherein the method further comprises:

3. The method according to claim 1, wherein the method further comprises:

4. A method according to any one of claims 1 to 3, further comprising:

5. The method according to claim 1, wherein the method further comprises:

6. A method of cross-system trading, for use with a trading callee system, the method comprising:

sending the confirmation message to the transaction master modulator system;

7. The method of claim 6, wherein the performing the positive processing on the transaction corresponding to the transaction identifier according to the positive processing manner, and generating a positive processing result, includes:

searching an original transaction according to the transaction identifier;

8. The method of claim 6 or 7, wherein the first punch record includes an indication that punch success is unknown or punch failure is unknown.

9. The method of claim 6, wherein the method further comprises:

10. The method of claim 6, wherein the method further comprises:

and carrying out transaction processing according to the second message.

11. A method of cross-system transactions, for use in a reconciliation system, the method comprising:

12. An apparatus for cross-system transactions, the apparatus comprising:

13. An apparatus for cross-system transactions, the apparatus comprising:

14. An apparatus for cross-system transactions, the apparatus comprising:

15. A server, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

The processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1 to 11.

16. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1 to 11.