A method for compensating for abnormalities in third-party system interface docking

Abstract

The present invention discloses a method for compensating for anomalies in a third-party system interface docking, comprising entering interface information; inserting the entered interface information into a log record; parsing the interface information to execute a specific interface call; performing status analysis on the interface return result and updating the log record; and searching for failed log records to compensate for the anomaly. The present invention inserts log information before calling the interface to prevent the interface from being actually called but anomalies occur during the process, resulting in the record not being generated normally and the information being unable to be traced. The interface docking anomaly compensation method of the present invention can accurately know the process of the interface call, facilitate query and statistics, determine whether the interface call is synchronous or asynchronous by inputting parameters, quickly query the failed record, and automatically enter the parameter information according to the log record for interface retry, find the specified interface, and avoid the complex operation of data recovery.

Description

Technical Field

[0001] The present invention relates to an abnormality compensation method for third-party system interface docking, and belongs to the technical field of information processing. Background Art

[0002] With the rapid development of internet technology, software application systems are becoming increasingly diverse. Enterprises typically utilize multiple systems with diverse functions, often with overlapping business operations. When interfacing these systems, incomplete documentation of the process can lead to frequent buck-passing, and difficulty retrying interface calls after exceptions. Traditional approaches focus solely on the interface call itself, making it difficult to troubleshoot and repair data inconsistencies when they occur. Therefore, how to fully record the interface call process and quickly retry exceptions has become a pressing technical challenge. Summary of the Invention

[0003] The purpose of the present invention is to provide an exception compensation method for third-party system interface docking, which inserts log information before calling the interface to prevent the interface from being actually called but an exception occurs during the process, resulting in the record not being generated normally and the information being unable to be traced.

[0004] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0005] A method for compensating for anomalies in a third-party system interface connection, comprising:

[0006] Enter interface information;

[0007] Insert the entered interface information into the log record;

[0008] Parse the interface information and execute specific interface calls;

[0009] Perform status analysis on the results returned by the interface and update the log records;

[0010] Find the failure log record for exception compensation.

[0011] Furthermore, the input interface information includes: interface url and interface input parameters;

[0012] The interface input parameter includes at least one of the following:

[0013] The interface provides the manufacturer, interface system type, interface code, interface operation type, interface calling method, and interface input parameter string;

[0014] Among them, the interface calling mode includes synchronous mode and asynchronous mode.

[0015] Furthermore, it also includes returning the unique code of the log record after inserting the entered interface information into the log record.

[0016] Furthermore, if the interface calling mode is asynchronous, the calling interface is added to the thread pool for execution.

[0017] Furthermore, parsing the interface information and executing a specific interface call includes:

[0018] Identify the interface address to be called based on the interface operation type in the input parameter and execute the interface call.

[0019] Furthermore, parsing the interface information and executing a specific interface call includes:

[0020] Predefine and store interface codes that correspond one to one with interface addresses;

[0021] When executing an interface call, the storage file is queried to find the interface address corresponding to the interface code and make the call.

[0022] Furthermore, the state parsing of the interface return result and updating the log record includes:

[0023] Pre-write the interception code for the manufacturer in the input parameter according to the returned data format; the interception code is used to intercept the status of the execution interface call from the returned data;

[0024] According to the unique log number, update the status information of the interface call, exception information and complete data returned by the interface.

[0025] Furthermore, the search failure log records abnormal compensation, including:

[0026] For the records in the log record where the interface call status is failed, a graphical interface is used to display them, and the user can manually check to retry.

[0027] Furthermore, the search failure log records abnormal compensation, including:

[0028] Set the scheduled task to pull the log records of the interface call status as failed and retry.

[0029] Furthermore, it also includes,

[0030] The number of retries is recorded. When the number of retries reaches the preset limit, the record will not be retried.

[0031] The beneficial effects of the present invention are:

[0032] The interface docking exception compensation method of the present invention can accurately know the process of interface calling, facilitate query and statistics, and can determine whether the interface call is executed synchronously or asynchronously through the input parameter form. Failure records can be quickly queried, and the interface retry automatically enters the parameter information according to the log record to find the specified interface and avoid the complex operation of data recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 The present invention provides a flowchart of a method for compensating for anomalies in a third-party system interface connection. DETAILED DESCRIPTION

