System exception handling method, device, computer equipment and storage medium

Abstract

The embodiment of the present invention discloses a system exception processing method, device, computer equipment and storage medium. The method comprises: obtaining business exception data sent by at least one business processing system, the business exception data comprises business interface exception data and business call exception data, the business call exception data is obtained by checking the log data associated with the business call chain, and when the log data meets the inconsistency condition; according to the business exception data, determining the retry processing information, and sending it to the business processing system matching the business exception data, so as to instruct the matching business processing system to perform the business retry operation according to the retry processing information. The embodiment of the present invention can capture the anomalies of business data and improve the accuracy of business processing in the business system.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of data processing, and in particular to a system exception processing method, device, computer equipment and storage medium. Background Art

[0002] In recent years, the use of microservice distributed architecture in business systems for business processing can reduce the coupling between different businesses and improve business processing efficiency.

[0003] For example, in the loan assistance industry, a user's loan order process includes: transaction, risk control review, risk control credit, financing, capital access, funding party review, funding party credit, clearing and settlement, and insurance, etc. For each exception, each business system captures its own internal exceptions, retry exceptions, and compensates for abnormal storage asynchronous events (JOB).

[0004] At present, the existing exception capture function can only capture exceptions within each business system. If there is an exception in the communication between business systems, for example, an order is lost, the exception at the data level cannot be captured through the exception capture within the business system. Currently, it relies on the T+1 offline manual reconciliation method to detect inconsistent data between business data, resulting in long exception processing time and low accuracy. Summary of the invention

[0005] The embodiments of the present invention provide a system exception processing method, device, computer equipment and storage medium, which can capture the exception of business data and improve the accuracy of business processing in the business system.

[0006] In a first aspect, an embodiment of the present invention provides a system exception handling method, which is applied in an exception handling system, and includes:

[0007] Acquire business exception data sent by at least one business processing system, wherein the business exception data includes business interface exception data and business call exception data, wherein the business call exception data is obtained by checking log data associated with a business call chain and when the log data meets an inconsistency condition;

[0008] Retry processing information is determined according to the service exception data, and sent to a service processing system matching the service exception data, so as to instruct the matching service processing system to perform a service retry operation according to the retry processing information.

[0009] In a second aspect, an embodiment of the present invention provides a system exception handling method, which is applied in an audit system, including:

[0010] Obtain log data from at least two business processing systems associated with the business call chain;

[0011] Querying and verifying the processing data associated with the business call chain from the log data in each of the business processing systems;

[0012] When at least two target processing data meet the inconsistency condition, business call exception data is generated according to each target processing data and sent to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information.

[0013] In a third aspect, an embodiment of the present invention further provides a system exception handling device, which is configured in an exception handling system and includes:

[0014] A business exception data collection module, used to obtain business exception data sent by at least one business processing system, wherein the business exception data includes business interface exception data and business call exception data, and the business call exception data is obtained by checking the log data associated with the business call chain and when the log data meets the inconsistency condition;

[0015] The exception processing module is used to determine retry processing information according to the business exception data, and send it to a business processing system matching the business exception data to instruct the matching business processing system to perform a business retry operation according to the retry processing information.

[0016] In a fourth aspect, an embodiment of the present invention further provides a system exception handling device, which is configured in an audit system and includes:

[0017] A log data acquisition module, used to acquire log data from at least two business processing systems associated with a business call chain;

[0018] A business data checking module, used to query and check the processing data associated with the business call chain from the log data in each of the business processing systems;

[0019] A call chain exception data sending module is used to generate business call exception data according to each target processing data when at least two target processing data meet the inconsistency condition, and send it to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information.

[0020] In a fifth aspect, an embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, a system exception handling method as described in any one of the embodiments of the present invention is implemented.

[0021] In a sixth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a system exception handling method as described in any one of the embodiments of the present invention.

[0022] The embodiment of the present invention can uniformly collect the business exception data of each business processing system by collecting the business exception data sent by the business processing system. The business exception data includes the business interface exception data of each business processing system, and obtains the business call exception data existing in each business processing system in the business call chain. According to the business exception data, retry processing information is determined to instruct the business processing system with the exception to retry the business, thereby solving the problem in the prior art that the exceptions caused by the communication between the business processing systems cannot be processed. The exceptions occurring in the data in the business call chain can be counted and processed, and the exceptions existing in the business call chain can be captured in real time, thereby improving the accuracy of the exception processing of the business system and improving the accuracy of business processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a flow chart of a method for handling system exceptions in Embodiment 1 of the present invention;

[0024] Figure 2a is a flow chart of a method for handling system exceptions in Embodiment 2 of the present invention;

[0025] Figure 2b is a schematic diagram of an application scenario applicable to an embodiment of the present invention;

[0026] Figure 3 It is a structural schematic diagram of a system exception handling device in Embodiment 3 of the present invention;

[0027] Figure 4 It is a structural schematic diagram of a system exception handling device in Embodiment 4 of the present invention;

[0028] Figure 5 It is a structural diagram of a computer device in Embodiment 5 of the present invention. DETAILED DESCRIPTION

