Abnormality processing method and device, equipment, medium and product

Abstract

The invention provides an exception handling method and device, equipment, a medium and a product, and relates to the field of data processing, and the specific technical scheme is as follows: operating a service analysis script, and extracting a service request matched with a target service type according to a preset triggering time; and obtaining respective service responses of the service requests corresponding to the service system data sources from the plurality of service system data sources, determining target responses from the service responses, and determining a response comparison result among the target responses according to the request result types, the target fields and the field values of the target responses. And under the condition that the response comparison result is inconsistent, performing exception processing on the response logs of the target responses to obtain exception information corresponding to the response logs and processing reference information for the exception information. And the exception information, the processing steps and the expected processing result are displayed, so that full automation of monitoring, comparison, preliminary exception processing and display is realized, the method does not depend on artificial experience, and the exception processing efficiency is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of data processing, and in particular to an exception processing method, device, equipment, medium and product. BACKGROUND

[0002] With the development of technology, more and more enterprises will carry out digital transformation. The digital transformation process involves switching of system platforms, for example, using more advanced and integrated digital platforms to replace or upgrade old and isolated systems.

[0003] In the traditional way, during the digital transformation process, the response results of multiple systems to the same request are compared by manual comparison. In the case of abnormal comparison process, the efficiency and accuracy of exception processing are low due to the limitation of manual experience and manual comparison efficiency. SUMMARY

[0004] Embodiments of the present application provide an exception processing method, device, equipment, medium and product, which can improve the efficiency and accuracy of exception processing.

[0005] In a first aspect, an exception processing method is provided, which comprises: running a business analysis script, extracting a business request matching a target business type according to a preset trigger time, the business request comprising a request business identifier; and automatically extracting the business request according to the preset trigger time by the business analysis script, achieving full automation from monitoring, comparison, preliminary exception processing and display, not relying on human experience, and improving the exception processing efficiency. From multiple business system data sources, the business request is obtained corresponding to the respective business responses of each business system data source, the business response comprising a response identifier, and a plurality of target responses are filtered in each business response, wherein the target response comprises a request result type, a target field, and a field value corresponding to the target field. According to the matching of the request business identifier and the response identifier, the target response is accurately filtered from the data source, providing a basis for subsequent consistency comparison, and further improving the efficiency of subsequent exception processing. Based on the request result type, the target field and the field value, the consistency of each target response is compared, the target response is compared from multiple angles of the request result type and the target field, and a response comparison result is obtained for representing the business consistency degree between each target response. The response comparison time is reduced, not limited by human experience, the accuracy and efficiency of the response comparison are improved, and the labor cost is reduced. In the case that the response comparison result is inconsistent, the response log containing the target response is obtained from the business system data source, and the response log of each target response is processed to obtain the exception information corresponding to each response log and the processing reference information for the exception information. In this method, on the one hand, the time from problem discovery to problem positioning is reduced, and the efficiency and accuracy of exception processing are improved. On the other hand, the exception information includes an exception type, an exception occurrence time and an exception cause, which accurately locates the exception type, the exception occurrence time and the exception cause. Displaying the exception information can provide accurate reference for users intuitively, and improve user experience. On the other hand, the processing reference information includes a processing step for processing the exception and an expected processing result corresponding to the processing step. The expected processing result is displayed to directly provide the user with the processing step for processing the exception, reducing the threshold for processing the exception, and further improving the overall processing efficiency of the exception processing.

[0006] In a possible implementation of the first aspect, the exception processing method further comprises: in the case that the response log acquisition fails, determining an exception data source corresponding to the target response from each of the business system data sources; and sending the business request to the exception data source according to a preset interval time of the business analysis script, until the response log containing the target response is obtained from the exception data source, or until the number of times of sending the business request to the exception data source exceeds a preset number threshold.

[0007] In this embodiment, first, a request retransmission mechanism is provided in the case of response log acquisition failure, without manual intervention, improving system robustness and automation. Second, in the case of response log acquisition failure, the abnormal data source corresponding to the target response is accurately determined from each business system data source, the abnormality of the business system data source is determined in advance, which provides a reference for subsequent abnormality processing, and helps to improve the accuracy of abnormality processing. Third, a fuse mechanism is set to stop retransmission when the number of times exceeds the preset number threshold, avoiding the system from falling into an infinite retry loop, thereby exhausting its own threads, connections and other resources, and thus improving the efficiency of abnormality processing.

[0008] In a possible implementation of the first aspect, the response comparison result for characterizing the business consistency between the target responses includes consistency and inconsistency; the consistency comparison of the target responses based on the request result type, the target field and the field value is performed to obtain the response comparison result for characterizing the business consistency between the target responses, including: type comparison of the request result type of each target response is performed to obtain the type comparison result corresponding to each target response, wherein the request result type includes response execution success and response execution failure; in the case that each type comparison result is consistent, field value comparison of the target field and the field value contained in each target response is performed to obtain the field value comparison result corresponding to each target response; in the case that each field value comparison result is consistent, it is determined that the response comparison result is consistent; in the case that there is a field value comparison result that is inconsistent, it is determined that the response comparison result is inconsistent; in the case that there is a type comparison result that is inconsistent, it is determined that the response comparison result is inconsistent.

[0009] In this embodiment, first, in the case that there is a type comparison result that is inconsistent, it is determined that the response comparison result is inconsistent, short-circuit judgment is performed, and whether the field value comparison result is consistent does not need to be further judged, thereby reducing unnecessary calculation resource consumption, especially when a large number of business requests are processed, the performance improvement is particularly significant. Second, for the type comparison level and the field value comparison level, the inconsistent level is accurately located, which provides a clear direction for subsequent processing, thereby improving the accuracy and efficiency of abnormality processing.

[0010] In a possible implementation manner of the first aspect, the processing of the exception of each of the target responses based on the response log of the target response respectively comprises: performing exception type analysis on the response log of each of the target responses to obtain a plurality of exception types corresponding to each of the target responses, an exception occurrence time of each of the exception types, and an exception cause of each of the exception types; for each of the exception types, determining a type processing step corresponding to the exception type and a type expected processing result corresponding to the type processing step in a knowledge base configured for the target service type, wherein the processing reference information for the exception information comprises the type processing step and the type expected processing result; and the type processing step is a step of processing the exception of the exception type.

[0011] In the embodiment, firstly, the processing schemes of the exceptions are stored in the knowledge base in a structured manner. Any operator can obtain the standardized processing scheme according to the analysis result. This realizes the sedimentation, sharing and inheritance of the enterprise operation and maintenance knowledge, reduces the dependence of the processing efficiency on the personal experience, and improves the exception processing efficiency. Secondly, the provision of the explicit type processing step and the type expected result greatly shortens the decision-making and troubleshooting time between the problem positioning and the processing start, and improves the exception processing efficiency.