[0034] The present invention will be further described below. The following examples are only used to more clearly illustrate the technical solution of the present invention and are not intended to limit the scope of protection of the present invention.

[0035] The present invention provides a method for compensating for anomalies in a third-party system interface connection, comprising:

[0036] A method for compensating for anomalies in third-party interface docking, comprising the following steps:

[0037] Step 1: Enter the interface information to identify the interface address to be called; the interface information includes the interface URL and interface input parameters;

[0038] Step 2: Insert the entered interface information into the log record before calling the interface;

[0039] Step 3: parse the interface information and execute specific interface calls;

[0040] Step 4: Analyze the status of the interface return result and update the log record;

[0041] Step 5: Find the failed log records and retry manually or through scheduled tasks to achieve exception compensation.

[0042] Figure 1 This is a flowchart of a method for compensating for anomalies in a third-party system interface connection provided by a specific embodiment of the present invention. The specific implementation process of the method is as follows:

[0043] S10: Write interface call parameter information,

[0044] In order to accurately locate the interface to be called through the incoming information, the input parameters must include but are not limited to:

[0045] Interface providers include Kingdee, UFIDA, SAP, etc.

[0046] System type, such as ERP, WMS, QMS, etc.

[0047] Encoding and operation type, used to specifically locate the interface.

[0048] Synchronous or asynchronous: When calling a third-party API, if the API response time is long, choose asynchronous mode to avoid excessive lag and affect the user experience. Asynchronous mode: The call process is executed without waiting for the third-party system to return a result; synchronous mode: The call process needs to wait for the third-party system to return a result.

[0049] Interface input parameter string, used for input when calling the interface, and for backtracking or retrying after the call.

[0050] S20: Insert the above interface call parameter information into the log table,

[0051] Inserting log information is performed before calling an interface to prevent the interface from being called but encountering an exception during the call, resulting in the record not being generated properly and the information being lost. In this case, the unique code of the log record needs to be returned to update the log status information after the interface is executed.

[0052] It should be noted that this code is only used for unique identification and can be generated in any way, such as through the snowflake algorithm or UUID.

[0053] Furthermore, this step may also include:

[0054] S21: Determine whether the parameter content is asynchronous based on the input parameter content.

[0055] If the third-party interface response time is relatively long and the user does not need to wait for the interface to return the result or cannot accept a long response time, the asynchronous method can be selected. If the user can accept the response time, the synchronous method should be given priority, which can ensure the consistency of the final log information update.

[0056] S22: If it is asynchronous, the method calling the third-party interface will be added to the thread pool for execution.

[0057] The thread pool can reduce the consumption of each acquisition and termination of resources and improve resource utilization.

[0058] The specific parameters of the thread pool can be considered comprehensively based on server resource conditions, interface call frequency and other conditions. Do not configure the thread pool parameters too high at one time, which will affect the use of other business functions.

[0059] S30: Determine which manufacturer's interface needs to be called based on the input parameters, and execute the specific interface call.

[0060] Since each manufacturer provides different interface protocols and input parameters, the calling methods need to be written separately.

[0061] In this embodiment, a specific interface call is executed based on the interface type or code in the input parameter. The interface call has a specific interface address. The interfaces provided by the manufacturer can be roughly divided into two categories:

[0062] A. Determine the interface address based on the operation type

[0063] All business functions are saved using the same interface. Similarly, the interface addresses for other types of operations such as query and deletion are the same, but the parameters are different.

[0064] B. Irregular interface address

[0065] This type of interface is the most common. For customized interfaces, each business function provides a different interface address. In this case, you need to define a one-to-one mapping between interface codes and interface addresses. This information can be stored in a configuration file or database. When executing an interface call, you query this storage file to find the interface address corresponding to the interface code and make the call. Directly using the interface address as an input parameter is inconvenient for developers to memorize and write.

[0066] S40: Determine the return status and exception information based on the interface return result

[0067] The formats of data returned by different manufacturers are different. It is necessary to intercept the status of the interface call (such as success or failure) from the returned information. If it fails, the exception information needs to be obtained and recorded.