[0029] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0030] Embodiment 1

[0031] Figure 1This is a schematic diagram of a flowchart of a system exception handling method in the first embodiment of the present invention. This embodiment can be applied to the case where an exception occurs in a business processing system with a call relationship and is captured and processed in the exception handling system. The method can be executed by the system exception handling device provided in the embodiment of the present invention. The device can be implemented in software and / or hardware, and can generally be integrated into a computer device, specifically a server. Figure 1 As shown, the method of this embodiment specifically includes:

[0032] S110, obtaining business exception data sent by at least one business processing system, wherein the business exception data includes business interface exception data and business call exception data, and the business call exception data is obtained by checking log data associated with the business call chain and when the log data meets an inconsistency condition.

[0033] The business system includes at least one business processing system, which is used to provide financial services to users. The structure of the business system can be distributed microservices, and a business processing system can be used as a microservice. Each business processing system is used to work together to process the business. There is a calling relationship between business processing systems. The business call chain is used to describe the calling path of the business processing system associated with the process from receiving a business request to responding. A business request can refer to a request initiated by a user through a client.

[0034] Business exception data is used to determine the business processing system where the abnormal event occurred. The abnormal event may include the abnormal event that occurred in the business processing system itself, and / or the abnormal event sent by the data layer processed by the business processing system. Business exception data may include business interface exception data and business call exception data.

[0035] Among them, the business interface exception data is used to determine the abnormal events that occur in the business processing system itself, which may specifically refer to the call exception events that occur when the business processing system calls the interface. Exemplarily, the call exception events may include call interface errors, interface call timeouts, network timeouts and other events.

[0036] Business call exception data is used to determine events such as business data loss in the business call chain, or errors in business data processing results in the business call chain. Generally, business call exception data may refer to abnormal events that occur in the business processing system in terms of data processing. Specifically, the log data stored in the business processing system associated with the entire business call chain can be obtained and checked to determine which business processing system has a problem with the data in the processing link. The inconsistency condition is used to determine whether the corresponding processing data of each business processing system recorded in the log data in the business call chain is consistent. If inconsistent, it means that in the business call chain, the value or format of the processing data corresponding to the business processing system is incorrect, or the processing data is lost, etc.

[0037] By checking the log data associated with the business call chain, the business call exception data can obtain the log data stored in the business processing system associated with the business call chain. The log data usually records the processing operations and processing data associated with the business processing system. If the log data in one or several business processing systems does not store the processing operations and processing data that match the business call chain, it is determined that the processing data corresponding to the business call chain is lost during the communication process between the business processing systems. At this time, the stored processing data can be reprocessed according to the processing operations in the business processing system where the processing operations and processing data that match the business call chain exist, and the processed data is transmitted to the next adjacent business processing system in the business call chain for processing, thereby completing the business call chain, realizing compensation processing for processing data loss events, and improving the fault tolerance and stability of the entire business system. If the format of the processed data stored in the log data in one or several business processing systems or the value of the processed data is wrong, it is determined that an error has occurred in the execution result of the processing operation of the processed data corresponding to the business call chain in the business processing system. The input data can be reprocessed in the business processing system and the processed data can be transmitted to the next adjacent business processing system in the business call chain for processing, thereby achieving compensation processing for events of numerical or format errors in the processed data and improving the fault tolerance and stability of the entire business system.

[0038] Optionally, obtaining business exception data sent by at least one business processing system includes: obtaining business exception data sent by at least one business processing system from a message queue, and the business processing system includes at least one of the following: an audit system, a transaction system, a risk control system, an access system, and a clearing and settlement system.

[0039] The business system is a lending business system, which may include an audit system, a transaction system, a risk control system, an access system, and a clearing and settlement system, etc. It should be noted that the business system is a third-party system that provides services to lenders and borrowers.

[0040] The audit system is used to review the various processing data of the transaction business in the business call chain. The transaction system is used to receive the loan request from the borrower and form a transaction order. The risk control system is used to conduct risk control assessment on the accounts involved in the business request. The access system is used to obtain the account that provides funds and determine the target funding account that provides funds to the borrower. The clearing and settlement system is used to calculate the amount that the two parties to the transaction (borrower and funding party) should receive or pay at set intervals, and to transfer funds to the two parties to the transaction based on the calculated amount at the agreed time.

[0041] In addition, the lending business system may also include other systems, such as a funding party review system and / or a financing system, and each system may be divided, for example, the risk control system may include a risk control review module and a risk control credit module, etc.; the funding party review system may include a funding party review module and a funding party credit module, etc. In this regard, configuration may be performed according to actual conditions, and the embodiments of the present invention do not impose specific limitations.

[0042] A message queue is a container that stores messages during their transmission. The message queue is used to transmit data between the business processing system and the exception handling system. Specifically, the business processing system sends business exception data to the message queue for storage. The exception handling system obtains business exception data from the message queue.

[0043] Data is transmitted between the exception handling systems of the business processing system through message queues, which improves the reliability of data transmission, as well as the response speed and stability of each system, thereby improving the reliability and stability of business exception handling.

