Error-reported transaction positioning method and related device
By obtaining and analyzing the transaction log and background transaction code, determining the target transaction and positioning the method name of the error-reported transaction in the corresponding transaction background program, the problem of inefficient positioning of the error-reported transaction in the distributed system is solved, and more efficient and accurate positioning is achieved.
Patent Information
- Application Number
- CN202411743769.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-30
- Publication Date
- 2025-03-11
AI Technical Summary
In distributed systems, manual positioning error-reporting transactions are inefficient and prone to inaccurate, especially in complex scenarios where centralized systems and distributed systems are parallel.
By obtaining the error transaction information and transaction logs sent by the trading front-end program, determining the log number of the target transaction, and looking up the transaction background program from the general control transaction table based on the background transaction code, determining whether there is a collaborative request, and then positioning the method name of the error transaction in the local services of the centralized or distributed trading background program.
The positioning efficiency and accuracy of error-reporting transactions have been improved, and different error-reporting positioning strategies have been designed for the two centralized and distributed transaction background program architectures.
Smart Images

Figure CN119597530A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method for locating an error transaction and a related device. Background Art
[0002] With the continuous advancement of technology in the financial industry, the system architecture is undergoing a major transformation from centralized systems to distributed systems, aiming to overcome the limitations of traditional centralized architectures. This change achieves horizontal expansion, flexible iteration, and performance improvement of the system by splitting a large system into multiple independent systems. However, the construction of distributed systems also increases the complexity of the system, making it more difficult to locate error transactions.
[0003] At present, it is mainly the testers who understand and analyze the information of the error transaction and then locate the error transaction.
[0004] However, in complex scenarios where centralized and distributed systems run in parallel, manually locating error transactions is time-consuming and labor-intensive, which is not only inefficient but also prone to inaccurate positioning. Summary of the invention
[0005] In view of the above problems, the present application provides a method and a related device for locating error transactions, in order to improve the efficiency and accuracy of locating error transactions. The specific scheme is as follows:
[0006] The first aspect of the present application provides a method for locating an error transaction, comprising:
[0007] Acquire the information of the error transaction and the transaction log sent by the transaction front-end program, wherein the information of the error transaction includes the log number and error code of the error transaction, and the transaction log includes the log numbers of multiple transactions;
[0008] Determine a target transaction from the multiple transactions, wherein the log number of the target transaction is consistent with the log number of the error reporting transaction;
[0009] Based on the acquired background transaction code of the target transaction, searching the transaction background program corresponding to the target transaction from the preset master control transaction table, and judging whether there is a coordination request corresponding to the target transaction, the background transaction code of the target transaction is respectively consistent with the background transaction code of the transaction background program and the background transaction code of the coordination request;
[0010] If the transaction backend program is a centralized transaction backend program, then based on the error code, locate the method name of the error reporting transaction in the local service of the centralized transaction backend program;
[0011] If the transaction backend program is a distributed transaction backend program and there is no collaborative request corresponding to the target transaction, then based on the error code, the method name of the error reporting transaction is located in the local service of the distributed transaction backend program.
[0012] In a possible implementation, determining a target transaction from the multiple transactions includes:
[0013] Based on the log numbers of the multiple transactions, determining a candidate transaction that is consistent with the log number of the error-reporting transaction from the multiple transactions;
[0014] If the number of the candidate transactions is 1, the candidate transaction is used as the target transaction;
[0015] If the number of the candidate transactions is greater than 1, a target transaction is determined from the candidate transactions based on the acquired operation time and operator identification of the candidate transactions, the operation time of the target transaction is consistent with the operation time of the candidate transactions, and the operator identification of the target transaction is consistent with the operator identification of the candidate transactions.
[0016] In a possible implementation, the method further includes:
[0017] If the transaction backend program is a distributed transaction backend program and there is a collaborative request corresponding to the target transaction, then the collaborative program corresponding to the collaborative request is obtained;
[0018] If the collaborative program is the centralized transaction background program, then based on the error code, locate the method name of the error reporting transaction in the local service of the centralized transaction background program;
[0019] If the collaborative program is a remote service program, the method name of the error reporting transaction is located in the distributed transaction background program based on the type of the acquired error code.
[0020] In a possible implementation, locating the method name of the error reporting transaction in the distributed transaction background program based on the acquired error code type includes:
[0021] If the type of the error code obtained is a first preset type, locating the method name of the error reporting transaction in the local service program of the distributed transaction background program based on the error code;
[0022] If the type of the error code obtained is the second preset type, then based on the error code, the method name of the error reporting transaction is located in the remote service program of the distributed transaction background program.
[0023] A second aspect of the present application provides a device for locating an error transaction, comprising:
[0024] An acquisition unit, used to acquire information of an error transaction and a transaction log sent by a transaction front-end program, wherein the information of the error transaction includes a log number and an error code of the error transaction, and the transaction log includes log numbers of multiple transactions;
[0025] a determining unit, configured to determine a target transaction from the plurality of transactions, wherein the log number of the target transaction is consistent with the log number of the error reporting transaction;
[0026] a search unit, configured to search for a transaction backend program corresponding to the target transaction from a preset master control transaction table based on the acquired backend transaction code of the target transaction, and determine whether there is a coordination request corresponding to the target transaction, wherein the backend transaction code of the target transaction is respectively consistent with the backend transaction code of the transaction backend program and the backend transaction code of the coordination request;
[0027] A first locating unit, configured to locate the method name of the error-reporting transaction in a local service of the centralized transaction background program based on the error code if the transaction background program is a centralized transaction background program;
[0028] The second positioning unit is used to locate the method name of the error transaction in the local service of the distributed transaction background program based on the error code if the transaction background program is a distributed transaction background program and there is no collaborative request corresponding to the target transaction.
[0029] In a possible implementation, the determining unit includes:
[0030] A first determining subunit is configured to determine, based on the log numbers of the multiple transactions, a candidate transaction that is consistent with the log number of the error reporting transaction from the multiple transactions;
[0031] a second determining subunit, configured to use the candidate transaction as the target transaction if the number of the candidate transactions is 1;
[0032] The third determination subunit is used to determine a target transaction from the candidate transactions based on the acquired operation time and operator identifier of the candidate transactions if the number of the candidate transactions is greater than 1, wherein the operation time of the target transaction is consistent with the operation time of the candidate transactions, and the operator identifier of the target transaction is consistent with the operator identifier of the candidate transactions.
[0033] In a possible implementation, the device further includes:
[0034] an acquisition subunit, configured to acquire, if the transaction background program is a distributed transaction background program and there is a collaboration request corresponding to the target transaction, a collaboration program corresponding to the collaboration request;
[0035] A first positioning subunit is used for locating the method name of the error-reporting transaction in the local service of the centralized transaction background program based on the error code if the collaborative program is the centralized transaction background program;
[0036] The second positioning subunit is used to locate the method name of the error-reporting transaction in the distributed transaction background program based on the type of the acquired error code if the collaborative program is a remote service program.
[0037] A third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements the method for locating an erroneous transaction of a customer according to the first aspect or any implementation method of the first aspect.
[0038] A fourth aspect of the present application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:
[0039] The memory is used to store computer programs;
[0040] The processor is used to execute the computer program so that the electronic device can implement the method for locating an error transaction of a customer according to the first aspect or any implementation method of the first aspect.
[0041] A fifth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement a method for locating an erroneous transaction of a customer of the first aspect or any implementation method of the first aspect.
[0042] By means of the above technical scheme, the present application provides a method for locating an error transaction and a related device, the method comprising: obtaining information and a transaction log of an error transaction sent by a transaction front-end program, the information of the error transaction including a log number and an error code of the error transaction, and the transaction log including log numbers of multiple transactions; determining a target transaction from multiple transactions, the log number of the target transaction being consistent with the log number of the error transaction, quickly locking the target transaction from numerous transactions, and effectively narrowing the scope of investigation; based on the acquired background transaction code of the target transaction, searching the transaction background program corresponding to the target transaction from a preset master control transaction table, and judging whether there is a collaborative request corresponding to the target transaction, the background transaction code of the target transaction being consistent with the background transaction code of the transaction background program and the background transaction code of the collaborative request respectively; if the transaction background program is a centralized transaction background program, then based on the error code, locating the method name of the error transaction in the local service of the centralized transaction background program; if the transaction background program is a distributed transaction background program, and there is no collaborative request corresponding to the target transaction, then based on the error code, locating the method name of the error transaction in the local service of the distributed transaction background program. Different error location strategies are designed for the centralized and distributed transaction backend program architectures, which improves the efficiency and accuracy of locating error transactions. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.
[0044] Figure 1 A flowchart of a method for locating an error transaction provided in an embodiment of the present application;
[0045] Figure 2 A schematic diagram of the structure of a positioning device for reporting an error transaction provided in an embodiment of the present application;
[0046] Figure 3 A schematic diagram of the hardware structure of a positioning device for reporting an error transaction provided in an embodiment of the present application. DETAILED DESCRIPTION
[0047] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.
[0048] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.
[0049] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.
[0050] In order to improve the efficiency and accuracy of locating error transactions, the present application provides a method for locating error transactions. The method for locating error transactions provided by the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.
[0051] Please see attached Figure 1 , Figure 1 A flowchart of a method for locating an error transaction provided in an embodiment of the present application. The method may include the following steps:
[0052] Step S101: Acquire the information of the error transaction and the transaction log sent by the transaction front-end program. The information of the error transaction includes the log number and error code of the error transaction. The transaction log includes the log numbers of multiple transactions.
[0053] In this application, when a transaction front-end program (i.e., the interface or system with which the user directly interacts) encounters an error during the execution of a transaction, a series of information related to the error transaction will be generated, which usually includes the log number and error code of the error transaction.
[0054] It should be noted that the log number is an identifier generated when each transaction is executed. It is used to track and locate specific transaction records in the transaction log. The log number can be used to quickly find log entries related to the transaction, thereby understanding the execution status of the transaction and the context in which the error occurred.
[0055] An error code is a unique code assigned to each possible error condition. When a transaction fails, an error code is generated that indicates the type and cause of the error. Error codes are often associated with specific error messages that provide more details about the cause of the error.
[0056] The transaction log is a log file used by the transaction front-end program to record all transaction activities. It contains information such as the log number, operation time, operator identification, back-end transaction code, and coordination request for each transaction.
[0057] Step S102: Determine a target transaction from multiple transactions, where the log number of the target transaction is consistent with the log number of the error transaction.
[0058] In the present application, based on the log numbers of multiple transactions, a candidate transaction that is consistent with the log number of the error-reporting transaction is determined from multiple transactions. If the number of candidate transactions is 1, the candidate transaction is used as the target transaction. If the number of candidate transactions is greater than 1, the target transaction is determined from the candidate transactions based on the obtained operation time and operator identification of the candidate transactions, the operation time of the target transaction is consistent with the operation time of the candidate transaction, and the operator identification of the target transaction is consistent with the operator identification of the candidate transaction.
[0059] In this application, when the log number of the error transaction is received, the transaction log is scanned to find all transaction records with the same log number, which are considered candidate transactions because they are related to the error transaction. If the number of candidate transactions is 1, that is, there is only one transaction that matches the log number of the error transaction, then this transaction is directly determined as the target transaction. If the number of candidate transactions is greater than 1, that is, there are multiple transactions that match the log number of the error transaction, then additional information is needed for further analysis to determine the target transaction.
[0060] Specifically, errors usually occur at a specific time point. The operation time of candidate transactions can be compared, and the transaction that is consistent with or closest to the time of the error transaction can be selected as the target transaction.
[0061] The operator ID is used to identify the user or system entity that executes the transaction. The same operator ID increases the possibility of correlation between the transaction and the error transaction. The operator ID of the target transaction can be compared with the operator ID of the candidate transaction, and the candidate transaction with the same operator as the candidate transaction can be selected as the target transaction.
[0062] If a specific target transaction is still not clear, other identifying information can be used to assist in determining the target transaction, such as: Transaction type: If the error transaction belongs to a specific transaction type (such as transfer, payment, inquiry, etc.), then the candidate transactions with the same transaction type can be prioritized. Transaction amount: If the error transaction involves a specific amount, the amount of the candidate transaction can be compared to see if it is consistent or similar to the error transaction. This is especially important in systems involving financial transactions, because incorrect amounts are one of the common causes of errors. Transaction status: If the status of the error transaction is known, candidate transactions with the same or similar status can be prioritized.
[0063] Step S103: Based on the acquired background transaction code of the target transaction, the transaction background program corresponding to the target transaction is searched from the preset master control transaction table, and it is determined whether there is a collaboration request corresponding to the target transaction.
[0064] It should be noted that the background transaction code of the target transaction is respectively consistent with the background transaction code of the transaction background program and the background transaction code of the collaborative request.
[0065] In this application, a field or routing configuration similar to the "background transaction code" of the target transaction is searched in the transaction log, and the value of the field is recorded. This value is the backstage transaction code of the target transaction. The backstage transaction code is the unique identifier of the transaction. The backstage transaction code of the target transaction can be sent to the preset master control transaction table for comparison. The master control transaction table is a database or data table containing all executed transactions and their corresponding background programs and collaborative requests. The transaction background program corresponding to the target transaction can be determined by comparison. This is achieved by comparing the backstage transaction code with the backstage transaction code stored in the master control transaction table.
[0066] The transaction backend program corresponding to the target transaction can be a centralized transaction backend program (usually located under the cloud) or a distributed transaction backend program (usually located on the cloud), which can help developers quickly locate the system environment where the problem occurs.
[0067] In addition to searching for the transaction backend program, it is also necessary to determine whether there is a collaborative request corresponding to the target transaction. A collaborative request refers to a request that may need to interact with other programs or services during the transaction processing. In the master control transaction table, check whether there is a collaborative request backend transaction code that is consistent with the backend transaction code of the target transaction. If there is a collaborative request backend transaction code that is consistent with the backend transaction code of the target transaction, it means that there is a collaborative request corresponding to the target transaction.
[0068] Collaborative analysis refers to querying the routing direction of the error transaction in the master control table based on the background transaction code, operation time and log number to be checked.
[0069] In the case where the transaction backend program is a centralized transaction backend program, step S104 is executed.
[0070] Step S104: Based on the error code, locate the method name of the error transaction in the local service of the centralized transaction background program.
[0071] In this application, when a transaction request is sent to a centralized transaction backend program (usually a service or system that handles a large number of transaction requests, running on an independent server or host) through some means (such as API calls, message queues, etc.), if an error occurs during the transaction processing, the backend program will return an error code and possible error information. These errors are usually caused by code logic problems, data inconsistency, insufficient resources, etc.
[0072] Centralized trading backend programs usually have local services (or local code logic) that are responsible for processing trading requests and generating responses. These local services can be used to further locate errors. Jacoco is an open source code coverage tool that monitors code execution and helps developers understand which codes have been executed and which have not been executed. In this step, the Jacoco monitoring tool can be used to monitor the execution of the code in real time, query the range of lines covered by the code increment, and combine the error code and other information of the error transaction to lock the specific line of code and method class name where the error occurred. Once the method name where the error occurred is determined, this information can be assigned to the corresponding development colleague for problem troubleshooting and repair.
[0073] In actual applications, this process can help the development team quickly locate and resolve errors in the trading backend program, improving the stability and reliability of the system. By using tools such as Jacoco, code quality and test coverage can also be improved, reducing the occurrence of potential errors.
[0074] When the transaction backend program is a distributed transaction backend program and there is no collaboration request corresponding to the target transaction, step S105 is executed.
[0075] Step S105: Based on the error code, locate the method name of the error transaction in the local service of the distributed transaction background program.
[0076] In a distributed system, the trading backend is usually composed of multiple services, which communicate with each other through the network to complete the transaction processing. When a transaction request is sent to a distributed backend, it may be broken down into multiple subtasks and executed on different services. If an error occurs during the execution, the backend will return an error code and possible error information.
[0077] In this application, when the transaction backend is a distributed transaction backend, the transaction request may trigger a collaborative request with other services. Therefore, it is necessary to check whether there is a collaborative request corresponding to the target transaction in the master control log table (or other similar logging system). If there is no collaborative request, it means that the transaction is processed by a single service (ie, a local service) rather than being completed by multiple services in collaboration. In this case, the cause of the error usually needs to be located in the local service of the distributed transaction backend, because the error may occur in the local code logic.
[0078] Distributed trading backend programs also usually have local services (or local code logic), which are responsible for processing trading requests and generating responses. These local services can be used to further locate errors. Jacoco is an open source code coverage tool that can monitor the execution of code and help developers understand which codes have been executed and which have not been executed. In this step, the Jacoco monitoring tool can be used to monitor the execution of the code in real time, query the range of lines covered by the code increment, and combine the error code and other information of the error transaction to lock the specific line of code and method class name where the error occurred. Once the method name where the error occurred is determined, this information can be assigned to the corresponding development colleague for problem troubleshooting and repair.
[0079] Furthermore, based on the above method, the following steps may also be included:
[0080] When the transaction backend program is a distributed transaction backend program and there is a collaboration request corresponding to the target transaction, step S106 is executed.
[0081] Step S106: Obtain the collaborative program corresponding to the collaborative request.
[0082] In this application, if there are collaborative requests corresponding to the target transaction, it is necessary to obtain the collaborative programs corresponding to these collaborative requests. Collaborative programs refer to services or components responsible for processing collaborative requests. These collaborative programs may be centralized transaction backend programs, remote service programs, or other types of distributed services. The information of collaborative programs can be used to further analyze the processing of collaborative requests and any factors that may cause errors.
[0083] When the collaborative program is a centralized transaction background program, step S107 is executed.
[0084] Step S107: Based on the error code, locate the method name of the error transaction in the local service of the centralized transaction background program.
[0085] In a distributed transaction system, transactions may flow between different services or components, which may be deployed in the cloud (such as public cloud, private cloud, etc.) or locally (such as the data center within the enterprise). When transactions flow from the cloud to the local for processing, it can be called a "cloud-to-cloud" scenario.
[0086] If the collaborative program is a centralized trading background program, that is, the transaction request is initially processed by the distributed trading background program on the cloud, but is then forwarded to the centralized trading background program under the cloud for processing, a scenario of transferring from the cloud to the cloud occurs. In this process, an error occurs, and the error information is usually fed back by the centralized background program. Therefore, the information of the target transaction is located in the local service of the centralized trading background program.
[0087] Centralized trading backend programs usually have local services (or local code logic) that are responsible for processing trading requests and generating responses. These local services can be used to further locate errors. Jacoco is an open source code coverage tool that monitors code execution and helps developers understand which codes have been executed and which have not been executed. In this step, the Jacoco monitoring tool can be used to monitor the execution of the code in real time, query the range of lines covered by the code increment, and combine the error code and other information of the error transaction to lock the specific line of code and method class name where the error occurred. Once the method name where the error occurred is determined, this information can be assigned to the corresponding development colleague for problem troubleshooting and repair.
[0088] When the collaborative program is a remote service program, step S108 is executed.
[0089] Step S108: Based on the type of the error code obtained, locate the method name of the error-reporting transaction in the distributed transaction background program.
[0090] If the collaborative program is a remote service program, it means that the transaction request is forwarded to one or more remote services for processing, and a scenario of cloud-to-remote processing occurs, that is, the transaction is forwarded to other distributed remote service programs on the cloud for processing. If an error occurs in this process, the error information will be fed back by the distributed background program and include the service code returned by the remote service program. The method name of locating the error transaction in the remote or local distributed transaction background program is determined based on the type of error code obtained by the service code.
[0091] In the present application, if the type of the error code obtained is the first preset type, then based on the error code, the method name of the error transaction is located in the local service program of the distributed transaction background program. If the type of the error code obtained is the second preset type, then based on the error code, the method name of the error transaction is located in the remote service program of the distributed transaction background program.
[0092] Specifically, the first preset type indicates that the error occurs in the local service program of the distributed trading background program. This type of error is usually caused by code logic errors, data processing errors, or resource access errors in the local service program. When this type of error is detected, the specific error reporting method name will be located in the local service program according to the error code, and the relevant information will be fed back to the development team for repair.
[0093] Distributed trading backend programs usually have local services (or local code logic) that are responsible for processing trading requests and generating responses. These local services can be used to further locate errors. Jacoco is an open source code coverage tool that monitors code execution and helps developers understand which codes have been executed and which have not been executed. In this step, you can use the Jacoco monitoring tool to monitor code execution in real time, query the range of lines covered by the code increment, and combine the error code and other information of the error transaction to lock the specific line of code and method class name where the error occurred. Once the method name where the error occurred is determined, this information can be assigned to the corresponding development colleague for problem troubleshooting and repair.
[0094] The second preset type indicates that the error occurs in the remote service program of the distributed trading background program. This type of error is usually caused by code logic errors, service anomalies, network communication failures, or insufficient resources in the remote service program. When this type of error is detected, the specific error reporting method name will be located in the remote service program according to the error code, and it may be necessary to connect and coordinate with the development team of the remote service program to solve the problem.
[0095] Distributed trading backend programs also usually have remote services (or local code logic) that are responsible for processing trading requests and generating responses. These remote services can be used to further locate errors. Jacoco is an open source code coverage tool that monitors code execution and helps developers understand which codes have been executed and which have not been executed. In this step, the Jacoco monitoring tool can be used to monitor the execution of the code in real time, query the range of lines covered by the code increment, and combine the error code and other information of the error transaction to lock the specific line of code and method class name where the error occurred. Once the method name where the error occurred is determined, this information can be assigned to the corresponding development colleagues and the development team of the remote service program for problem troubleshooting and repair.
[0096] In summary, the present application provides a method for locating an error transaction, the method comprising: obtaining the information of the error transaction and the transaction log sent by the transaction front-end program, the information of the error transaction including the log number and the error code of the error transaction, and the transaction log including the log numbers of multiple transactions. Determine the target transaction from multiple transactions, the log number of the target transaction is consistent with the log number of the error transaction. Quickly lock the target transaction from many transactions, effectively narrow the scope of investigation, based on the background transaction code of the acquired target transaction, find the transaction background program corresponding to the target transaction from the preset master control transaction table, and judge whether there is a collaborative request corresponding to the target transaction, the background transaction code of the target transaction is respectively consistent with the background transaction code of the transaction background program and the background transaction code of the collaborative request. If the transaction background program is a centralized transaction background program, then based on the error code, locate the method name of the error transaction in the local service of the centralized transaction background program. If the transaction background program is a distributed transaction background program, and there is no collaborative request corresponding to the target transaction, then based on the error code, locate the method name of the error transaction in the local service of the distributed transaction background program. Different error location strategies are designed for the centralized and distributed transaction backend program architectures, which improves the efficiency and accuracy of locating error transactions.
[0097] A method for locating an error transaction provided by an embodiment of the present application is introduced above, and a device for executing the above-mentioned method for locating an error transaction will be introduced below.
[0098] See also Figure 2 , Figure 2 A schematic diagram of the structure of a positioning device for reporting an error transaction provided in an embodiment of the present application. Figure 2 As shown, the positioning device for the error transaction includes:
[0099] The acquisition unit 11 is used to acquire the information of the error transaction and the transaction log sent by the transaction front-end program, wherein the information of the error transaction includes the log number and error code of the error transaction, and the transaction log includes the log numbers of multiple transactions.
[0100] The determining unit 12 is used to determine a target transaction from the multiple transactions, wherein the log number of the target transaction is consistent with the log number of the error transaction.
[0101] The search unit 13 is used to search for the transaction background program corresponding to the target transaction from the preset master control transaction table based on the background transaction code of the target transaction obtained, and to determine whether there is a collaboration request corresponding to the target transaction, and the background transaction code of the target transaction is respectively consistent with the background transaction code of the transaction background program and the background transaction code of the collaboration request.
[0102] The first locating unit 14 is configured to locate the method name of the error-reporting transaction in the local service of the centralized transaction background program based on the error code if the transaction background program is a centralized transaction background program.
[0103] The second locating unit 15 is used to locate the method name of the error-reporting transaction in the local service of the distributed transaction background program based on the error code if the transaction background program is a distributed transaction background program and there is no collaborative request corresponding to the target transaction.
[0104] In a possible implementation, the determining unit 12 includes:
[0105] The first determining subunit is used to determine, based on the log numbers of the multiple transactions, a candidate transaction that is consistent with the log number of the error reporting transaction from the multiple transactions.
[0106] The second determining subunit is configured to use the candidate transaction as the target transaction if the number of the candidate transactions is 1.
[0107] The third determination subunit is used to determine a target transaction from the candidate transactions based on the acquired operation time and operator identifier of the candidate transactions if the number of the candidate transactions is greater than 1, wherein the operation time of the target transaction is consistent with the operation time of the candidate transactions, and the operator identifier of the target transaction is consistent with the operator identifier of the candidate transactions.
[0108] In a possible implementation, the device further includes:
[0109] The acquisition subunit is used for acquiring the collaborative program corresponding to the collaborative request if the transaction background program is a distributed transaction background program and there is a collaborative request corresponding to the target transaction.
[0110] The first positioning subunit is used to locate the method name of the error-reporting transaction in the local service of the centralized transaction background program based on the error code if the collaborative program is the centralized transaction background program.
[0111] The second positioning subunit is used to locate the method name of the error-reporting transaction in the distributed transaction background program based on the type of the acquired error code if the collaborative program is a remote service program.
[0112] In a possible implementation, the second positioning subunit includes:
[0113] The third positioning subunit is used to locate the method name of the error-reporting transaction in the local service program of the distributed transaction background program based on the error code if the type of the acquired error code is the first preset type.
[0114] The fourth positioning subunit is used to locate the method name of the error transaction in the remote service program of the distributed transaction background program based on the error code if the type of the acquired error code is the second preset type.
[0115] The present application also provides an electronic device in an embodiment. Figure 3 As shown, it shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 3 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0116] like Figure 3 As shown, the electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 to a random access memory (RAM) 303. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 303. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.
[0117] Typically, the following devices may be connected to the I / O interface 305: an input device 306 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 308 including, for example, a memory card, a hard disk, etc.; and a communication device 309. The communication device 309 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 3 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.
[0118] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any method for locating an error transaction provided in the embodiment of the present application.
[0119] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any method for locating an error transaction provided in an embodiment of the present application.
[0120] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.
[0121] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.
[0122] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.
[0123] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.
Claims
1. A method for locating an error transaction, characterized in that: include: Acquire the information of the error transaction and the transaction log sent by the transaction front-end program, wherein the information of the error transaction includes the log number and error code of the error transaction, and the transaction log includes the log numbers of multiple transactions; Determine a target transaction from the multiple transactions, wherein the log number of the target transaction is consistent with the log number of the error transaction; Based on the acquired background transaction code of the target transaction, searching the transaction background program corresponding to the target transaction from the preset master control transaction table, and judging whether there is a coordination request corresponding to the target transaction, the background transaction code of the target transaction is respectively consistent with the background transaction code of the transaction background program and the background transaction code of the coordination request; If the transaction backend program is a centralized transaction backend program, then based on the error code, locate the method name of the error reporting transaction in the local service of the centralized transaction backend program; If the transaction backend program is a distributed transaction backend program and there is no collaborative request corresponding to the target transaction, then based on the error code, the method name of the error reporting transaction is located in the local service of the distributed transaction backend program.
2. The method for locating an error transaction according to claim 1, characterized in that: The determining a target transaction from the multiple transactions comprises: Based on the log numbers of the multiple transactions, determining a candidate transaction from the multiple transactions that is consistent with the log number of the error-reporting transaction; If the number of the candidate transactions is 1, the candidate transaction is used as the target transaction; If the number of the candidate transactions is greater than 1, a target transaction is determined from the candidate transactions based on the acquired operation time and operator identification of the candidate transactions, the operation time of the target transaction is consistent with the operation time of the candidate transactions, and the operator identification of the target transaction is consistent with the operator identification of the candidate transactions.
3. The method for locating an error transaction according to claim 1, characterized in that: The method further comprises: If the transaction backend program is a distributed transaction backend program and there is a collaborative request corresponding to the target transaction, then the collaborative program corresponding to the collaborative request is obtained; If the collaborative program is the centralized transaction background program, then based on the error code, locate the method name of the error reporting transaction in the local service of the centralized transaction background program; If the collaborative program is a remote service program, the method name of the error reporting transaction is located in the distributed transaction background program based on the type of the acquired error code.
4. The method for locating an error transaction according to claim 3, characterized in that: The method name of locating the error reporting transaction in the distributed transaction background program based on the acquired error code type includes: If the type of the error code obtained is a first preset type, locating the method name of the error reporting transaction in the local service program of the distributed transaction background program based on the error code; If the type of the error code obtained is the second preset type, then based on the error code, the method name of the error reporting transaction is located in the remote service program of the distributed transaction background program.
5. A device for locating an error transaction, characterized in that: include: An acquisition unit, used to acquire information of an error transaction and a transaction log sent by a transaction front-end program, wherein the information of the error transaction includes a log number and an error code of the error transaction, and the transaction log includes log numbers of multiple transactions; a determining unit, configured to determine a target transaction from the plurality of transactions, wherein the log number of the target transaction is consistent with the log number of the error reporting transaction; a search unit, configured to search for a transaction backend program corresponding to the target transaction from a preset master control transaction table based on the acquired backend transaction code of the target transaction, and determine whether there is a coordination request corresponding to the target transaction, wherein the backend transaction code of the target transaction is respectively consistent with the backend transaction code of the transaction backend program and the backend transaction code of the coordination request; A first locating unit, configured to locate the method name of the error-reporting transaction in a local service of the centralized transaction background program based on the error code if the transaction background program is a centralized transaction background program; The second positioning unit is used to locate the method name of the error transaction in the local service of the distributed transaction background program based on the error code if the transaction background program is a distributed transaction background program and there is no collaborative request corresponding to the target transaction.
6. The device for locating an error transaction according to claim 1, characterized in that: The determining unit comprises: A first determining subunit is configured to determine, based on the log numbers of the multiple transactions, a candidate transaction that is consistent with the log number of the error reporting transaction from the multiple transactions; a second determining subunit, configured to use the candidate transaction as the target transaction if the number of the candidate transactions is 1; The third determination subunit is used to determine a target transaction from the candidate transactions based on the acquired operation time and operator identifier of the candidate transactions if the number of the candidate transactions is greater than 1, wherein the operation time of the target transaction is consistent with the operation time of the candidate transactions, and the operator identifier of the target transaction is consistent with the operator identifier of the candidate transactions.
7. The device for locating an error transaction according to claim 1, characterized in that: The device also includes: an acquisition subunit, configured to acquire, if the transaction background program is a distributed transaction background program and there is a collaboration request corresponding to the target transaction, a collaboration program corresponding to the collaboration request; A first positioning subunit is used for locating the method name of the error-reporting transaction in the local service of the centralized transaction background program based on the error code if the collaborative program is the centralized transaction background program; The second positioning subunit is used to locate the method name of the error-reporting transaction in the distributed transaction background program based on the type of the acquired error code if the collaborative program is a remote service program.
8. A computer program product, characterized in that It includes computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device implements the method for locating an error transaction as described in any one of claims 1 to 4.
9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the method for locating an error transaction as described in any one of claims 1 to 4.
10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the method for locating an error transaction as described in any one of claims 1 to 4.