[0012] In a possible implementation manner of the first aspect, the exception types comprise a time exception type, a system exception type and a service exception type; and the exception type analysis on the response log of each of the target responses to obtain a plurality of exception types corresponding to each of the target responses comprises: for each of the response logs, determining an execution duration of a target response corresponding to the response log based on an execution start time and an execution completion time of the response log; in a case where a duration threshold configured for the target response is greater than the execution duration, determining that an exception type corresponding to the target response is the time exception type; for each of the response logs, performing keyword extraction on the response log to obtain an error keyword of the response log; in a case where an error type corresponding to the error keyword is within a system error type set, determining that the exception type corresponding to the target response is the system exception type; for each of the response logs, performing error code extraction on the response log to obtain an error code of the response log; and in a case where the error code belongs to a preset error code, determining that the exception type corresponding to the target response is the service exception type.

[0013] In this embodiment, firstly, the target response corresponding to the abnormal type is determined from multiple dimensions in time, system, and service, which improves the accuracy of determining the abnormal type. Secondly, for each response log, the execution duration of the target response corresponding to the response log is determined based on the execution start time and the execution completion time of the response log. In the case where the duration threshold configured for the target response is greater than the execution duration, the abnormal type corresponding to the target response is determined as the time abnormal type, so that the system can discover the "sub-health" state of the system in advance when the business result has not yet been wrong (i.e., the function is still normal), thereby realizing forward-looking monitoring and improving the accuracy and efficiency of abnormal processing.

[0014] In a possible implementation of the first aspect, the abnormal processing method further includes: configuring connection information of each of the business analysis scripts and each of the business system data sources; and obtaining, from the multiple business system data sources, the business response corresponding to each of the business system data sources for the business request based on the connection information and the business analysis scripts.

[0015] In this embodiment, the business analysis scripts and the configuration file are used to obtain the business response corresponding to each of the business system data sources for the business request in the multiple business system data sources. In the case where a new business system data source needs to be added for consistency comparison, the core logic of the business analysis script does not need to be modified. Only the connection information (such as a new API address and an authentication method) of the system needs to be added in the configuration file, and the script can automatically identify and obtain data therefrom in the next run. The expansibility of the system is improved.

[0016] In a second aspect, an abnormal processing apparatus is provided, which includes: a script running module configured to run a business analysis script, extract a business request matching a target business type according to a preset trigger time, and the business request including a request business identifier; a response obtaining module configured to obtain, from multiple business system data sources, a business response corresponding to each of the business system data sources for the business request, and the business response including a response identifier; a response screening module configured to screen, from the business responses, multiple target responses in which the response identifier matches the request business identifier, and the target response including a request result type, a target field, and a field value corresponding to the target field; a comparison module configured to compare the target responses for consistency based on the request result type, the target field, and the field value, and obtain a response comparison result used to represent a business consistency degree between the target responses. a log obtaining module, configured to, in a case where the response comparison result is inconsistent, obtain, from the service system data source, a response log containing the target response; an exception processing module, configured to perform exception processing on the response log of each target response, to obtain corresponding exception information of each response log and processing reference information for the exception information, wherein the processing reference information includes a processing step for processing the exception and an expected processing result corresponding to the processing step, and the exception information includes an exception type, an exception occurrence time and an exception cause; a display module, configured to display the exception information, the processing step and the expected processing result.

[0017] In a third aspect, an exception processing device is provided, and the device includes a memory and at least one processor. The memory is in communication connection with the processor. The memory is configured to store computer program code including computer instructions. When the processor executes the computer instructions, the electronic device performs the method according to the first aspect and any possible implementation manner thereof.

[0018] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores computer instructions. When the computer instructions are executed by a processor, the method according to the first aspect and any possible implementation manner thereof is implemented.

[0019] In a fifth aspect, a computer program product is provided, and when the computer program product is run on a computer / executed by a processor of a computer, the method according to the first aspect and any possible implementation manner thereof is implemented. The computer can be the exception processing device according to the third aspect and any possible implementation manner thereof.

[0020] It can be understood that the exception processing device according to the second aspect, the exception processing device according to the third aspect, the computer readable storage medium according to the fourth aspect, and the computer program product according to the fifth aspect can achieve the beneficial effects as described in the first aspect and any possible implementation manner thereof, and thus repeated description is omitted. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 FIG. 1 is a structural schematic diagram of an exception processing system according to an embodiment of the present application; Figure 2 FIG. 2 is a flowchart of an exception processing method according to an embodiment of the present application; Figure 3 FIG. 3 is a flowchart of a request retransmission method according to an embodiment of the present application; Figure 4A structural schematic diagram of an abnormality processing apparatus provided in an embodiment of the present application is shown in the figure. Figure 5 A structural schematic diagram of an abnormality processing apparatus provided in an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0022] Hereinafter, the terms "first" and "second" are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features. In the description of the embodiments, the meaning of "a plurality of" is two or more, unless otherwise specified.

[0023] The exemplary embodiments will be described in detail below with reference to the accompanying drawings. In the following description, the same numbers refer to the same or similar elements unless otherwise specified. The embodiments described in the following exemplary embodiments do not represent all the embodiments consistent with the present application. Rather, they are merely examples of devices and methods consistent with some aspects of the present application, as detailed in the appended claims.

[0024] In the technical solutions provided in the embodiments of the present application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data, etc. comply with the relevant legal regulations and do not violate public order and good customs.

[0025] It should be noted that in the embodiments of the present application, some industry existing solutions such as software, components, models, etc. may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0026] The abnormality processing method provided in the embodiments of the present application can be applied to an abnormality processing system as shown in the figure. Figure 1 The system includes an abnormality processing apparatus 101 and a plurality of business system data sources 102.

[0027] The abnormality processing apparatus 101 executes a business analysis script to extract a business request matching a target business type according to a preset trigger time, and the business request includes a request business identifier.

[0028] The abnormality processing apparatus 101 obtains a business response corresponding to each business system data source from the plurality of business system data sources 102, and the business response includes a response identifier.

[0029] The exception handling device 101 filters multiple target responses from each service response whose response identifier matches the request service identifier. The target response includes the request result type, the target field, and the field value corresponding to the target field.

[0030] The exception handling device 101 performs a consistency comparison on each target response based on the request result type, target field, and field value, and obtains a response comparison result that characterizes the degree of business consistency between each target response.

[0031] If the response comparison results are inconsistent, the exception handling device 101 retrieves the response log containing the target response from the business system data source 102.