[0044] S120, determining retry processing information according to the service exception data, and sending the retry processing information to a service processing system matching the service exception data, so as to instruct the matching service processing system to perform a service retry operation according to the retry processing information.

[0045] The retry processing information is used to determine the compensation operation of the business processing system for the business exception data, specifically to instruct the business processing system to perform a business retry operation on the business exception data. Among them, the business retry operation may refer to the operation of the business processing system to retry the business associated with the business exception data. Exemplarily, the processing result of the upstream business processing system is lost when it is sent to the downstream business processing system, and the upstream business processing system can re-execute the business retry operation of sending the processing result to the downstream business processing system. For another example, the calculation result of the business processing system performing the calculation for the request sent by the upstream business processing system is wrong, and the business retry operation of re-executing the calculation on the request can be performed. In addition, there are other situations, which are not specifically limited by the embodiments of the present invention.

[0046] Optionally, the business exception data includes business call exception data; determining retry processing information based on the business exception data, and sending it to a business processing system that matches the business exception data to instruct the matching business processing system to perform a business retry operation based on the retry processing information, including: extracting a system identifier, a business call chain identifier and a first exception type from the business call exception data; generating retry processing information based on the business call chain identifier and the first exception type; and sending the retry processing information to a business processing system that matches the system identifier to instruct the matching business processing system to reprocess the business data matched by the business call chain identifier in accordance with a processing method that matches the first exception type.

[0047] The business call exception data is used to determine whether the business call chain is complete and whether the transmission data in the business call chain is consistent. The system identifier is used to identify the business processing system, for example, the business processing system domain name or the Internet Protocol (IP) address of the business processing system. The business call chain identifier is used to distinguish from other business call chains. The first exception type is used to determine the type of business call exception data to distinguish the abnormal events that occurred in the business call chain.

[0048] There are multiple business call chains in the business processing system. The business call chain is actually the call relationship between the business systems in the process of processing a business request initiated by a certain account. Identification information can be configured for each business call chain to identify each business call chain. The business call chain identifier can be an identification code (Identity, ID) assigned to the business call chain. The first exception type can include a business data loss type and / or a business processing error type, etc.

[0049] In addition, the service call abnormal data may also include account identification, time, and service request identification information associated with the service call chain, etc. The specific setting may be based on actual conditions, and the embodiment of the present invention does not impose any specific limitation on this.

[0050] Retry processing information can be determined based on the extracted data, and the retry processing information is used to instruct the business processing system to perform retry processing. The retry processing information may include the business that needs to be retried, the time, and the call function associated with the retry processing.

[0051] The business processing system that matches the system identifier indicates that the business processing system needs to be retried. It can be a business processing system with a processing exception, or it can be an upstream business processing system with data loss. The retry processing information is sent to the business processing system that matches the system identifier, instructing the matching business system to reprocess the data associated with the business call chain, and transfer the output data flow to the downstream business processing system in the business call chain, so that the business call chain is correct and the requests in the business call chain respond normally. Among them, the processing method can be determined according to the first exception type. Exemplarily, when the first exception type is data loss, the business processing system resends the data associated with the business call chain to the downstream business processing system; when the first exception type is data calculation error, the business processing system recalculates the pre-calculation data associated with the business call chain, and sends the calculated data to the downstream business processing system.

[0052] By extracting the system identifier, the business call chain identifier and the first exception type from the business call exception data, instructing the business processing system that matches the system identifier to reprocess the business data that matches the business call chain identifier in accordance with the processing method that matches the first exception type, the business processing system can be accurately notified to handle the exception accordingly, solve the exception problem, and improve the stability and fault tolerance of the business system.

[0053] Optionally, the business exception data includes business interface exception data; determining retry processing information based on the business exception data, and sending it to a business processing system matching the business exception data, includes: extracting a system identifier, an interface identifier and a second exception type from the business interface exception data; determining retry processing parameters based on the second exception type and a preset correspondence between the second exception type and the retry processing parameters, the retry processing parameters including a retry frequency parameter; determining the interface identifier and the retry processing parameters as retry processing information; and sending the retry processing information to a business processing system matching the system identifier to instruct the matching business processing system to re-call the interface matching the interface identifier in accordance with the processing method matching the retry processing parameters.

[0054] The business interface abnormality data is used to determine the abnormal events that occurred in the business processing system itself. The business interface abnormality data may specifically refer to data associated with the abnormal call event that occurred when the business processing system called the interface. Among them, the interface identifier is used to identify the interface where the abnormality occurred. The second abnormality type may include at least one of the call interface error type, the interface call timeout type, and the network timeout type.

[0055] The retry processing parameter is used to determine the retry processing method. The retry frequency parameter is used to determine the frequency of the retry processing. Exemplarily, the retry frequency parameter can be to retry three times for each abnormal event, or to retry once within a set time period (such as 2ms). Among them, if the number of retries is exceeded, an alarm report can be generated and provided to the management user, who will handle it manually. Specifically, the retry processing parameters can be determined according to the second abnormal type. Usually, different second abnormal types can correspond to different severities of abnormal events. The correspondence between the second abnormal type and the retry processing parameters can be pre-configured, and the retry processing parameters can be determined according to the determined abnormal type. In addition, the retry processing parameters can also include the duration of the retry processing, etc., and this embodiment of the present invention does not impose specific restrictions.

