A method and system for handling three-state results of cross-system calls

Abstract

This invention provides a three-state processing method and system for cross-system call results. The method includes initiating a call request to the called party; upon receiving a call response from the called party, obtaining the call result; and executing the corresponding success or failure business process if the call result is successful or failed. If the call response reception times out, an inquiry request is initiated to the called party; upon receiving an inquiry response from the called party, obtaining the call result; and executing the corresponding success or failure business process if the call result is successful or failed. If the call result is unprocessed, positive compensation is performed. If no inquiry response is received after N inquiries, the call result of the call request is determined based on business preference, and the call data corresponding to the call request is stored in a database. This method is highly versatile, widely applicable, and ensures the timeliness and clarity of call result acquisition.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology, specifically relating to a method and system for processing three-state results of cross-system calls. Background Technology

[0002] In the field of computer software, cross-system calls are frequently involved. Cross-system calls interact through pre-agreed interface specifications between the two systems. See the basic process below. Figure 1 The initiator (also known as the request sender) obtains information such as the address and port of the requested party (also known as the request receiver). Following the interface specification, the initiator sends a request message to the requested party. The requested party receives and parses the request message and performs business processing. Following the interface specification, the requested party returns the processing result to the initiator via a response message. The initiator receives and parses the response message and performs subsequent processing based on the result. The response message typically has two results: success or failure. Regardless of success or failure, the result is clear, and the initiator can explicitly perform subsequent logical processing based on the result.

[0003] In actual calls, situations may arise where the caller cannot obtain a clear result (unknown result). For example: the caller sends a request message, but due to network communication issues, the called party does not receive it. The caller sends a request message, the called party receives it, but an exception occurs during processing, and the called party does not return a response message. The caller sends a request message, the called party receives it, and returns a response message after completing the business processing, but due to network communication issues, the caller does not receive the response message. These scenarios leave the caller facing an unknown result. Therefore, the caller cannot easily treat this call as successful or as a failure for subsequent processing. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a three-state processing method for cross-system call results, which determines the call results in three states: success, failure, and unknown. This method is highly versatile, has a wide range of applications, and ensures the timeliness and clarity of call result acquisition.

[0005] A method for handling three-state results of cross-system calls, comprising:

[0006] Initiate a call request to the called party;

[0007] When a call response is received from the called party, the call response is parsed to obtain the call result. If the call result is success or failure, the corresponding success business process or failure business process is executed.

[0008] When the call response timeout occurs, an inquiry request is sent to the called party.

[0009] When a query response is received from the called party, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed; when the call result is unprocessed, positive compensation is performed.

[0010] If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed.

[0011] Furthermore, the query request is used to inquire about the result of the call from the called party.

[0012] Furthermore, business inclinations are determined based on the business scenario, including optimistic and pessimistic inclinations;

[0013] The specific results of the call request, determined based on business preferences, include:

[0014] When the business scenario of the call request belongs to the optimistic trend, the call result is successful;

[0015] When the business scenario of the call request belongs to the pessimistic trend, the call result will fail.

[0016] Furthermore, the system periodically retrieves call data from the database that indicates an optimistic business trend and performs positive compensation accordingly.

[0017] Periodically retrieve call data from the database that has a pessimistic business orientation and reverse it to a positive orientation.

[0018] Furthermore, positive compensation includes:

[0019] Initiate a call request to the party being called, corresponding to the obtained call data, to perform this positive compensation;

[0020] If the result of this positive compensation call is successful, the business process will be executed successfully, and the result of updating the call data in the database will be successful. The call data will no longer be subject to positive compensation.

[0021] If the result of this positive compensation call is failure, and the reason for failure is that there is already a record with a successful call result, the successful business process will update the call data in the database to a successful call result, and the call data will no longer be subject to positive compensation.

[0022] The positive compensation fails if the call fails because a record of a failed call already exists, or if the response to the positive compensation call times out.

[0023] Furthermore, reverse positive includes:

[0024] Send a reversal request to the party being invoked to cancel the original invocation request, and perform this reverse reversal;

[0025] If the reverse reversal result is successful, the failed business process is executed, the result of the call to the database is updated to indicate failure, and the call data is no longer reversed.