[0032] The anomaly handling device 101 performs anomaly processing on the response logs of each target response to obtain the anomaly information corresponding to each response log, as well as the processing reference information for the anomaly information. The processing reference information includes the processing steps for handling the anomaly and the expected processing results corresponding to the processing steps. The anomaly information includes the anomaly type, the time of anomaly occurrence, and the cause of anomaly.

[0033] The anomaly handling device 101 displays anomaly information, handling steps, and expected handling results.

[0034] The exception handling device 101 can be a server, which can be a standalone server or a server cluster composed of multiple servers. The business system data source 102 can be the business system's database or a processor or server with data storage capabilities.

[0035] In the process of enterprise digital transformation, the switchover between old and new systems is a critical step. To ensure a smooth business transition, it is necessary to verify the consistency of output results between the new system and the old system (or multiple parallel systems) when processing the same business requests.

[0036] Traditionally, this task relies heavily on manual comparison of results. When inconsistencies (i.e., anomalies) are found, the efficiency of the entire process depends entirely on the personal experience of the personnel involved. This results in low efficiency and accuracy in handling anomalies.

[0037] In this embodiment, by running a business analysis script and automatically extracting business requests according to a preset trigger time, the entire process from monitoring, comparison, initial anomaly handling, and display is fully automated, without relying on human experience, thus improving anomaly handling efficiency. When the response comparison results are inconsistent, response logs containing the target responses are retrieved from the business system data source. Anomaly handling is performed on the response logs of each target response to obtain the corresponding anomaly information for each log, as well as processing reference information for that anomaly. On the one hand, this reduces the time from problem discovery to problem localization, improving anomaly handling efficiency. On the other hand, the anomaly information includes the anomaly type, occurrence time, and cause, accurately pinpointing the anomaly type, occurrence time, and cause. Displaying the anomaly information provides users with accurate references, enhancing user experience. Furthermore, the processing reference information includes processing steps for handling the anomaly and the expected processing results for those steps. Displaying the expected processing results provides users with processing steps for handling the anomaly, lowering the barrier to anomaly handling and thus improving the overall efficiency of anomaly handling.

[0038] The exception handling method provided in this application can be applied to different business scenarios.

[0039] For example, in a scenario where banks switch between old and new systems, multiple business system data sources can include both the new and old business system data sources. Anomaly information can include anomaly information corresponding to both the new and old systems. Processing reference information can also include processing reference information corresponding to both the new and old systems. For instance, during the process of information technology innovation transformation, production transaction results from the old business system data source can be compared with the information technology innovation tracking results from the new business system data source, and then the comparison results can be used to analyze and resolve problems.

[0040] For example, in the scenario of switching between old and new financial systems, multiple business system data sources can include data sources from the new financial business system and data sources from the old financial business system.

[0041] For example, in the scenario of switching between old and new teaching systems in a school, multiple business system data sources can include data sources from the new teaching business system and data sources from the old teaching system.

[0042] Therefore, the embodiments of this application do not limit specific business scenarios.

[0043] In one embodiment, such as Figure 2 As shown, an exception handling method is provided that can be applied to... Figure 1The exception handling device 101 can be used in cloud computing platforms, edge computing devices, chips, or computing devices with data processing capabilities. This application embodiment does not limit the specific form of the device executing the method; taking the exception handling device 101 as a server and the method applied to a server as an example, the method specifically includes: S201, run the business analysis script and extract business requests that match the target business type according to the preset trigger time.

[0044] In some embodiments, the business analysis script may be a script used to analyze a specific business.

[0045] The trigger time can be the extraction time corresponding to the business analysis script. For example, the trigger time can be the system's batch processing time, such as from 11 pm to 2 am the next day.

[0046] The target business type can be a specific business type. For example, the target business type could include credit product transactions, precious metal product transactions, or school teaching supplies services. When the target business type is a transaction type, it can be matched one-to-one with a transaction code.

[0047] The business request can be a specific request corresponding to the target business type. For example, for the credit product transaction type, the corresponding business request could be a credit product application request, a credit product withdrawal request, or a credit product continuation request. As another example, for the school teaching supplies type, the business request could be a teaching supplies application request or a teaching supplies return request.

[0048] A business request also includes a request business identifier. This identifier can be a unique identifier specific to the business within the request. For example, the application number in a credit product application request. This identifier ensures the uniqueness of the request, facilitating subsequent matching of requests and responses. Another example is the teaching supplies identifier in a teaching supplies application request.

[0049] In a specific implementation, the business analysis script includes a scheduled task management tool in the Linux system. The server can run the scheduled task management tool in the business analysis script and extract business requests that match the target business type (transaction code) according to the preset trigger time in the scheduled task management tool. The business request includes a request business identifier.

[0050] In one specific implementation, before running the business analysis script, the server can pre-acquire multiple candidate requests, each containing a candidate business identifier. Then, the server can run the business analysis script to extract business requests matching the target business type from among the candidate requests, according to a preset trigger time.

[0051] In this embodiment, running a business analysis script automatically extracts business requests that match the target business type according to a preset trigger time, which can improve the efficiency of exception handling.

[0052] S202: Obtain the business response corresponding to each business system data source from multiple business system data sources for the business request.

[0053] The business response includes a response identifier.

[0054] After extracting the business requests that match the target business type, the server can obtain the business responses corresponding to each business system data source from multiple business system data sources to be compared. This allows for subsequent matching based on the business request identifier in the business response and filtering of the target response from multiple business responses.

[0055] In one embodiment, the business system data source can be a data source corresponding to both the old and new systems. For example, multiple business system data sources may include a data source from the new bank system and a data source from the old bank system. As another example, multiple business system data sources may include a data source from the new school system and a data source from the old school system.

[0056] A business response can be a response to a business request in the business system's data source. For example, a business request could be a credit product application request, and the business response could be a response to the credit product application request in both the bank's new system data source and the bank's old system data source (credit product application response).

[0057] A response identifier can be a unique identifier for a business response. For example, a response identifier can be a unique identifier for a business response, such as the application number in a credit product application response. This identifier is used to ensure the uniqueness of the response within the business system's data source.

[0058] In a specific implementation, the server can send business requests containing request business identifiers to multiple business system data sources. The server then retrieves the corresponding business responses from each of the multiple business system data sources, with each response including a response identifier.

[0059] For example, the server can send a business request containing a request business identifier to multiple business system data sources and determine the time of sending the business request. Based on the time of sending, the server can obtain the respective business responses of each business system data source corresponding to the business request, whereby the business responses include response identifiers. The time of generation of the business response is later than the time of sending.

[0060] In a specific implementation, the server can be configured with connection information for the business analysis scripts and the respective data sources of each business system. Based on the connection information and the business analysis scripts, the server can retrieve the corresponding business responses for each business system data source from multiple business system data sources.