[0056] Since the service abnormality data is service interface abnormality data, the service processing system can compensate for the interface abnormality event by re-calling the interface. Specifically, the service processing system is notified of the interface that needs to be re-called and the interface is re-called according to the frequency of the retry frequency parameter.

[0057] By extracting the system identifier, interface identifier and the second exception type from the business call exception data, instructing the business processing system that matches the system identifier, and re-calling the interface that matches the interface identifier according to the retry processing parameters that match the second exception type, the business processing system can be accurately notified to perform corresponding processing on the exception, solve the exception problem, and improve the stability and fault tolerance of the business system.

[0058] The embodiment of the present invention can uniformly collect the business exception data of each business processing system by collecting the business exception data sent by the business processing system. The business exception data includes the business interface exception data of each business processing system, and obtains the business call exception data existing in each business processing system in the business call chain. According to the business exception data, retry processing information is determined to instruct the business processing system with the exception to retry the business, thereby solving the problem in the prior art that the exceptions caused by the communication between the business processing systems cannot be processed. The exceptions occurring in the data in the business call chain can be counted and processed, and the exceptions existing in the business call chain can be captured in real time, thereby improving the accuracy of the exception processing of the business system and improving the accuracy of business processing.

[0059] Embodiment 2

[0060] Figure 2aThis is a schematic diagram of a flowchart of a system exception handling method in the second embodiment of the present invention. This embodiment can be applied to the case where an exception occurs in a business processing system with a call relationship in an audit system and is captured and handled. The method can be executed by the system exception handling device provided in the embodiment of the present invention. The device can be implemented in software and / or hardware, and can generally be integrated into a computer device, specifically a server. Figure 2a As shown, the method of this embodiment specifically includes:

[0061] S210: Obtain log data from at least two business processing systems associated with the business call chain.

[0062] For a non-exhaustive description of the embodiments of the present invention, reference may be made to the aforementioned embodiments.

[0063] The business processing system records the data and processing operations associated with the business call chain in the log. The log includes data associated with multiple business call chains, and the log data associated with the business call chain can be queried from the log according to the identifier of the business call chain. By collecting the log data associated with the business call chain provided by each business processing system, the log data matching the business call chain can be counted.

[0064] S220, querying and verifying the processing data associated with the business call chain from the log data in each of the business processing systems.

[0065] In fact, the log data should store the processing data and processing operations of each business processing system in the business call chain. By querying and verifying the processing data, you can check whether the data transmitted between the upstream and downstream business processing data is correctly transmitted, and detect whether each business processing data is processed correctly as a processing result. It should be noted that the log data of a business processing system can include multiple processing data.

[0066] For example, the audit system can obtain log data by monitoring binlog and perform real-time verification. According to the pre-configured data verification rules, the exception is reported. For example, if the data transmitted between the upstream and downstream business processing systems is inconsistent within 5 minutes, the exception code matching the event is reported, and the exception code is used to determine the exception type.

[0067] In a specific example, the upstream business processing system is system A, and the downstream business processing system is system B. The input data of system A is a, and the processing result is b, which is used as output data. The input data of system B is b, and the processing result is c, which is used as output data. If the collected log data does not contain system B receiving input data b, it indicates that system A did not correctly transmit the processing result b to system B, for example, the network was disconnected and the processing result b was lost. If the collected log data shows that system B received input data b and the processing result of input data b is c, it indicates that the calculation operation associated with the processing operation of system B is wrong.

[0068] S230, when at least two target processing data meet the inconsistency condition, generate business call exception data according to each target processing data, and send it to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information.

[0069] At least two processing data satisfying the inconsistency condition are used as target processing data. The inconsistency condition is used to determine whether the processing data corresponding to the business processing system associated with the business call chain is consistent, specifically, to determine whether the output data of the upstream business processing system is consistent with the input data of the downstream business processing system, and / or to determine whether the calculation result obtained after the calculation of the data before calculation in the business processing system is consistent with the processing result.

[0070] It should be noted that if there is no log data associated with the business call chain in the downstream business processing system, the processing data associated with the business call chain in the log data of the downstream business processing system is empty.

[0071] Optionally, when at least two target processing data meet the inconsistency condition, business call exception data is generated according to each target processing data, including: if it is determined that the processing data associated with two business processing systems in a calling relationship do not match, then the processing data associated with the two business processing systems in the calling relationship are used as the target processing data, and the two business processing systems in the calling relationship include an upstream business processing system and a downstream business processing system; if the target processing data associated with the upstream business processing system is different from the target processing data associated with the downstream business processing system, then the business call exception data is generated according to the system identifier of the upstream business processing system, the business call chain identifier of the business call chain and the business data loss type.

[0072] Two business processing systems in a calling relationship may mean that one business processing system calls another business processing system, that is, the relationship between the two business processing systems in the business calling chain is an adjacent upstream and downstream relationship, and the upstream business processing system directly calls the downstream business processing system.