[0026] If the reverse reversal result is a failure and the reason for the failure is that a record with a failed call result already exists, the failed business process is executed, the call result of the call data is updated in the database to indicate failure, and the call data is no longer reversed.

[0027] The reverse reversal fails if the reversal result is a failure, and the reason for failure is that a record with a successful call already exists, or the reverse reversal times out.

[0028] Furthermore, if the triggering of positive compensation or negative reversal reaches the threshold on the same day, the corresponding call results in the database are manually updated.

[0029] Secondly, a three-state processing system for cross-system call results includes:

[0030] The called module: used to return a call response based on the call request, and to return a query response based on the query response;

[0031] Initiator module: Used to initiate a call request to the called module; when a call response is received, the call response is parsed to obtain the call result; when the call result is success or failure, the corresponding success business process or failure business process is executed.

[0032] When the call response timeout occurs, an inquiry request is sent to the called module.

[0033] When a query response is received, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed; when the call result is unprocessed, positive compensation is performed.

[0034] If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed.

[0035] Furthermore, the business orientation of this type of business is determined by the specific business scenario, including optimistic and pessimistic orientations;

[0036] The main caller module is specifically used for:

[0037] When the business scenario of the call request belongs to the optimistic trend, the call result is successful;

[0038] When the business scenario of the call request belongs to the pessimistic trend, the call result will fail.

[0039] Furthermore, the main caller module is also used for:

[0040] Periodically retrieve call data from the database that has an optimistic business tendency, and perform positive compensation;

[0041] Periodically retrieve call data from the database that has a pessimistic business orientation and reverse it to a positive orientation.

[0042] As can be seen from the above technical solution, the cross-system call result three-state processing method and system provided by this invention determines the call result under three states: success, failure, and unknown (hereinafter referred to as three states). It proposes a general and secure method, applicable to both cases where the caller receives a clear call result and cases where the caller receives an unknown call result. This method has strong versatility and a wide range of applications. The method can obtain the call result in a timely manner through the unknown query step, ensuring the timeliness and clarity of the call result acquisition. Attached Figure Description

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0044] Figure 1 A schematic diagram of an existing invocation system provided for the background technology.

[0045] Figure 2 The flowchart shows the three-state processing method for cross-system call results provided in this embodiment.

[0046] Figure 3 The flowchart shows the positive compensation method provided in this embodiment.

[0047] Figure 4 The flowchart shows the reverse correction method provided in this embodiment. Detailed Implementation

[0048] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and are therefore merely examples and should not be used to limit the scope of protection of the present invention. It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0049] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0050] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0051] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0052] Example:

[0053] A method for handling the three states of cross-system call results, see [link / reference]. Figure 2 ,include:

[0054] Initiate a call request to the called party;

[0055] When a call response is received from the called party, the call response is parsed to obtain the call result. If the call result is success or failure, the corresponding success business process or failure business process is executed.

[0056] When the call response timeout occurs, an inquiry request is sent to the called party.

[0057] When a query response is received from the called party, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed; when the call result is unprocessed, positive compensation is performed.

[0058] If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed.

[0059] In this embodiment, the three states of cross-system call results mainly refer to the three outcomes that occur during the cross-system data call process: successful call (hereinafter referred to as success), failed call (hereinafter referred to as failure), and unknown call result (hereinafter referred to as unknown). This three-state cross-system call result processing method is primarily executed on the calling party. Table 1 summarizes the call result status, occurrence scenario, and actual result of the called party when the calling party calls the data from the called party:

[0060] Table 1

[0061]

[0062] As shown in Table 1, the initiator will receive the following three types of invocation results:

[0063] 1. The call result is Success.

[0064] If all steps in the call process proceed normally, and a clear call result of success is obtained from the response message, then the caller will execute the preset success business process for subsequent processing.

[0065] 2. The call failed.

[0066] If all steps in the call process proceed normally, and the response message clearly indicates a failure, then the caller will execute the pre-defined failure handling procedure for subsequent processing.

[0067] 3. The result of the call is "Unknown".

[0068] If any of the six scenarios C1 to C6 in Table 1 occur during the call, the caller will not receive a clear call result and will remain in an "Unknown" state. The actual result status of the called party could be any of the following: unprocessed, successful, or failed.