[0061] In this embodiment, obtaining business responses from multiple business system data sources can provide a basis for subsequent consistency comparison of business responses. At the same time, it eliminates the need for manual acquisition of business responses from multiple business system data sources, resulting in higher accuracy in business response acquisition and thus improving the accuracy of anomaly handling.

[0062] S203, In each business response, filter out multiple target responses whose response identifiers match the request business identifiers.

[0063] The target response includes the request result type, the target field, and the field value corresponding to the target field.

[0064] In some embodiments, the target response may be a business response whose response identifier matches the request business identifier.

[0065] The request result type can represent the type of execution result for the request. For example, a credit product application request may correspond to a new credit product application response (the response in the bank's new system data source) and an old credit product application response (the response in the bank's old system data source). The request result type can represent whether the new credit product application response and the old credit product application response were executed successfully.

[0066] The target field can represent the specific fields in the target response. For a credit product application response, specific fields may include: applicant identity fields (name, contact information, place of residence, etc.) and credit product assessment result fields (credit rating, value of resources to be applied for, etc.).

[0067] The field value corresponding to the target field can represent the specific value of the target field. For example, a specific name, a specific credit rating, or a specific value of the resource to be applied for.

[0068] In a specific implementation, the server can filter multiple target responses whose response identifiers are the same as the request business identifiers from among the various business responses.

[0069] In a specific implementation, the server can determine the similarity between each business response and the business request, and identify the business responses with a similarity greater than a preset similarity threshold as the target responses. The target response includes the request result type, target fields, and the corresponding field values. The similarity can represent the similarity between the response identifier of the business response and the request business identifier.

[0070] In this embodiment, among each business response, multiple target responses whose response identifiers match the request business identifiers are filtered out. By using the identifier matching method, the manual screening time is reduced, the labor cost is lowered, and the accuracy and efficiency of response comparison are improved.

[0071] S204. Based on the request result type, target field, and field value, perform a consistency comparison on each target response to obtain a response comparison result that characterizes the degree of business consistency between the target responses.

[0072] Based on the request result type, target fields, and field values, a consistency comparison is performed on each target response to determine the degree of consistency between them. This is so that the response logs can be retrieved based on the degree of consistency, and anomaly analysis can be performed based on the response logs.

[0073] In some embodiments, business consistency can represent the degree of similarity between fields contained in a target response and fields contained in other target responses.

[0074] Response comparison results can represent a qualitative assessment of the degree of consistency. For example, if business consistency is low, the response comparison result is inconsistent; conversely, if business consistency is high, the response comparison result is consistent.

[0075] In a specific implementation, when the request result types of each target response type are the same, the server can perform a consistency comparison on each target response based on the target fields and field values ​​to obtain a response comparison result that characterizes the degree of business consistency between the target responses.

[0076] In a specific implementation, the response comparison results used to characterize the degree of business consistency between target responses include consistent and inconsistent responses. For two target responses, the server can perform similarity matching based on the request result type, target fields, and field values ​​contained in each target response, obtaining a first similarity corresponding to the request result type and a second similarity corresponding to the target fields. The server can determine the response comparison result as consistent if the sum of the first and second similarities is greater than a similarity threshold. The server can determine the response comparison result as inconsistent if the sum of the first and second similarities is less than or equal to the similarity threshold.

[0077] In a specific implementation, the response comparison results used to characterize the business consistency among various target responses include consistency and inconsistency. The server can perform type comparison on the request result types of each target response to obtain the corresponding type comparison results for each target response. The request result types include response execution success and response execution failure. If all type comparison results are consistent, the server can perform field value comparison on the target fields and field values ​​contained in each target response to obtain the corresponding field value comparison results for each target response. If all field value comparison results are consistent, the response comparison result is determined to be consistent; if there are inconsistencies in the field value comparison results, the response comparison result is determined to be inconsistent. The server can also determine that the response comparison result is inconsistent if there are inconsistencies in the type comparison results.

[0078] In this embodiment, based on the request result type, target fields, and field values, a consistency comparison is performed on each target response to obtain a response comparison result that characterizes the degree of business consistency between each target response. The consistency comparison is performed on each target response from multiple perspectives, ensuring the accuracy of the consistency comparison and thus improving the accuracy of subsequent anomaly handling.

[0079] S205, if the response comparison results are inconsistent, retrieve the response log containing the target response from the business system data source.

[0080] In some embodiments, the response log may be the log corresponding to the target response in the data source of the business system.

[0081] Response logs can specifically include: timestamps, log levels, component classes, thread information, stack traces, and log content. The timestamp records the precise time the log was generated (usually to the millisecond), which is fundamental for analyzing execution order and time consumption. The log level indicates the importance / severity of the log and serves as a key filter for information retrieval. The component class can be the component or class that generated the log, used to quickly locate the code location. Thread information can be used to trace the complete chain of the same business request when handling high-concurrency requests. The stack trace is the complete call stack corresponding to the log level, a "key" to locating system anomalies. The log content is the main body of the log, specifically describing what happened.

[0082] In a specific implementation, the server can directly retrieve response logs containing the target response from the business system's data source based on operating system commands or scripts.

[0083] In one specific implementation, the server can also pre-deploy a lightweight agent at the business system's data source. The server receives response logs containing the target response uploaded by the lightweight agent from the business system's data source.

[0084] In this embodiment, when the response comparison results are inconsistent, the response log containing the target response is obtained from the data source of the business system. The response log includes timestamp, log level, component class, thread information, stack trace information, log content, etc., which provides rich reference for subsequent exception handling based on the response log, thereby improving the accuracy of exception handling.

[0085] S206, perform exception handling on the response logs of each target response to obtain the exception information corresponding to each response log, as well as the reference information for handling the exception information.

[0086] The processing reference information includes the processing steps for handling exceptions and the expected processing results corresponding to the processing steps. The exception information includes the exception type, the time of occurrence of the exception, and the cause of the exception.

[0087] In some embodiments, the exception information may be exception information extracted from the response log where the exception exists.

[0088] The exception information can include the exception type, the time of occurrence of the exception, and the reason for the exception.

[0089] The exception type can represent the type of exception in the response log. Exception types can include time-based exception types, system exception types, or business exception types.

[0090] The processing reference information can be a reference processing strategy for handling this anomaly. It can include processing steps for handling the anomaly and the expected processing results for those steps. For example, for a time anomaly, the processing steps could include: 1. Checking the network connection status of the business system's data source; 2. Re-acquiring the business response; 3. Performing a consistency comparison again. Expected processing results could include: network connection status as connected or disconnected, and consistency comparison results as consistent or inconsistent.

[0091] In a specific implementation, exception handling for the response log of each target response can include: the server can determine the timestamp information, log level, stack trace information, and log content in the response log to obtain the exception type of the response log.