[0073] The mismatch of the processing data associated with the two business processing systems in a calling relationship may include the difference in the transmission data between the upstream and downstream business processing systems caused by the loss of business data due to transmission anomalies. Specifically: when the data transmitted by the upstream business processing system to the downstream business processing system is omitted or lost, the upstream business processing system needs to resend the transmission data to the downstream business processing system. Among them, in the processing data associated with the two business processing systems in a calling relationship, the processing data associated with the downstream business processing system can be empty. Exemplarily, the first data sent by the upstream business processing system to the downstream business processing data is used as the processing data associated with the upstream business processing system. The downstream business processing data does not receive the data associated with the business call chain sent by the upstream business processing system, that is, the processing associated with the downstream business processing data is empty. At this time, it can be determined that the processing data associated with the two business processing systems in the calling relationship do not match, so that it is determined that the two processing data meet the inconsistency condition and are used as the target processing data.

[0074] In the case of transmitted data loss or omission, the upstream business processing system only needs to retransmit the data to the downstream business processing system. Therefore, the business processing system performing the retry process is the upstream business processing system. Therefore, the system identifier, business call chain identifier and business data loss type of the upstream business processing system are used as the exception type to generate business call exception data and send it to the exception processing system. The exception processing system then notifies the upstream business processing system to resend the processed data that matches the business call chain identifier to the downstream business processing system.

[0075] In addition, if it is determined that the processing data received by the business processing system does not match the processing data sent, it indicates that an operation error occurs during the processing of the business processing system. At this time, the two processing data included in the business processing system can meet the inconsistency condition and these two processing data are used as target processing data. In the case of a calculation error or a processing error, as long as the current business processing system reprocesses the processing data, the business processing system that performs the retry processing is the current business processing system. Therefore, the system identifier, business call chain identifier and business processing error type of the current business processing system are used as the exception type to generate business call exception data and send it to the exception processing system. The exception processing system then notifies the business processing system to reprocess the processing data that matches the business call chain identifier and resends the processing result to the downstream business processing system.

[0076] By determining that the processing data associated with two business processing systems in a calling relationship do not match, determining the exception type as a business data loss type, and treating the upstream business processing system as a business processing system to be retried, thereby generating business call exception data, the business processing system that requires exception processing can be quickly and accurately determined, and the type of exception that has occurred can be accurately determined, so that compensation and processing can be performed precisely for the exception, thereby improving exception processing efficiency and accurately compensating for exceptions.

[0077] In a specific example, Figure 2b As shown, the business system includes a trading system 230, a risk control system 240, an access system 250, a clearing and settlement system 260, an audit system 290 and an exception handling system 280. In the prior art, an exception handling module is configured in each of the trading system 230, the risk control system 240, the access system 250 and the clearing and settlement system 260. The embodiment of the present invention can reduce the duplication of configuring and maintaining the exception handling module of each business processing system by uniformly reporting to the exception handling system 280 and performing uniform processing, reduce the cost of exception processing, and improve research and development efficiency, so that each business processing system only needs to focus on its own business logic implementation. In addition, the audit system 290 finds inconsistencies in the pre- and post-processing data in the business call chain according to the pre-configured data verification rules, and reports to the exception handling system 280, so that the exception of inconsistent data can be discovered in time, so that the abnormal data that requires T+1 offline verification and manual intervention can be automatically discovered and repaired in real time, thereby improving the real-time discovery and processing of the abnormality. At the same time, the business processing system sends exception data to the exception handling system through the message queue, which can decouple the business and improve the response speed and stability of each business processing system.

[0078] The embodiment of the present invention collects log data in the business processing system associated with the business call chain in the audit system, verifies the processing data associated with the business call chain, and generates business call exception data when the processing data meets the inconsistency condition, and sends it to the exception processing system to instruct the exception processing system to compensate for the exception. It can accurately discover exceptions at the data level, reduce data errors in the business call chain, realize automatic discovery of exceptions and automatic processing, reduce manual intervention, reduce the labor cost of exception processing, and improve the accuracy of the business call chain.

[0079] Embodiment 3

[0080] Figure 3The fourth embodiment is a corresponding device for implementing the system exception handling method provided by the above embodiments of the present invention, which can be implemented in software and / or hardware, and can generally be integrated into a computer device, specifically an exception handling system.

[0081] Accordingly, the device of this embodiment may include:

[0082] The business exception data collection module 310 is used to obtain business exception data sent by at least one business processing system, wherein the business exception data includes business interface exception data and business call exception data, and the business call exception data is obtained by checking the log data associated with the business call chain and when the log data meets the inconsistency condition;

[0083] The exception processing module 320 is used to determine retry processing information according to the business exception data, and send it to the business processing system matching the business exception data to instruct the matching business processing system to perform a business retry operation according to the retry processing information.