[0069] In this embodiment, when the caller receives a call response within a specified time, it obtains a clear call result: success or failure, and executes the corresponding business process. When the call result is an unknown situation such as timeout, the caller's call result will be in an "Unknown" state. Since network jitter, busy conditions on the called party, and temporary, occasional anomalies can all cause the caller's call result to be in an "Unknown" state, and temporary, occasional anomalies account for a relatively high proportion in practice, the caller can initiate an inquiry request to the called party to inquire about the called result and obtain the actual result from the called party. This allows the caller to obtain the call result promptly, improving the timeliness of business processing results and customer experience.

[0070] In this embodiment, when the initiator queries, since the query itself may still experience timeouts or other anomalies, the initiator can query multiple times, but a maximum of N queries are allowed, with an interval of M milliseconds between multiple queries (N and M are parameters). Typically, the number of queries should not be set too high; setting N = 2 or 3 is sufficient. If the initiator obtains a success or failure result from the called party through the query, it stops querying and executes the corresponding business process based on the obtained call result. If the actual result from the called party is "unprocessed," it is assumed that the called party did not receive the call request. Therefore, to ensure normal business processing as much as possible, a call request needs to be initiated to the called party again to conform to the original business process. Therefore, the initiator stops querying at this time and performs positive compensation. If the initiator repeatedly queries N times without obtaining a clear call result, it stops querying and determines the call result of the call request—success or failure—based on the business tendency (optimistic tendency is considered success; pessimistic tendency is considered failure), and executes the subsequent business process according to the corresponding call result. At the same time, the call data corresponding to the call request is stored in the database. The call data includes timestamp, business type, request message, address of the called party, business orientation, result status, etc.

[0071] In this embodiment, there are two business orientations: optimistic and pessimistic. The business orientation is determined based on the principle of security prudence and is determined by the specific business scenario. During the system requirements analysis or design phase, the corresponding business orientation can be determined according to each specific business scenario.