[0092] For example, the server can determine whether the exception type of the response log is a time-related exception based on the timestamp information. The server can determine whether the exception type of the response log is a system-related exception based on the log level and stack trace information. The server can determine whether the exception type of the response log is a business-related exception based on the log level and log content.

[0093] Understandably, log levels can include: DEBUG: the most detailed debugging information, used during development; INFO: normal system operation information, such as "received request" or "processing completed"; WARN: a warning indicating a potential problem, but the system is still running; ERROR: an error indicating an operation failed, but the system as a whole is still operational; FATAL / CRITICAL: a critical error that may cause system crashes. System exception types are typically reflected through ERROR or WARN levels, accompanied by stack trace information. Business exception types also typically use WARN or ERROR levels, but the log content is more business-oriented.

[0094] In a specific implementation, after determining the exception type, the server can determine the time of occurrence of the exception based on the timestamp information. The server can also determine the cause of the exception based on the log content.

[0095] In a specific implementation, after determining the exception type, occurrence time, and cause, the server can extract processing reference information matching the exception type, occurrence time, and cause from the knowledge base configured for exception information. This processing reference information includes the processing steps for handling the exception and the expected processing results corresponding to those steps.

[0096] In this implementation, anomaly processing is performed on the response logs of each target response to obtain the corresponding anomaly information for each response log, as well as reference information for handling the anomaly information. The anomaly information includes the anomaly type, the time of occurrence of the anomaly, and the cause of the anomaly. Accurately locating the anomaly type, the time of occurrence of the anomaly, and the cause of the anomaly can provide users with comprehensive reference and improve the user experience.

[0097] S207 displays the exception information, processing steps, and expected processing results.

[0098] In some embodiments, the exception information may include the exception type, the exception occurrence time, and the exception cause, wherein the exception occurrence time may be the time when the exception type is generated, and the exception cause may be the reason that leads to the exception type.

[0099] The processing steps can be reference steps for specific exception types. The expected processing result can be the result that the reference steps might yield.

[0100] In a specific implementation, the server can display the exception type, the time of the exception, the cause of the exception, the handling steps, and the expected handling result.

[0101] For example, to improve user experience, multiple exception information, processing steps, and expected processing results can be categorized and displayed according to exception type. Specifically, for each exception type, the server can extract the exception occurrence time, exception time, processing steps, and expected processing results corresponding to the exception type and display them.

[0102] For example, to further improve the user experience, based on the categorized display, the occurrence time of the exception, the exception time, the handling steps, and the expected handling result corresponding to the exception type can be displayed in sequence.

[0103] In this embodiment, a business analysis script is run to extract business requests matching the target business type according to a preset trigger time. These business requests include a request business identifier. The script automatically extracts these requests at the preset trigger time, achieving full automation from monitoring, comparison, initial anomaly handling, and display. This process is independent of human experience and improves anomaly handling efficiency. From multiple business system data sources, the business responses corresponding to each business system data source are obtained. These responses include response identifiers. Multiple target responses matching the request business identifier are filtered. Each target response includes a request result type, a target field, and the corresponding field value. Matching the request business identifier with the response identifier accurately filters target responses from the data source, providing a basis for subsequent consistency comparison and improving the efficiency of subsequent anomaly handling. Based on the request result type, target field, and field value, a consistency comparison is performed on each target response. The target responses are compared from multiple perspectives, including request result type and target field, to obtain response comparison results characterizing the degree of business consistency between the target responses. This reduces manual verification time, is independent of human experience, improves the accuracy and efficiency of response comparison, and lowers labor costs. When the response comparison results are inconsistent, response logs containing the target responses are retrieved from the business system's data source. Anomaly handling is then performed on the response logs for each target response, yielding corresponding anomaly information for each log, along with processing reference information for that anomaly. This method, on the one hand, reduces the time from problem discovery to problem localization, improving the efficiency and accuracy of anomaly handling. On the other hand, the anomaly information includes the anomaly type, occurrence time, and cause, accurately pinpointing the anomaly type, occurrence time, and cause. Displaying this information provides users with intuitive and accurate guidance, enhancing the user experience. Furthermore, the processing reference information includes the steps for handling the anomaly and the expected results for those steps. Displaying the expected results directly provides users with the steps for handling the anomaly, lowering the barrier to entry and thus improving the overall efficiency of anomaly handling.

[0104] In one embodiment, such asFigure 3 As shown, the exception handling methods also include: S301: In the event that the response log cannot be retrieved, determine the abnormal data source corresponding to the target response from the data sources of each business system.

[0105] S302, according to the preset interval of the business analysis script, send the business request to the abnormal data source until the response log containing the target response is obtained from the abnormal data source.

[0106] S303: According to the preset interval of the business analysis script, the business request is sent to the abnormal data source until the number of times the business request is sent to the abnormal data source exceeds the preset threshold.

[0107] In some embodiments, the abnormal data source can be the data source of a business system that experiences a log retrieval error.

[0108] There are several reasons why log retrieval might fail. These include insufficient permissions, incorrect paths, and network fluctuations. Insufficient permissions can mean that the user or process performing the log retrieval operation does not have permission to read the log file or directory. Incorrect paths can indicate that the log file path is misconfigured, the log file has been rotated or deleted, or the application is not generating logs as expected. Network fluctuations can indicate that there is no network connectivity between the server and the data source port of the business system, or that the port is blocked by a firewall.

[0109] The preset interval can be the interval between the time when log retrieval fails and the time when the request is resent.

[0110] In a specific implementation, after identifying the abnormal data source, the server can send business requests to the abnormal data source at preset intervals according to the business analysis script, until a response log containing the target response is obtained from the abnormal data source.

[0111] For example, if the abnormal data source includes the enterprise's new financial business system data source and the enterprise's old financial business system data source, the server can send business requests to the enterprise's new financial business system data source and the enterprise's old financial business system data source according to the preset interval of the business analysis script (i.e., request replay process) until a response log containing the target response is obtained from the abnormal data source, or until the number of times the business request is sent to the abnormal data source exceeds a preset threshold, and then stop resending.

[0112] In a specific implementation, after identifying the abnormal data source, the server can send business requests to the abnormal data source at preset intervals according to the business analysis script. If the response log fails to be retrieved, the business request will be resent at the preset intervals according to the business analysis script again, until the number of times the business request is sent to the abnormal data source exceeds a preset threshold, at which point resending will stop.

[0113] In this embodiment, firstly, a request resending mechanism is provided in the event of failure to obtain the response log, eliminating the need for manual intervention and improving system robustness and automation. Secondly, in the event of failure to obtain the response log, the abnormal data source corresponding to the target response is accurately determined from the data sources of various business systems, identifying the anomaly in the data source of that business system in advance, providing a reference for subsequent anomaly handling, and helping to improve the accuracy of anomaly handling. Thirdly, a circuit breaker mechanism is set up to stop resending until the number of attempts exceeds a preset threshold, preventing the system from falling into an infinite retry loop, thereby exhausting its own thread, connection, and other resources, and thus improving the efficiency of anomaly handling.