[0084] The embodiment of the present invention can uniformly collect the business exception data of each business processing system by collecting the business exception data sent by the business processing system. The business exception data includes the business interface exception data of each business processing system, and obtains the business call exception data existing in each business processing system in the business call chain. According to the business exception data, retry processing information is determined to instruct the business processing system with the exception to retry the business, thereby solving the problem in the prior art that the exceptions caused by the communication between the business processing systems cannot be processed. The exceptions occurring in the data in the business call chain can be counted and processed, and the exceptions existing in the business call chain can be captured in real time, thereby improving the accuracy of the exception processing of the business system and improving the accuracy of business processing.

[0085] Furthermore, the business exception data collection module 310 includes: a message queue data acquisition unit, which is used to obtain business exception data sent by at least one business processing system from a message queue, and the business processing system includes at least one of the following: an audit system, a transaction system, a risk control system, an access system, and a clearing and settlement system.

[0086] Furthermore, the business exception data includes business call exception data; the exception processing module 320 includes: a business call exception processing unit, used to extract a system identifier, a business call chain identifier and a first exception type from the business call exception data; generate retry processing information according to the business call chain identifier and the first exception type; send the retry processing information to a business processing system that matches the system identifier to instruct the matching business processing system to reprocess the business data that matches the business call chain identifier in accordance with a processing method that matches the first exception type.

[0087] Furthermore, the business exception data includes business interface exception data; the exception processing module 320 includes: a business interface exception processing unit, used to extract a system identifier, an interface identifier and a second exception type from the business interface exception data; determine the retry processing parameters according to the second exception type and a preset correspondence between the second exception type and the retry processing parameters, the retry processing parameters including a retry frequency parameter; determine the interface identifier and the retry processing parameters as retry processing information; send the retry processing information to a business processing system that matches the system identifier to instruct the matching business processing system to re-call the interface that matches the interface identifier in accordance with the processing method matched by the retry processing parameters.

[0088] The above-mentioned device can execute the system exception handling method provided by the embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0089] Embodiment 4

[0090] Figure 4 Schematic diagram of a system exception handling device in Embodiment 4 of the present invention. Embodiment 4 is a corresponding device for implementing the system exception handling method provided in the above embodiments of the present invention, which can be implemented in software and / or hardware, and can generally be integrated into a computer device, specifically an audit system.

[0091] Accordingly, the device of this embodiment may include:

[0092] The log data acquisition module 410 is used to acquire log data from at least two business processing systems associated with the business call chain;

[0093] A business data checking module 420 is used to query and check the processing data associated with the business call chain from the log data in each of the business processing systems;

[0094] The call chain exception data sending module 430 is used to generate business call exception data according to each target processing data when at least two target processing data meet the inconsistency condition, and send it to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information.

[0095] The embodiment of the present invention collects log data in the business processing system associated with the business call chain in the audit system, verifies the processing data associated with the business call chain, and generates business call exception data when the processing data meets the inconsistency condition, and sends it to the exception processing system to instruct the exception processing system to compensate for the exception. This can accurately detect exceptions at the data level, reduce data errors in the business call chain, and improve the accuracy of the business call chain.

[0096] Furthermore, the call chain exception data sending module 430 includes: a data loss type processing unit, which is used to use the processing data associated with the two business processing systems in the call relationship as target processing data if it is determined that the processing data associated with the two business processing systems in the call relationship do not match, and the two business processing systems in the call relationship include an upstream business processing system and a downstream business processing system; if the target processing data associated with the upstream business processing system is different from the target processing data associated with the downstream business processing system, then generate business call exception data based on the system identifier of the upstream business processing system, the business call chain identifier of the business call chain and the business data loss type.

[0097] The above-mentioned device can execute the system exception handling method provided by the embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0098] Embodiment 5

[0099] Figure 5 A schematic diagram of the structure of a computer device provided in Embodiment 5 of the present invention. Figure 5 A block diagram of an exemplary computer device 12 suitable for use in implementing embodiments of the present invention is shown. Figure 5 The computer device 12 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0100] like Figure 5 As shown, the computer device 12 is in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 connecting different system components (including the system memory 28 and the processing unit 16). The computer device 12 may be a device attached to the bus.

[0101] Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus structures. For example, these architectures include but are not limited to Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0102] The computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0103] The system memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. The computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 5 not shown, usually called a "hard drive"). Although Figure 5 Not shown in the figure, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a compact disk read-only memory (CD-ROM), a digital video disk (DVD-ROM) or other optical media) may be provided. In these cases, each drive may be connected to the bus 18 via one or more data medium interfaces. The system memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present invention.

[0104] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. Program modules 42 generally perform the functions and / or methods of the embodiments described herein.

[0105] The computer device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), one or more devices that enable a user to interact with the computer device 12, and / or any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may be performed through an input / output (I / O) interface 22. In addition, the computer device 12 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN)) through a network adapter 20. As shown in the figure, the network adapter 20 communicates with other modules of the computer device 12 through the bus 18. It should be understood that although Figure 5 Not shown, other hardware and / or software modules may be used in conjunction with the computer device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays (Redundant Arrays of Inexpensive Disks, RAID) systems, tape drives, and data backup storage systems.

[0106] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the system exception handling method provided by any embodiment of the present invention.