[0068] Of course, the return data formats provided by the same manufacturer may also vary. In this case, you need to add judgment and distinction in the code. For example, the save interface of manufacturer xx returns {"IsSuccess":"false","Message":"XXXXX"}, while the push interface returns {"Result": {"ResponseStatus": {"ErrorCode": 500,"IsSuccess": false,"Errors":[{"FieldName": "","Message": "XXXX","DIndex": 0}]}}}. Different return formats will cause problems in data parsing, but you cannot control the return style of the third-party system, so this problem cannot be avoided.

[0069] It should be known that the data returned by each manufacturer will include the call status; different manufacturers need to write different interception codes because the returned data formats are different.

[0070] S41: Update the log record according to the intercepted information

[0071] Based on the unique log number, the interface call status information, exception information, and original interface return value (the complete data returned by the third-party interface) are updated. At this point, the manufacturer, system type, code, and operation type information of the interface in the log record can be provided to accurately locate the corresponding interface address, the status returned by the interface call in the log record, and the cause of the exception. This provides data support for tracing or retrying.

[0072] S50: For the records in the log record where the interface call status is failed, the process returns to step S10 and retry to compensate for the exception.

[0073] Two approaches can be considered:

[0074] A. The graphical interface is displayed, and the user manually selects to retry

[0075] The advantage of this method is that users can accurately execute the records that should be called again. If the failed record has been recovered in a third-party system, consider setting the record to success or adding an ignore mark so that users do not retry this record in subsequent operations.

[0076] B. Pull failed records through scheduled tasks and retry

[0077] This approach has the advantage of effectively reducing user operations and automatically handling exceptions. However, if the user has already performed data repairs in a third-party system, this can cause duplication of business processing. Furthermore, records may fail for a period of time or permanently, causing the system to continuously retry data that has been lost, which can easily lead to excessive system load. Therefore, the number of retries is typically recorded. Once a certain threshold is reached, the record is no longer retried.

[0078] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0080] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered by the scope of protection of the claims of the present invention.

Claims

1. A method for compensating for abnormalities in third-party system interface docking, characterized in that: include: Enter the interface information, including: interface URL and interface input parameters; The interface input parameter includes at least one of the following: interface provider, interface system type, interface code, interface operation type, interface call mode, interface input parameter string; wherein the interface call mode includes synchronous mode and asynchronous mode; Insert the entered interface information into the log record and return the unique code of the log record; Parse the interface information and execute specific interface calls; Parse the status of the interface return result and update the log record, including: pre-writing the interception code according to the returned data format for the manufacturer in the input parameter; the interception code is used to intercept the status of the interface call execution from the returned data; according to the unique log number, update the interface call status information, exception information and complete data returned by the interface in the log; Find the failure log record for exception compensation.

2. The method for compensating for abnormalities in third-party system interface docking according to claim 1, characterized in that: It also includes adding the calling interface to the thread pool for execution if the interface calling mode is asynchronous.

3. The method for compensating for abnormalities in third-party system interface docking according to claim 1, characterized in that: The parsing of the interface information and executing a specific interface call includes: Identify the interface address to be called based on the interface operation type in the input parameter and execute the interface call.

4. The method for compensating for abnormalities in third-party system interface docking according to claim 1, characterized in that: The parsing of the interface information and executing a specific interface call includes: Predefine and store interface codes that correspond one to one with interface addresses; When executing an interface call, the storage file is queried to find the interface address corresponding to the interface code and make the call.

5. The method for compensating for abnormalities in third-party system interface docking according to claim 1, characterized in that: The search failure log records abnormal compensation, including: Records in the log record with the interface call status as failed are displayed using a graphical interface, and the user can manually check to retry.

6. The method for compensating for abnormalities in third-party system interface docking according to claim 1, characterized in that: The search failure log records abnormal compensation, including: Set the scheduled task to pull the log records of the interface call status as failed and retry.

7. The method for compensating for abnormalities in third-party system interface docking according to claim 6, characterized in that: Also includes, The number of retries is recorded. When the number of retries reaches the preset limit, the record will not be retried.

Images