[0114] In one embodiment, the response comparison result used to characterize the business consistency among the target responses includes consistency and inconsistency. Based on the request result type, target fields, and field values, a consistency comparison is performed on each target response to obtain a response comparison result characterizing the degree of business consistency among the target responses. This includes: performing a type comparison on the request result type of each target response to obtain a corresponding type comparison result for each target response, wherein the request result type includes response execution success and response execution failure. If all type comparison results are consistent, a field value comparison is performed on the target fields and field values ​​contained in each target response to obtain a corresponding field value comparison result for each target response. If all field value comparison results are consistent, the response comparison result is determined to be consistent; if any field value comparison result is inconsistent, the response comparison result is determined to be inconsistent. If any type comparison result is inconsistent, the response comparison result is determined to be inconsistent.

[0115] In some embodiments, the type comparison result can indicate whether the request result types of each target response are consistent. The type comparison result can include consistent type and inconsistent type. For example, consistent type can mean that the request result types of multiple target responses are all consistent, while inconsistent type can mean that there are at least two different request result types in the request results of multiple target responses.

[0116] The request result types include "response execution successful" and "response execution failed". If each target response's request result type is either "response execution successful" or "response execution failed", then the type comparison result is consistent. If each target response's request result type includes both "response execution successful" and "response execution failed", then the type comparison result is inconsistent, and correspondingly, the response comparison result is also inconsistent.

[0117] In some embodiments, the field value comparison result can be the comparison result of target fields and field values ​​between each target response and other target responses. For example, target fields may include name, contact information, place of residence, credit rating, and the value of the resource to be requested. If the field values ​​corresponding to the target fields in the first target response and the target fields in the second target response are all equal, then the field value comparison result can be considered consistent.

[0118] If all type comparison results are consistent, and all field value comparison results are consistent, the response comparison result is determined to be consistent. If there are inconsistencies in field value comparison results or inconsistencies in type comparison results, the response comparison result is determined to be inconsistent.

[0119] In this embodiment, firstly, when there is an inconsistency in the type comparison results, the response comparison results are determined to be inconsistent, and a short-circuit judgment is made without further judging whether the field value comparison results are consistent. This reduces unnecessary consumption of computing resources, and the performance improvement is particularly significant when processing massive business requests. Secondly, for both the type comparison level and the field value comparison level, the inconsistent level is accurately located, providing a clear direction for subsequent processing, thereby improving the accuracy and efficiency of exception handling.

[0120] In one embodiment, exception handling is performed on the response logs of each target response to obtain exception information corresponding to each response log, as well as reference information for handling the exception information. This includes: performing exception type analysis on the response logs of each target response to obtain multiple exception types corresponding to each target response, the exception occurrence time of each exception type, and the exception cause of each exception type. For each exception type, the type handling steps corresponding to the exception type and the expected handling result corresponding to the type handling steps are determined in the knowledge base configured for the target business type. The reference information for handling the exception information includes the type handling steps and the expected handling result; the type handling steps are the steps for handling the exception type.

[0121] In some embodiments, the exception type can represent the type of exception in the response log. Exception types can include time-based exception types, system exception types, or business exception types.

[0122] The time of occurrence of an anomaly can be the time of occurrence corresponding to the anomaly type.

[0123] An exception can be the cause of an exception type.

[0124] A knowledge base can store solutions for handling known anomalies and the expected effects of those solutions. Specifically, multiple candidate processing steps and their corresponding expected results are structured and stored in the knowledge base.

[0125] The handling steps can be the steps corresponding to the exception type. For example, the handling steps for time exception types, system exception types, and business exception types.

[0126] The expected processing result for a type can be the expected result corresponding to the processing steps under the exception type. For example, the expected result for a time-related exception type could be that the execution time of the response log is less than the time threshold. Another example is that the expected result for a system exception type could be that the response log does not contain error keywords or the error keywords do not belong to the system error type set. Yet another example is that the expected result for a business exception type could be that the response log does not contain error codes or the error codes do not belong to the preset error codes.

[0127] In a specific implementation, for each exception type, the knowledge base configured for the target business type determines the type handling steps corresponding to the exception type and the expected handling results corresponding to the type handling steps. Specifically, this may include: exception types that the server can determine, a knowledge base containing multiple candidate handling steps, and the expected handling results corresponding to each candidate handling step. The server can filter the type handling steps that match the exception type from among the candidate handling steps, and determine the expected handling result of the candidate handling step corresponding to the type handling step as the expected type result of the type handling step.

[0128] In this embodiment, firstly, the handling solutions for anomalies are structurally stored in a knowledge base. Any operator can obtain standardized handling solutions based on the analysis results. This enables the accumulation, sharing, and inheritance of enterprise operation and maintenance knowledge, reduces the dependence of processing efficiency on individual experience, and improves anomaly handling efficiency. Secondly, providing clear type-specific handling steps and expected results greatly shortens the decision-making and troubleshooting time from locating the problem to starting processing, thus improving anomaly handling efficiency.

[0129] In one embodiment, the exception types include time-related exception types, system exception types, and business exception types. Exception type analysis is performed on the response logs of each target response to obtain multiple exception types corresponding to each target response, including: For each response log, based on the execution start time and execution completion time of the response log, determining the execution duration of the target response corresponding to the response log. If the duration threshold configured for the target response is greater than the execution duration, the exception type corresponding to the target response is determined to be a time-related exception type. For each response log, keyword extraction is performed to obtain error keywords; if the error type corresponding to the error keyword is within the range of the system error type set, the exception type corresponding to the target response is determined to be a system exception type. For each response log, error code extraction is performed to obtain the error code; if the error code belongs to a preset error code, the exception type corresponding to the target response is determined to be a business exception type.

[0130] In some embodiments, the execution start time may represent the time when the business request was received, as recorded in the response log.

[0131] The execution completion time can represent the moment recorded in the response log when the business request was processed and a business response was obtained. For example, both the execution start time and execution completion time can be obtained by reading timestamp information.

[0132] Execution duration can be the interval between the start time and the completion time of execution.

[0133] The duration threshold can be a threshold configured for the execution time of the target response. The duration threshold can be flexibly selected according to the actual situation, and no limitation is made here.

[0134] Error keywords are keywords extracted from response logs that indicate anomalies in the logs. Error keywords can be status terms for the infrastructure, resources, or technical components of the business system's data source. Examples include database connection errors, disk space shortages, and third-party API call errors.