[0107] Embodiment 6

[0108] Embodiment 6 of the present invention provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method provided in all the embodiments of the present invention is implemented:

[0109] That is, when the program is executed by the processor, it is implemented as follows: obtaining business exception data sent by at least one business processing system, the business exception data including business interface exception data and business call exception data, the business call exception data is obtained by checking the log data associated with the business call chain and when the log data meets the inconsistency condition; determining retry processing information based on the business exception data, and sending it to the business processing system matching the business exception data, so as to instruct the matching business processing system to perform a business retry operation based on the retry processing information.

[0110] Alternatively, when the program is executed by the processor, it is implemented as follows: obtaining log data from at least two business processing systems associated with the business call chain; querying and verifying the processing data associated with the business call chain from the log data in each of the business processing systems; when at least two target processing data meet the inconsistency condition, generating business call exception data according to each of the target processing data, and sending it to the exception processing system to instruct the exception processing system to determine retry processing information according to the business call exception data, and instruct the matching business processing system to perform a business retry operation according to the retry processing information.

[0111] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a RAM, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0112] Computer-readable signal media may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0113] The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

[0114] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0115] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A system exception handling method, characterized in that: Applied in exception handling systems, including: Acquire business exception data sent by at least one business processing system, the business exception data including business interface exception data and business call exception data, the business call exception data is obtained by checking the log data associated with the business call chain and when the log data meets the inconsistency condition; the inconsistency condition is used to determine whether the corresponding processing data of each business processing system recorded in the log data associated with the business call chain is consistent; the inconsistency condition is used to determine whether the output data of the upstream business processing system is consistent with the input data of the downstream business processing system, and / or determine whether the calculation result obtained after the calculation of the data before calculation in the business processing system is consistent with the processing result; According to the business exception data, retry processing information is determined and sent to the business processing system matching the business exception data to instruct the matching business processing system to perform a business retry operation according to the retry processing information; the business interface exception data is used to determine the abnormal event that occurs in the business processing system itself; the business call exception data is the abnormal event that occurs in the business processing system in processing data; The determining retry processing information according to the service exception data, and sending the information to the service processing system matching the service exception data to instruct the matching service processing system to perform a service retry operation according to the retry processing information, includes: When the business exception data includes business call exception data, extracting a system identifier, a business call chain identifier and a first exception type from the business call exception data; the business call exception data is used to determine whether the business call chain is complete and whether the transmission data in the business call chain is consistent; Generate retry processing information according to the business call chain identifier and the first exception type; Sending the retry processing information to the business processing system matching the system identifier to instruct the matching business processing system to reprocess the business data matching the business call chain identifier in accordance with a processing method matching the first exception type; The retry processing information is used to instruct the upstream business processing system to re-execute the business retry operation of sending the processing result to the downstream business processing system when the processing result of the upstream business processing system is lost when being sent to the downstream business processing system; the retry processing information is also used to instruct the business processing system to re-execute the calculation for the request sent by the upstream business processing system when the calculation result of the calculation performed by the business processing system is wrong; When the business exception data includes business interface exception data, extracting the system identifier, the interface identifier and the second exception type from the business interface exception data; the business interface exception data is data associated with a call exception event that occurs when the business processing system calls an interface; Determine the retry processing parameters according to the second exception type and the preset correspondence between the second exception type and the retry processing parameters, wherein the retry processing parameters include a retry frequency parameter; Determine the interface identifier and the retry processing parameter as retry processing information; Sending the retry processing information to the business processing system matching the system identifier to instruct the matching business processing system to re-call the interface matching the interface identifier according to the processing method matching the retry processing parameter; The obtaining of business exception data sent by at least one business processing system includes: Business exception data sent by at least one business processing system is obtained from a message queue, wherein the business processing system includes at least one of the following: an audit system, a transaction system, a risk control system, an access system, and a clearing and settlement system.

2. A system exception handling method, characterized in that: Applications in audit systems include: Obtain log data from at least two business processing systems associated with the business call chain; Querying and verifying the processing data associated with the business call chain from the log data in each of the business processing systems; When at least two target processing data meet the inconsistency condition, business call exception data is generated according to each of the target processing data, and sent to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information; the inconsistency condition is used to determine whether the corresponding processing data of each business processing system recorded in the log data associated with the business call chain is consistent; the inconsistency condition is used to determine whether the output data of the upstream business processing system and the input data of the downstream business processing system are consistent, and / or determine whether the calculation result obtained after the calculation of the data before calculation in the business processing system is consistent with the processing result; When at least two target processing data satisfy the inconsistency condition, generating service call exception data according to each of the target processing data includes: If it is determined that the processing data associated with the two business processing systems in the calling relationship do not match, then using the processing data associated with the two business processing systems in the calling relationship as target processing data, wherein the two business processing systems in the calling relationship include an upstream business processing system and a downstream business processing system; If the target processing data associated with the upstream business processing system is different from the target processing data associated with the downstream business processing system, generating business call exception data according to the system identifier of the upstream business processing system, the business call chain identifier of the business call chain and the business data loss type; the business call exception data is used to determine whether the business call chain is complete and whether the transmission data in the business call chain is consistent; Among them, the retry processing information is used to instruct the upstream business processing system to re-execute the business retry operation of sending the processing result to the downstream business processing system when the processing result of the upstream business processing system is lost when sending it to the downstream business processing system; the retry processing information is also used to instruct the business processing system to re-execute the calculation for the request sent by the upstream business processing system when the calculation result of the calculation performed by the business processing system is erroneous.