[0072] For example, in a scenario where a bank processes an ATM withdrawal, if an "Unknown" error occurs when calling the accounting system (the system being called, responsible for changing the customer's account balance), and after the aforementioned unknown query process, no clear result is obtained, the bank system (the calling party) can choose a pessimistic approach. This means the accounting system's operation to deduct the customer's balance fails, the entire transaction is treated as a failure, and a withdrawal failure message is returned to the customer's interface. The main reasons for the bank choosing a pessimistic approach in customer withdrawal scenarios are: 1. Even if the accounting system's actual deduction of the customer's balance is successful, the original balance can be restored through a reverse reversal, and the funds remain within the banking system, ensuring their safety. 2. If an optimistic approach is chosen, the accounting system's operation to deduct the customer's balance succeeds, the entire transaction is treated as a success, and a withdrawal success message is returned to the customer's interface. If the accounting system's actual deduction of the customer's balance fails (e.g., due to insufficient balance), but the customer has already taken the funds, the accounting system cannot successfully deduct the funds again (e.g., a re-deduction due to insufficient balance will also fail), and the bank will face financial risk.

[0073] For example, in the scenario of a bank accepting ATM deposits, if an "Unknown" error occurs when calling the accounting system, and after the aforementioned unknown query process, no clear result is obtained, the bank system can choose an optimistic approach. This means the accounting system successfully adds the customer's balance, the entire transaction is processed as successful, a successful deposit notification is sent to the customer's interface, and the ATM accepts the customer's cash and deposits it into its cash box. The reasons for choosing an optimistic approach in customer deposit scenarios are mainly: 1. Even if the accounting system's actual operation to add the customer's balance fails, the balance can be added again through positive compensation, and the funds remain within the banking system, ensuring their safety. 2. If a pessimistic approach is chosen, the accounting system's operation to add the customer's balance fails, the entire transaction is processed as a failure, a failed deposit notification is sent to the customer's interface, and the ATM returns the cash to the customer. If the accounting system's actual operation to add the customer's balance succeeds, although the original balance can be restored through a reverse reversal, if the customer transfers funds from the increased balance before the reversal (e.g., transferring all the funds, in which case the reverse reversal will fail), the bank will face financial risk.

[0074] In this embodiment, the method can preset business preferences under various scenarios, as shown in Table 2:

[0075] Table 2

[0076]

[0077] This method identifies three possible states for cross-system call results: success, failure, and unknown. It proposes a general and secure approach applicable to both cases where the caller receives a clear result and cases where the caller receives an unknown result. This method is highly versatile and widely applicable. The unknown query step ensures timely and clear result retrieval.

[0078] Furthermore, in some embodiments, call data with an optimistic business tendency is periodically retrieved from the database for positive compensation;

[0079] Periodically retrieve call data from the database that has a pessimistic business orientation and reverse it to a positive orientation.

[0080] In this embodiment, both forward compensation and reverse reversal are initiated using a timed triggering method. To avoid excessive delays in the unknown query stage that could negatively impact customer experience, if no actual result is obtained from the called party during the unknown query stage, the process switches to asynchronous, performing forward compensation and reverse reversal. For optimistic call data, forward compensation is performed; for pessimistic call data, reverse reversal is performed. This way, forward compensation and reverse reversal can ultimately guarantee a clear call result.

[0081] This method reduces the workload of modifying existing systems, has low invasiveness, and does not change the existing business logic of existing business systems. The forward compensation and reverse reversal processes can be treated as a global system or service, facilitating overall management, tracking, and control. Record processing is completed through a database, making it easy for operations and maintenance personnel to monitor and manually intervene.

[0082] Furthermore, in some embodiments, see Figure 3 Positive compensation includes:

[0083] Initiate a call request to the party being called, corresponding to the obtained call data, to perform this positive compensation;

[0084] If the result of this positive compensation call is successful, the business process will be executed successfully, and the result of updating the call data in the database will be successful. The call data will no longer be subject to positive compensation.

[0085] If the result of this positive compensation call is failure, and the reason for failure is that there is already a record with a successful call result, the successful business process will update the call data in the database to a successful call result, and the call data will no longer be subject to positive compensation.

[0086] The positive compensation fails if the call fails because a record of a failed call already exists, or if the response to the positive compensation call times out.

[0087] In this embodiment, positive compensation can be deployed independently in the system or service as an asynchronous processing module to record, manage, and retry unknown calls. When positive compensation is initiated, call data (including timestamp, business type, request message, address of the called party, business tendency, result status, etc.) with an unknown state and optimistic business tendency are read from the database, and the original call request is sent to the called party again.

[0088] If the positive compensation call is successful, the corresponding business data is retrieved from the call response message, updated in the business table corresponding to the business, the successful business process is executed, the corresponding call result is updated to success in the database, the call data will no longer be subject to positive compensation, and the positive compensation ends.

[0089] If the positive compensation call fails because a successful call record already exists, the positive compensation is considered successful. The corresponding business data is retrieved from the call response message and updated to the corresponding business table. The successful business process is executed, and the corresponding call result is updated to success in the database. The call data will no longer be subject to positive compensation, and the positive compensation ends.

[0090] If the current positive compensation call fails, and the reason for the failure is that a previous call failure record already exists and is being repeated, then the current positive compensation fails and ends. The serial number of the call request in the database is then changed, and the system waits for the next positive compensation.

[0091] If the result of this positive compensation call is a timeout or other unknown situation, then this positive compensation will fail and end, and we will wait for the next positive compensation.

[0092] Furthermore, in some embodiments, see Figure 4 Reverse correction includes:

[0093] Send a reversal request to the party being invoked to cancel the original invocation request, and perform this reverse reversal;

[0094] If the reverse reversal result is successful, the failed business process is executed, the result of the call to the database is updated to indicate failure, and the call data is no longer reversed.

[0095] If the reverse reversal result is a failure and the reason for the failure is that a record with a failed call result already exists, the failed business process is executed, the call result of the call data is updated in the database to indicate failure, and the call data is no longer reversed.

[0096] The reverse reversal fails if the reversal result is a failure, and the reason for failure is that a record with a successful call already exists, or the reverse reversal times out.

[0097] In this embodiment, the reverse reversal can be deployed independently in the system or service as an asynchronous processing module to record, manage, and retry unknown calls. When the reverse reversal is initiated, it reads call data with unknown status and pessimistic business tendencies from the database and sends a reversal request to the called party to cancel the original call request.

[0098] If the reverse reversal is successful, the corresponding business data is retrieved from the response message and updated to the business table corresponding to that business. If the business process fails, the corresponding call result is updated to failure in the database, and the call data is no longer reverse reversed. The reverse reversal ends.

[0099] If the result of this reverse reversal is failure, and the reason for failure is that a previous failure record already exists and is repeated, then the corresponding business data is obtained from the response message and updated to the business table corresponding to that business. The failed business process is executed, and the corresponding call result is updated to failure in the database. This call data will not be reversed again, and this reverse reversal ends.

[0100] If the result of this reverse reversal is failure, and the reason for failure is that a previous successful call record already exists and is being duplicated, then this reverse reversal fails and ends. The serial number of the reversal request in the database is changed, and the process waits for the next reverse reversal.

[0101] If the result of this reverse reversal is unknown, then this reverse reversal fails and ends, awaiting the next reverse reversal.

[0102] Furthermore, in some embodiments, if the triggering of positive compensation or reverse reversal reaches a threshold, the corresponding call result in the database is manually updated.

[0103] In this embodiment, the method also needs to determine whether the triggering of positive compensation reaches the daily threshold. The threshold can be flexibly defined, such as the maximum number of repeated attempts or time per day, or it can be defined as allowing attempts only during the day and not at night. If the triggering of positive compensation reaches the threshold, positive compensation will no longer be triggered. If there are still unknown records in the database at this point, the issue is handled manually, with the cause analyzed and targeted intervention implemented.

[0104] Similarly, this method also needs to determine whether the triggering of reverse reversal has reached the daily threshold. This threshold can be flexibly defined, such as the maximum number of repeated attempts or time limit for the day, or it can be defined as allowing attempts only during the day and not at night. If the triggering of positive compensation reaches the threshold, reverse reversal will no longer be triggered. If there are still unknown records in the database at this point, manual processing is required to analyze the cause and implement targeted interventions.

[0105] A three-state processing system for cross-system call results, comprising:

[0106] The called module: used to return a call response based on the call request, and to return a query response based on the query response;

[0107] Initiator module: Used to initiate a call request to the called module; when a call response is received, the call response is parsed to obtain the call result; when the call result is success or failure, the corresponding success business process or failure business process is executed.

[0108] When the call response timeout occurs, an inquiry request is sent to the called module.

[0109] When a query response is received, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed; when the call result is unprocessed, positive compensation is performed.

[0110] If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed.

[0111] Furthermore, in some embodiments, the query request is used to query the calling result of the called module.

[0112] Furthermore, in some embodiments, the business orientation is determined based on the business scenario, including optimistic and pessimistic orientations;

[0113] The main caller module is specifically used for:

[0114] When the business scenario of the call request belongs to the optimistic trend, the call result is successful;

[0115] When the business scenario of the call request belongs to the pessimistic trend, the call result will fail.

[0116] Furthermore, in some embodiments, the master caller module is also used for:

[0117] Periodically retrieve call data from the database that has an optimistic business tendency, and perform positive compensation;

[0118] Periodically retrieve call data from the database that has a pessimistic business orientation and reverse it to a positive orientation.

[0119] Furthermore, in some embodiments, the master caller module is specifically used for:

[0120] Send a call request corresponding to the obtained call data to the module being called to perform this positive compensation;

[0121] If the result of this positive compensation call is successful, the business process will be executed successfully, and the result of updating the call data in the database will be successful. The call data will no longer be subject to positive compensation.

[0122] If the result of this positive compensation call is failure, and the reason for failure is that there is already a record with a successful call result, the successful business process will update the call data in the database to a successful call result, and the call data will no longer be subject to positive compensation.

[0123] The positive compensation fails if the call fails because a record of a failed call already exists, or if the response to the positive compensation call times out.

[0124] Furthermore, in some embodiments,

[0125] The module for the party being rescinded is also used to: return the reversal result based on the reversal request;

[0126] The main caller module is specifically used for:

[0127] Send a reversal request to the module being called to cancel the original call request, and perform this reverse reversal;

[0128] If the reverse reversal result is successful, the failed business process is executed, the result of the call to the database is updated to indicate failure, and the call data is no longer reversed.

[0129] If the reverse reversal result is a failure and the reason for the failure is that a record with a failed call result already exists, the failed business process is executed, the call result of the call data is updated in the database to indicate failure, and the call data is no longer reversed.

[0130] The reverse reversal fails if the reversal result is a failure, and the reason for failure is that a record with a successful call already exists, or the reverse reversal times out.

[0131] Furthermore, in some embodiments, the master caller module is also used for:

[0132] If the triggering of positive compensation or negative reversal reaches the threshold on the same day, a manual intervention instruction is received, and the corresponding call result in the database is updated.

[0133] The system provided in this embodiment of the invention is described in a brief manner. For any parts not mentioned in the embodiment section, please refer to the corresponding content in the foregoing embodiment.

[0134] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A method for handling three-state results of cross-system calls, characterized in that, include: Initiate a call request to the called party; When a call response is received from the called party, the call response is parsed to obtain the call result. When the call result is success or failure, the corresponding success business process or failure business process is executed. When the call response timeout occurs, an inquiry request is sent to the called party. When a query response is received from the called party, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed. When the result of the call is unprocessed, positive compensation is performed; If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed. The business orientation is determined based on the business scenario, including optimistic and pessimistic orientations; The specific steps of determining the invocation result of the invocation request based on business preferences include: When the business scenario requested by the call belongs to the optimistic trend, the call result is successful; When the business scenario requested by the call belongs to the pessimistic trend, the call result will be failure.

2. The three-state processing method for cross-system call results according to claim 1, characterized in that, The query request is used to inquire about the result of the call from the called party.

3. The three-state processing method for cross-system call results according to claim 1, characterized in that, Periodically retrieve call data with an optimistic business tendency from the database and perform positive compensation; Periodically retrieve call data with a pessimistic business orientation from the database and reverse it.

4. The three-state processing method for cross-system call results according to claim 3, characterized in that, The positive compensation includes: Initiate a call request corresponding to the obtained call data to the party being mediated, and perform this positive compensation; If the result of this positive compensation call is successful, the successful business process is executed, and the result of updating the call data in the database is successful. The call data will no longer be subject to positive compensation. If the result of this positive compensation call is failure, and the reason for failure is that there is already a record with a successful call result, the successful business process is executed, the call result of the call data is updated to success in the database, and the call data will no longer be subject to positive compensation. The positive compensation fails if the call fails because a record of a failed call already exists, or if the response to the positive compensation call times out.

5. The three-state processing method for cross-system call results according to claim 3, characterized in that, The reverse correction includes: Send a reversal request to the party being invoked to cancel the original invocation request, and perform this reverse reversal; When the reverse reversal result is successful, the failed business process is executed, the call result of the called data is updated to failure in the database, and the called data is no longer reversed. If the reverse reversal result is a failure and the reason for the failure is that a record of a failed call already exists, the failed business process is executed, the call result of the call data is updated to a failure in the database, and the call data is no longer reversed. The reverse reversal fails if the reversal result is a failure, and the reason for failure is that a record with a successful call already exists, or the reverse reversal times out.

6. The three-state processing method for cross-system call results according to claim 4 or 5, characterized in that, If the triggering of positive compensation or negative reversal reaches the threshold on the same day, the corresponding call result in the database is manually updated.

7. A three-state processing system for cross-system call results, characterized in that, include: The called module: used to return a call response based on the call request, and to return a query response based on the query response; Initiator module: Used to send the aforementioned call request to the called module; When the call response is received, the call response is parsed to obtain the call result. When the call result is success or failure, the corresponding success business process or failure business process is executed. When the call response reception times out, the query request is sent to the called module. When the query response is received, the query response is parsed to obtain the call result, and no further queries are made; when the call result is success or failure, the corresponding success business process or failure business process is executed. When the result of the call is unprocessed, positive compensation is performed; If no response is received after N queries, the call result of the call request is determined based on the business orientation, the call data corresponding to the call request is stored in the database, and no further queries are made; if the call result is success or failure, the corresponding success business process or failure business process is executed. The business orientation is determined based on the business scenario, including optimistic and pessimistic orientations; The main caller module is specifically used for: When the business scenario requested by the call belongs to the optimistic trend, the call result is successful; When the business scenario requested by the call belongs to the pessimistic trend, the call result will be failure.

8. The three-state processing system for cross-system call results according to claim 7, characterized in that, The master caller module is also used for: Periodically retrieve call data with an optimistic business tendency from the database and perform positive compensation; Periodically retrieve call data with a pessimistic business orientation from the database and reverse it.

Images