[0135] The error types corresponding to error keywords can be database connection error types, disk storage error types, and API call error types.

[0136] The system error type set can represent a set containing multiple preset error types.

[0137] Error codes can be identifiers set for various business anomalies. For example, error code (Ec) E1 can indicate that the user's credit rating in a credit product application request is too low, error code E2 can indicate that the user's pending resource value in a credit product application request exceeds the resource limit, and error code E3 can indicate that the user's age in a credit product application request is below the limit.

[0138] Preset error codes can be configured for different types of business exceptions. Specifically, preset error codes can be E1 (credit rating too low), E2 (exceeding resource limits), and E3 (age below limit).

[0139] In a specific implementation, if the duration threshold configured for the target response exceeds the execution time, the server can determine that the exception type corresponding to the target response is a time-related exception type. If the error type corresponding to the error keyword is within the range of the system error type set, the server can determine that the exception type corresponding to the target response is a system exception type. If the error code belongs to a preset error code, the server can determine that the exception type corresponding to the target response is a business exception type.

[0140] In this embodiment, firstly, the system is divided into three orthogonal dimensions: time, system, and business. This multi-dimensional approach helps determine the anomaly type corresponding to the target response, improving the accuracy of anomaly type identification. Secondly, for each response log, the execution duration of the target response is determined based on the start and end times of the log. When the configured duration threshold for the target response exceeds the execution duration, the anomaly type is determined to be a time-related anomaly. This allows the system to detect system "sub-health" states before business results malfunction (i.e., when functionality is still normal), achieving proactive monitoring and improving the accuracy and efficiency of anomaly handling.

[0141] In one embodiment, the method further includes: configuring connection information between the business analysis script and each business system data source. Obtaining the business response corresponding to each business system data source for a business request from multiple business system data sources includes: obtaining the business response corresponding to each business system data source for a business request from multiple business system data sources based on the connection information and the business analysis script.

[0142] In some embodiments, the connection information may be information from the configuration file of the business system's data source. Specifically, the connection information may be a unique identifier of the business system's data source and the type of the data source (database, interface, message queue, or one of these).

[0143] For example, if the data source of the business system is the data source of the school's new teaching business system, the connection information of the data source may include the unique identifiers corresponding to the database, interface, and message queue.

[0144] In a specific implementation, the server can obtain the business response corresponding to each business system data source from multiple business system data sources based on the unique identifiers corresponding to the database, interface, and message queue, and the business analysis script.

[0145] In a specific implementation, the server can determine multiple business system data sources that match the unique identifiers corresponding to the database, interface, and message queue. The server can then authenticate each business system data source based on the authentication file connected by the business analysis script. From the authenticated business system data sources, the server can retrieve the corresponding business responses for each business system data source.

[0146] In this embodiment, a business analysis script and configuration file are used to obtain the corresponding business responses for each business system data source from multiple business system data sources. When a new business system data source needs to be added for consistency comparison, the core logic of the business analysis script does not need to be modified. Only a section of connection information for that system (such as a new API address and authentication method) needs to be added to the configuration file, and the script can automatically identify and retrieve data from it on the next run. This improves the system's scalability.

[0147] Figure 4 This is a schematic diagram of an exception handling device provided in an embodiment of this application. Figure 5 As shown, the exception handling device includes: a script execution module 401, a response acquisition module 402, a response filtering module 403, a comparison module 404, a log acquisition module 405, an exception handling module 406, and a display module 407.

[0148] The script execution module 401 is used to run a business analysis script and extract business requests that match the target business type according to a preset trigger time. The business request includes a request business identifier. The response acquisition module 402 is used to acquire, from multiple business system data sources, the business response corresponding to each of the business system data sources for the business request, wherein the business response includes a response identifier; The response filtering module 403 is used to filter multiple target responses that match the response identifier and the request business identifier among the various business responses, wherein the target response includes a request result type, a target field, and a field value corresponding to the target field; The comparison module 404 is used to perform a consistency comparison on each of the target responses based on the request result type, the target field, and the field value, and obtain a response comparison result that characterizes the degree of business consistency between the target responses. The log acquisition module 405 is used to acquire a response log containing the target response from the data source of the business system when the response comparison result is inconsistent. An exception handling module 406 is used to perform exception handling on the response logs of each of the target responses to obtain exception information corresponding to each of the response logs and processing reference information for the exception information. The processing reference information includes processing steps for handling exceptions and expected processing results corresponding to the processing steps. The exception information includes exception type, exception occurrence time and exception cause. The display module 407 is used to display the abnormal information, the processing steps, and the expected processing result.

[0149] In other embodiments, the above-mentioned exception handling device may further include a request retransmission module, which, in the event that the response log acquisition fails, determines the abnormal data source corresponding to the target response from the data sources of each of the business systems; and sends the business request to the abnormal data source according to a preset interval of the business analysis script, until a response log containing the target response is obtained from the abnormal data source, or until the number of times the business request is sent to the abnormal data source exceeds a preset number threshold.

[0150] In other embodiments, the response comparison results used to characterize the business consistency among the target responses include consistency and inconsistency; the comparison module 404 is further configured to perform type comparison on the request result type of each target response to obtain the type comparison result corresponding to each target response, wherein the request result type includes response execution success and response execution failure; when all the type comparison results are consistent, the target fields and field values ​​contained in each target response are compared to obtain the field value comparison result corresponding to each target response; when all the field value comparison results are consistent, the response comparison result is determined to be consistent; when there is a field value comparison result that is inconsistent, the response comparison result is determined to be inconsistent; when there is a type comparison result that is inconsistent, the response comparison result is determined to be inconsistent.

[0151] In other embodiments, the above-mentioned exception handling module 406 is further configured to perform exception type analysis on the response logs of each of the target responses to obtain multiple exception types corresponding to each of the target responses, the exception occurrence time of each of the exception types, and the exception cause of each of the exception types; for each of the exception types, in the knowledge base configured for the target service type, the type handling steps corresponding to the exception type and the expected type handling result corresponding to the type handling steps are determined, wherein the processing reference information for the exception information includes the type handling steps and the expected type handling result; the type handling steps are the steps for handling the exception of the exception type.

[0152] In other embodiments, the exception types include time exception types, system exception types, and business exception types; the exception handling module 406 is further configured to, for each response log, determine the execution duration of the target response corresponding to the response log based on the execution start time and execution completion time of the response log; if the duration threshold configured for the target response is greater than the execution duration, determine the exception type corresponding to the target response as a time exception type; for each response log, perform keyword extraction on the response log to obtain the error keywords of the response log; if the error type corresponding to the error keyword is within the range of the system error type set, determine the exception type corresponding to the target response as a system exception type; for each response log, perform error code extraction on the response log to obtain the error code of the response log; if the error code belongs to a preset error code, determine the exception type corresponding to the target response as a business exception type.