3. A system abnormality handling device, characterized in that: Configured in the exception handling system, including: A business exception data collection module is used to obtain business exception data sent by at least one business processing system from a message queue, wherein the business exception data includes business interface exception data and business call exception data, and the business call exception data is obtained by checking the log data associated with the business call chain and when the log data meets the inconsistency condition; the inconsistency condition is used to determine whether the corresponding processing data of each business processing system recorded in the log data associated with the business call chain is consistent; the inconsistency condition is used to determine whether the output data of the upstream business processing system is consistent with the input data of the downstream business processing system, and / or determine whether the calculation result obtained after the calculation of the data before calculation in the business processing system is consistent with the processing result; the business processing system includes at least one of the following: an audit system, a transaction system, a risk control system, an access system, and a clearing and settlement system; The exception processing module is used to determine the retry processing information according to the business exception data, and send it to the business processing system matching the business exception data to instruct the matching business processing system to perform the business retry operation according to the retry processing information; the business interface exception data is used to determine the abnormal event that occurs in the business processing system itself; the business call exception data is the abnormal event that occurs in the business processing system in processing data; The exception handling module includes: a business call exception handling unit, which is used to extract a system identifier, a business call chain identifier and a first exception type from the business call exception data when the business exception data includes the business call exception data; generate retry processing information according to the business call chain identifier and the first exception type; the business call exception data is used to determine whether the business call chain is complete and whether the transmission data in the business call chain is consistent; send the retry processing information to the business processing system matching the system identifier to instruct the matching business processing system to reprocess the business data matching the business call chain identifier according to the processing method matching the first exception type; the retry processing information is used to instruct the upstream business processing system to re-execute the business retry operation of sending the processing result to the downstream business processing system when the processing result of the upstream business processing system is lost when it is sent to the downstream business processing system; the retry processing information is also used to instruct the business processing system to re-execute the calculation of the request sent by the upstream business processing system when the calculation result of the calculation performed by the business processing system is wrong; The exception handling module includes: a business interface exception handling unit, which is used to extract a system identifier, an interface identifier and a second exception type from the business interface exception data when the business exception data includes business interface exception data; the business interface exception data is data associated with a call exception event that occurs when a business processing system calls an interface; according to the second exception type and a preset correspondence between the second exception type and the retry processing parameter, determine the retry processing parameter, the retry processing parameter includes a retry frequency parameter; determine the interface identifier and the retry processing parameter as retry processing information; send the retry processing information to a business processing system that matches the system identifier to instruct the matching business processing system to re-call the interface that matches the interface identifier in accordance with the processing method matched by the retry processing parameter.

4. A system abnormality handling device, characterized in that: Configured in the audit system, including: A log data acquisition module, used to acquire log data from at least two business processing systems associated with a business call chain; A business data checking module, used to query and check the processing data associated with the business call chain from the log data in each of the business processing systems; A call chain exception data sending module is used to generate business call exception data according to each target processing data when at least two target processing data meet the inconsistency condition, and send it to the exception processing system to instruct the exception processing system to determine the retry processing information according to the business call exception data, and instruct the matching business processing system to perform the business retry operation according to the retry processing information; the inconsistency condition is used to determine whether the corresponding processing data of each business processing system recorded in the log data associated with the business call chain is consistent; the inconsistency condition is used to determine whether the output data of the upstream business processing system is consistent with the input data of the downstream business processing system, and / or determine whether the calculation result obtained after the calculation of the data before calculation in the business processing system is consistent with the processing result; The call chain abnormal data sending module includes: a data loss type processing unit, which is used to use the processing data associated with the two business processing systems in the call relationship as target processing data if it is determined that the processing data associated with the two business processing systems in the call relationship do not match, and the two business processing systems in the call relationship include an upstream business processing system and a downstream business processing system; if the target processing data associated with the upstream business processing system is different from the target processing data associated with the downstream business processing system, then generate business call abnormal data according to the system identifier of the upstream business processing system, the business call chain identifier of the business call chain and the business data loss type; The service call exception data is used to determine whether the service call chain is complete and whether the transmission data in the service call chain is consistent; Among them, the retry processing information is used to instruct the upstream business processing system to re-execute the business retry operation of sending the processing result to the downstream business processing system when the processing result of the upstream business processing system is lost when sending it to the downstream business processing system; the retry processing information is also used to instruct the business processing system to re-execute the calculation for the request sent by the upstream business processing system when the calculation result of the calculation performed by the business processing system is erroneous.

5. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the system exception handling method as described in any one of claims 1-2 is implemented.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the system exception handling method as described in any one of claims 1-2 is implemented.

Images