[0153] In other embodiments, the above-mentioned exception handling device may further include a configuration module for configuring the connection information between the business analysis script and each of the business system data sources; the above-mentioned response acquisition module 402 is further configured to acquire, based on the connection information and the business analysis script, the business response corresponding to each of the business system data sources from multiple business system data sources.

[0154] The exception handling device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0155] Figure 5 This is a schematic diagram of an anomaly handling device provided in an embodiment of this application. Figure 5 As shown, the exception handling device includes: a memory 501, a transceiver 502, and at least one processor 503.

[0156] The transceiver 502 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 502 can be used for business requests, business responses, etc.

[0157] The memory 501 stores computer program code, which includes computer instructions. These computer instructions run in the aforementioned exception handling device to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, external hard drive, read-only memory, disk, or optical disc, etc.

[0158] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0159] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0160] Optionally, the memory 501 can be either standalone or integrated with the processor 503. When the memory 501 is set up independently, it is connected to the processor 503 via a system bus.

[0161] This application also provides a chip for executing instructions, which is used to execute the technical solution of the exception handling method in the above embodiments.

[0162] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the exception handling method described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the exception handling device can execute the technical solution of the exception handling method described in the above embodiments.

[0163] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the exception handling method in the above embodiments.

[0164] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0165] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0166] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0167] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0168] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0169] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0170] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0171] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0172] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application.

Claims

1. An exception handling method, characterized in that, The method includes: Run the business analysis script and extract business requests that match the target business type according to the preset trigger time. The business requests include a request business identifier. The business response corresponding to each of the business system data sources is obtained from multiple business system data sources, and the business response includes a response identifier; In each of the aforementioned business responses, multiple target responses that match the response identifier with the request business identifier are filtered out, wherein the target response includes a request result type, a target field, and a field value corresponding to the target field; Based on the request result type, the target field, and the field value, a consistency comparison is performed on each of the target responses to obtain a response comparison result that characterizes the degree of business consistency between the target responses. If the response comparison results are inconsistent, retrieve the response log containing the target response from the data source of the business system; Anomaly processing is performed on the response logs of each target response to obtain anomaly information corresponding to each response log and processing reference information for the anomaly information. The processing reference information includes processing steps for handling anomalies and expected processing results corresponding to the processing steps. The anomaly information includes anomaly type, anomaly occurrence time, and anomaly cause. The abnormal information, the processing steps, and the expected processing result are displayed.

2. The method according to claim 1, characterized in that, The method further includes: If the response log acquisition fails, the abnormal data source corresponding to the target response shall be determined from the data sources of each of the business systems. According to the preset interval of the business analysis script, the business request is sent to the abnormal data source until a response log containing the target response is obtained from the abnormal data source, or until the number of times the business request is sent to the abnormal data source exceeds a preset threshold.

3. The method according to claim 1, characterized in that, The response comparison results used to characterize the business consistency among the target responses include consistent and inconsistent responses; Based on the request result type, the target field, and the field value, a consistency comparison is performed on each target response to obtain a response comparison result characterizing the degree of business consistency among the target responses, including: The request result types of each of the target responses are compared to obtain the type comparison results corresponding to each of the target responses, wherein the request result types include response execution success and response execution failure; If all the comparison results of the types are consistent, the target fields and field values ​​contained in each target response are compared to obtain the field value comparison results corresponding to each target response; if all the field value comparison results are consistent, the response comparison results are determined to be consistent; if there are inconsistencies in the field value comparison results, the response comparison results are determined to be inconsistent. If there is a discrepancy in the type comparison results, the response comparison results are determined to be inconsistent.

4. The method according to claim 1, characterized in that, The step of performing anomaly processing on the response logs of each of the target responses to obtain anomaly information corresponding to each response log, and processing reference information for the anomaly information, includes: Anomaly type analysis is performed on the response logs of each target response to obtain multiple anomaly types corresponding to each target response, the anomaly occurrence time of each anomaly type, and the anomaly cause of each anomaly type. For each of the aforementioned exception types, in the knowledge base configured for the target business type, the type processing steps corresponding to the exception type and the expected processing results corresponding to the type processing steps are determined. The processing reference information for the exception information includes the type processing steps and the expected processing results. The type processing steps are the steps for processing the exception type.

5. The method according to claim 4, characterized in that, The anomaly types include time anomaly types, system anomaly types, and business anomaly types; Anomaly type analysis was performed on the response logs of each of the aforementioned target responses to obtain multiple anomaly types corresponding to each target response, including: For each of the aforementioned response logs, the execution duration of the target response corresponding to the response log is determined based on the execution start time and execution completion time of the response log; if the duration threshold configured for the target response is greater than the execution duration, the exception type corresponding to the target response is determined to be a time exception type. For each of the aforementioned response logs, keyword extraction is performed on the response logs to obtain error keywords; if the error type corresponding to the error keyword is within the range of the system error type set, the exception type corresponding to the target response is determined to be a system exception type; For each of the aforementioned response logs, an error code is extracted from the response log to obtain the error code of the response log; if the error code belongs to a preset error code, the exception type corresponding to the target response is determined to be a business exception type.

6. The method according to claim 1, characterized in that, The method further includes: Configure the connection information between the business analysis script and the respective data sources of each of the business systems; Obtaining the business response corresponding to each of the business system data sources for the business request from multiple business system data sources includes: Based on the connection information and the business analysis script, the business response corresponding to each of the business system data sources is obtained from multiple business system data sources.

7. An anomaly handling device, characterized in that, include: The script execution module is used to run the business analysis script and extract business requests that match the target business type according to a preset trigger time. The business request includes a request business identifier. The response acquisition module is used to acquire, from multiple business system data sources, the business response corresponding to each of the business system data sources for the business request, wherein the business response includes a response identifier; The response filtering module is used to filter multiple target responses that match the response identifier and the request business identifier among the various business responses, wherein the target response includes a request result type, a target field, and a field value corresponding to the target field; The comparison module is used to perform a consistency comparison on each of the target responses based on the request result type, the target field, and the field value, and obtain a response comparison result that characterizes the degree of business consistency between the target responses. The log acquisition module is used to acquire response logs containing the target response from the data source of the business system when the response comparison results are inconsistent. An exception handling module is used to perform exception handling on the response logs of each of the target responses to obtain exception information corresponding to each of the response logs and processing reference information for the exception information. The processing reference information includes processing steps for handling exceptions and expected processing results corresponding to the processing steps. The exception information includes exception type, exception occurrence time and exception cause. The display module is used to display the abnormal information, the processing steps, and the expected processing results.

8. An anomaly handling device, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the exception handling device causes the exception handling device to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1-6.

Images