CN111831542A - API application debugging method and device, storage medium - Google Patents

Abstract

The embodiments of the present application disclose an API application debugging method and device, and a storage medium, which belong to the technical field of networks. The method includes: obtaining a target commissioning log, where the target commissioning log is a commissioning log generated during the commissioning of a target API application, and the target API application is composed of at least one API service; and from the target commissioning log, Obtain the target call log of the target API service. The target API service is any API service that is called in the process of debugging the target API application; obtain key information in the target call log; present key information. The embodiments of the present application help to solve the problem of low debugging efficiency of API applications, and help to improve the debugging efficiency of API applications. The embodiments of the present application are used for API application debugging.

Description

API application debugging method and device, storage medium

technical field

The embodiments of the present application relate to the field of network technologies, and in particular, to an application programming interface (application programming interface, API) application debugging method and device, and a storage medium.

Background technique

In the Internet cloudification scenario, API orchestration refers to the process of using professional API management tools to orchestrate one or more API services into API applications. Among them, the API service refers to the functional unit that meets the specific requirements, and the API services arranged by the API have a certain order. After an API application is orchestrated, it is usually necessary to debug the API application.

At present, the MuleSoft API orchestration tool is usually used to debug API applications. The commissioning process includes: the MuleSoft API orchestration tool generates an API model according to the model code edited by the tester, and according to the API model, interacts with the API gateway to call the API service in the API application to commission the API application. During the process, the API gateway generates a commissioning log, and the MuleSoft API orchestration tool obtains the commissioning log from the API gateway and displays the commissioning log in the form of text, so that the tester can manually analyze the commissioning log to determine the commissioning log. key information of the test log (such as input information of the called API service, output information of the called API service, request information forwarded by the called API service, response information forwarded by the called API service, exception information, etc.), And determine the problem point of API layout according to the key information of the commissioning log.

However, due to the low efficiency of manual analysis, the debugging efficiency of API applications is low.

SUMMARY OF THE INVENTION

The embodiments of the present application provide an API application debugging method, device, and storage medium, which help to improve the API application debugging efficiency. The technical solution is as follows:

In a first aspect, an API application debugging method is provided, the method includes:

Obtain the target commissioning log. The target commissioning log is the commissioning log generated during the commissioning of the target API application. The target API application is composed of at least one API service. From the target commissioning log, obtain the target API service. The target call log of the target API service is any API service that is called in the process of debugging the target API application; obtains the key information in the target call log; presents the key information.

The solution provided by the embodiment of the present application can acquire and present key information in the call log without manual analysis, thereby helping to improve the debugging efficiency of the API application.

Optionally, obtaining the target call log of the target API service from the target debugging log, including: obtaining the target call log from the association relationship between the called API service and the call log, and the difference between the called API service and the call log. Associations are established based on target commissioning logs.

In the solution provided by the embodiment of the present application, since the target call log can be obtained from the association relationship between the called API service and the call log, it is convenient to quickly obtain the target call log.

Optionally, before acquiring the target call log from the association relationship between the called API service and the call log, the method further includes: determining the calling sequence of the API service in the target API application according to the target debugging log; In the commissioning log, the call log of each called API service is obtained; according to each called API service and the corresponding call log, the relationship between the called API service and the call log is established.

In the solution provided by the embodiment of the present application, before acquiring the target invocation log, the association relationship between the invoked API service and the invocation log is first established, so that the fast acquisition of the target invocation log can be facilitated.

Optionally, obtaining the call log of each called API service from the target commissioning log includes: determining the characteristic label of each called API service, where the characteristic label includes the identifier of the called API service and the application to the target API. The trace instance identifier for debugging; according to the feature tag of each called API service, the call log of each called API service is extracted from the target debugging log.

In the solution provided by the embodiments of the present application, since the call log of each called API service can be extracted from the target commissioning log in the form of a feature tag, it is convenient to extract the call log of each called API service.

Optionally, before acquiring the target call log of the target API service from the target debugging log, the method further includes:

Determine the calling sequence of API services in the target API application according to the target commissioning log;

According to the calling sequence, the API service calling track is presented. The API service calling track at least includes the picture element of the called API service and the trajectory line connecting the picture elements of at least two called API services according to the calling sequence. The picture element of the API service indicates API service;

Obtain the target invocation log of the target API service from the target commissioning log, including: when the acquisition instruction triggered by the primitive of the target API service is detected, obtain the target invocation log of the target API service from the target commissioning log.

In the solution provided by the embodiment of the present application, since the API service call trace can be displayed, it is convenient for the commissioning personnel to know the calling process and the calling branch of the commissioning process, and the visualization effect of API application commissioning is better. Further, presenting the API service call trace can facilitate the tester to obtain the commissioning log (for example, the target call log) of the desired API service.

Optionally, before presenting the API service calling trace according to the calling sequence, the method further includes:

Determine the last called API service according to the calling sequence; determine the ending API service of the target API application according to the API service arrangement sequence of the target API application; determine whether the last API service called is the ending API service of the target API application; When the last API service called is the end API service of the target API application, determine the API service call track as a normal track; when the last API service called is not the end API service of the target API application, determine the API service call track is an abnormal trajectory.

In the solution provided by the embodiments of the present application, since the normal trajectory is different from the abnormal trajectory, it is convenient to present the API service invocation trajectory by determining whether the API service invocation trajectory is a normal trajectory before presenting the API service invocation trajectory.

Optionally, according to the calling sequence, the API service call trace is presented, including:

When the API service calling track is a normal track, the API service calling track is presented according to the calling sequence. The API service calling track includes the graphic elements of the called API service, and the graphic elements that connect all the called API services according to the calling sequence. track line;

When the API service calling track is an abnormal track, the API service calling track is presented according to the calling sequence and the API service arrangement order. The API service calling track includes the graphics elements of the called API services and the graphics elements of the API services that have not been called. The trace lines that connect the primitives of all called API services in sequence, the choreography lines that connect the primitives of all API services that have not been called according to the API service orchestration order, and the graphs that connect the called API services in the API service orchestration order The arrangement line of the primitives and the primitives of the API services that have not been called. The invoked API services include the normal API services and the abnormal API services, the primitives that call the normal API services, and the primitives that call the abnormal API services. And the rendering form of the primitives of the API service that is not called is different.

In the solution provided by the embodiments of the present application, since the graphic elements for calling normal API services, the graphic elements for calling abnormal API services, and the graphic elements for uncalled API services can be presented in different forms, it is convenient for testers to quickly determine Calls of each API service.

Optionally, determining the calling sequence of the API services in the target API application according to the target commissioning log includes: analyzing the target commissioning log in a regular manner to determine the calling sequence of the API services called in the target API application.

Optionally, obtain a target commissioning log, where the target commissioning log is a commissioning log generated during commissioning of the target API application, including: sending a commissioning request to the API gateway, and the commissioning request carries the API application identifier and the first A timestamp, the API application identifier indicates the target API application, the first timestamp is the start timestamp of the target API application commissioning; the commissioning response sent by the API gateway is received, and the commissioning response includes the target commissioning log, and the target commissioning log is A commissioning log generated by the API gateway for the target API application between the second timestamp and the first timestamp, where the second timestamp is the end timestamp of the target API application commissioning.

In the solution provided by the embodiment of this application, sending a commissioning request to the API gateway can trigger the commissioning process, and at the end of the commissioning, a commissioning response sent by the API gateway can be received, and the commissioning response includes the target commissioning log. The target commissioning log can be obtained at the same time, and the target commissioning log can be obtained in a timely manner, which is convenient for timely analysis and timely detection of problems.

Optionally, before acquiring the target commissioning log, the method further includes: acquiring a commissioning execution result, where the commissioning execution result is an execution result of commissioning the target API application; and presenting the commissioning execution result;

Obtaining the target commissioning log includes: when an analysis command triggered according to the commissioning execution result is received, obtaining the target commissioning log.

In the solution provided by the embodiments of the present application, since the commissioning execution result can be displayed, the tester can be informed of the commissioning execution result; in addition, since the target commissioning log is obtained when an analysis command triggered according to the commissioning execution result is received, the target commissioning log is obtained. The analysis of the target commissioning log can be triggered by testers, which improves the controllability of the commissioning process.

In a second aspect, an API application debugging apparatus is provided. The API application debugging apparatus includes at least one module, and the at least one module is used to implement the API application provided in the first aspect or any optional manner of the first aspect. debugging method.

A third aspect provides an API application debugging apparatus, the API application debugging apparatus includes: a processor, a communication interface, a memory, and a bus, where the processor is configured to execute instructions stored in the memory to implement the first aspect or the first The API application debugging method provided in any optional manner of the aspect.

In a fourth aspect, a computer-readable storage medium is provided, and instructions are stored in the computer-readable storage medium, and when the instructions are executed on a processing component of a computer, the processing component executes the first aspect or any one of the first aspects. The API application debugging method provided by the optional method.

In a fifth aspect, a computer program product containing instructions is provided, when the computer program product runs on a computer, the computer program product enables the computer to execute the API application debugging method provided in the first aspect or any optional manner of the first aspect.

A sixth aspect provides a chip, the chip includes a programmable logic circuit and/or program instructions, and is used to implement the first aspect or the API application debugging method provided in any optional manner of the first aspect when the chip is running .

For the beneficial effects of the above-mentioned second to sixth aspects, reference may be made to the first aspect, which will not be repeated here.

Description of drawings

FIG. 1 is a schematic diagram of an implementation environment involved in an embodiment of the present application;

FIG. 2 is a method flowchart of an API application debugging method provided by an embodiment of the present application;

3 is a schematic diagram of an API service arrangement sequence in a target API application provided by an embodiment of the present application;

FIG. 4 is a schematic diagram of displaying a commissioning execution result according to an embodiment of the present application;

5 is a flowchart of a method for obtaining a call log of a called API service provided by an embodiment of the present application;

6 is a schematic diagram of an API service arrangement sequence and an API service calling track provided by an embodiment of the present application;

7 is a schematic diagram of another API service arrangement sequence and API service calling track provided by an embodiment of the present application;

8 is a flowchart of a method for determining whether an API service call trajectory is a normal trajectory provided by an embodiment of the present application;

FIG. 9 is a schematic diagram of a logical structure of an API application debugging apparatus provided by an embodiment of the present application;

FIG. 10 is a schematic diagram of a logical structure of another API application debugging apparatus provided by an embodiment of the present application;

FIG. 11 is a schematic diagram of a physical structure of an API application debugging apparatus provided by an embodiment of the present application.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the embodiments of the present application, and together with the description serve to explain the principles of the embodiments of the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

With the popularization of Internet cloudification scenarios, more and more cloudified sites integrate their own resources (such as API services) and open them to developers through API gateways to provide high-performance and highly available APIs for cloud computing users. baby sitting program. Among them, API Gateway is a gateway for fully managed API services that enables developers to easily create, publish, maintain and secure API services of any scale.

In the Internet cloudification scenario, API orchestration refers to the process of using professional API management tools to orchestrate one or more API services into API applications. API orchestration does not involve programming, and only calls and/or compose API services through configuration and/or mapping on the cloud platform. Among them, API services refer to functional units that meet specific requirements. In API applications, API services can be sequential (the output of the previous API service is the input of the next API service), parallel (two API services in parallel) or conditional jump (jump from one API service when conditions are met) to another API service). Whether an API application is orchestrated by API services, and how many API services are orchestrated by an API application, are invisible to users (including testers and actual users). Therefore, through API orchestration, users do not need to care about the complex configuration process of API applications.

After an API is orchestrated to form an API application, it is usually necessary to debug the API application. However, in actual scenarios, when there is a problem in the commissioning process, the traditional commissioning method cannot intuitively locate the problem point of API layout. Testers need to view the commissioning log and find the problem point of API layout according to the commissioning log. As a result, API application debugging takes a long time and is inefficient.

At present, API applications are usually debugged using the MuleSoft API orchestration tool. The MuleSoft API orchestration tool is a graphical orchestration tool based on an offline integrated development environment. It allows users to use graphical development business processes and provides testers with Commissioning execution result (normal or abnormal commissioning). When the debugging is abnormal, the MuleSoft API Orchestration Tool can generate an API model according to the code written by the tester, and according to the API model, send a specific request to the API gateway to obtain the debugging log, and display the debugging log in the form of text. Through the analysis of the commissioning log, the key information of the commissioning log is determined, and the problem point of the API layout is determined according to the key information of the commissioning log.

However, the current solution requires manual analysis of the commissioning logs, and the commissioning of API applications is time-consuming and inefficient; the current solution only provides the testers with the commissioning execution results and the commissioning logs, and cannot visually provide the testers with the commissioning process The call process and call branch of the API service (that is, the API service call trace cannot be provided to the tester), and the visualization effect is poor; the current solution displays the debugging log in the form of text, and the tester cannot quickly view the API layout. The problem is that the user experience is low.

The embodiments of the present application provide an API application debugging method, device, and storage medium, which can acquire and present key information in a debugging log without manual analysis, which helps reduce the time consuming of API application debugging and improves API application performance. It can improve the commissioning efficiency and improve the user experience; and can obtain and display the API service call trace during the API application commissioning process, and the visualization effect of API application commissioning is better. The solutions of the embodiments of the present application are described in detail below.

Please refer to FIG. 1 , which shows a schematic diagram of an implementation environment involved in an embodiment of the present application. The implementation environment includes an API application debugging device 01 and an API gateway 02 . The API application debugging device 01 and the API gateway 02 can pass through the Wired network or wireless network communication connection, wireless network may include but not limited to: wireless fidelity (wireless fidelity, WIFI), bluetooth, infrared, zigbee (zigbee) or data and so on.

The API application debugging device 01 may be a terminal or a debugging device or a debugging tool running on the terminal. The terminal can be a smart phone, a tablet computer, or a desktop computer. The API gateway 02 may be one gateway, or a gateway cluster composed of several gateways. For example, the API gateway 02 may include a gateway deployed in a test environment (eg, a sandbox test environment) and a gateway deployed in a production environment (eg, a real application environment of an API application).

The API application debugging device 01 is configured to deploy the API application obtained by the orchestration into the API gateway 02, and to debug the API application by interacting with the API gateway 02. The API gateway 02 is used to generate a commissioning log and provide the commissioning log to the API application commissioning device 01 . In addition, the API gateway 02 is also used to manage the life cycle of the API application.

In some implementation scenarios, the API application debugging apparatus 01 is also called an API service tracking system. The API service tracking system may include an API development unit and an API debugging unit. The API development unit is mainly used for the development of API applications, and the API debugging unit It is mainly used for debugging API applications. For example, the API development unit is used for the generation of the orchestration relationship between the API and the API service, as well as the configuration of the sandbox environment and the production environment; the API debugging unit is used for the generation and testing of test cases (for debugging API applications) The execution of the API service (that is, the call of the API service), and the analysis of the debugging log.

It should be pointed out that the implementation environment shown in FIG. 1 is only used for example, and is not used to limit the technical solutions of the embodiments of the present application. Those skilled in the art should understand that, in the specific implementation process, the implementation environment of the present application may also include other devices, and the number of each device can be configured as required.

Please refer to FIG. 2 , which shows a method flowchart of an API application debugging method provided by an embodiment of the present application. The method can be applied to the above-mentioned implementation environment and can be executed by the API application debugging apparatus 01 . Referring to Figure 2, the method may include the following steps:

Step 101: Obtain a commissioning execution result, where the commissioning execution result is an execution result of commissioning a target API application, and the target API application is composed of at least one API service.

Optionally, the API application debugging apparatus may conduct debugging on the target API application by interacting with the API gateway according to the test case. After the commissioning and execution is completed (that is, the call to the API service in the target API application ends), the API gateway may generate a commissioning execution result, and the API application commissioning apparatus may obtain the commissioning execution result from the API gateway. The commissioning execution result may be normal or abnormal for commissioning. The test case may be deployed by the tester in the API application debugging device, and the target API application is composed of at least one API service. For example, please refer to FIG. 3 , which shows a schematic diagram of an API service orchestration sequence in a target API application provided by an embodiment of the present application. Referring to FIG. 3 , the target API application consists of API service N1 , API service N3 and API service N2 is arranged in sequence, and the API service arrangement order in the target API application is: API service N1—>API service N3—>API service N2. Among them, each circle in Figure 3 represents a graphic element, and the graphic element indicates an API service. For example, the circle where N1 is located represents the graphic element of API service N1 (which may be referred to as graphic element N1), the graphic element N1 indicates API service N1, and the circle where N2 is located represents the graphic element of API service N2 (which may be called graphic element N2) , the graphic element N2 indicates the API service N2, and the circle where the N3 is located represents the graphic element of the API service N3 (may be referred to as the graphic element N3), and the graphic element N3 indicates the API service N3.

Optionally, obtaining the commissioning execution result from the API gateway by the API application commissioning apparatus may include: the API application commissioning apparatus sends a commissioning request to the API gateway, where the commissioning request may carry the API application identifier and the test case, and the API application identifier indicates Target API application; after the API gateway receives the commissioning request, it determines the target API application according to the API application identifier, and calls the API service in the target API application according to the test case to debug the target API application. When the API service call in the API application ends, the API gateway generates a commissioning execution result; after that, the API gateway sends a commissioning response to the API application commissioning device, and the commissioning response includes the commissioning execution result; the API application commissioning device receives the After the commissioning response, parse the commissioning response to obtain the commissioning execution result.

In this embodiment of the present application, before step 101, the API application debugging apparatus may perform API programming on at least one API service to obtain a target API application, and deploy the target API application on the API gateway. The process of deploying the target API application on the API gateway by the API application debugging apparatus may include: the API application debugging apparatus sends a deployment request to the API gateway, the deployment request carries the arrangement information of the API service in the target API application, and the API gateway receives the deployment request. After the request, the target API application is deployed on the API gateway according to the arrangement information in the deployment request, and after the deployment is successful, a response indicating the successful deployment of the target API application is sent to the API application debugging device, which is not repeated in this embodiment of the present application. Repeat.

Step 102 , presenting the commissioning execution result.

After the API application commissioning device obtains the commissioning execution result, it can present the commissioning execution result, so that the tester can know the commissioning execution result. Optionally, the API application commissioning apparatus has a display interface, and the API application commissioning apparatus can display the commissioning execution result on the display interface.

For example, please refer to FIG. 4 , which shows a schematic diagram of an API application commissioning apparatus displaying commissioning execution results provided by an embodiment of the present application. Referring to FIG. 4 , the display interface of the API application commissioning apparatus displays commissioning The execution result is "Commissioning Abnormal". In addition, "Analysis" and "Yes" and "No" buttons are displayed. When the tester clicks the "Yes" button, the API application debugging device can analyze the debugging execution process. When the tester clicks the "No" button, the API application debugging device does not analyze the debugging execution process. For the process of analyzing the commissioning execution process, reference may be made to the following steps 103 to 110 .

It should be pointed out that FIG. 4 is illustrated by taking an abnormal commissioning execution result as an example. When the commissioning execution result is normal, the API application commissioning apparatus displays the interface of the commissioning execution result. Refer to FIG. 4 . This will not be repeated here.

Step 103: Obtain a target commissioning log, where the target commissioning log is a commissioning log generated during commissioning of the target API application.

In the process of debugging the target API application, the API gateway can generate the target debugging log, and the API application debugging device can obtain the target debugging log from the API gateway. Optionally, after the API application commissioning device presents the commissioning execution result, the tester can trigger the analysis instruction according to the commissioning execution result. When the API application commissioning device receives the analysis instruction triggered according to the commissioning execution result, the API application commissioning The test device can obtain the target commissioning log from the API gateway. For example, when the tester clicks the "Yes" button in Figure 4, the analysis instruction can be triggered, and the API application debugging device obtains the target debugging log from the API gateway.

Optionally, the acquisition of the target commissioning log by the API application commissioning apparatus from the API gateway may include: the API application commissioning apparatus sends a commissioning request to the API gateway, where the commissioning request carries the API application identifier and the first timestamp, the API application identifier Indicates the target API application. In addition, the commissioning request can also carry test cases; after the API gateway receives the commissioning request, it calls the API service in the target API application to commission the target API application. During the process, the API gateway can generate a debug log for the target API application. When the API service call in the target API application ends, the API gateway stops generating the debug log for the target API application, and compares the first timestamp with the second timestamp. Between timestamps, a commissioning log is generated for the target API application as the target commissioning log; after that, the API gateway sends a commissioning response to the API application commissioning device, and the commissioning response includes the target commissioning log; the API application commissioning device receives After the commissioning response is reached, the target commissioning log is obtained by parsing the commissioning response. The first timestamp is the start timestamp of the target API application commissioning, the first timestamp may be the timestamp when the API application commissioning device sends the commissioning request to the API gateway, and the second timestamp is the target API application commissioning The end timestamp of the target API application, the second timestamp can be the timestamp of the last API service of the target API application that is called by the API gateway, or the timestamp of the abnormal call of the API service of the target API application by the API gateway. The second timestamp can specifically be It is determined according to whether the API service call to the target API application is normal, and details are not described herein again in this embodiment of the present application.

It should be noted that the commissioning request in step 103 and the commissioning request in step 101 may be the same commissioning request or different commissioning requests, and the commissioning responses may be the same commissioning response or different commissioning responses. When the commissioning request in step 103 and the commissioning request in step 101 can be the same commissioning request, and the commissioning response in step 103 and the commissioning request in step 101 can be the same commissioning response, it is easy to understand, In step 101, the API gateway has returned the target commissioning log to the API application commissioning apparatus, and the API application commissioning apparatus may first store the target commissioning log, so in step 103, the API application commissioning apparatus stores data from its own storage space. The target commissioning log can be obtained by reading the target commissioning log, which is not limited in this embodiment of the present application.

For example, in this embodiment of the present application, the target commissioning log may be as follows:

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,031]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,056]|INFO||253753916688722|End Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,039]|DEBUG||253753916688722|Start execute diagram,element Id diagram_N3…,inputs:{“rest3_POST_xxxInfo”:{“a”:” stringa","b":intb},outputs:{"rest3_POST_xxxInfo":{"a":"stringa","b":intb}.requestInfo:{"reqUrl":"http://www.example.com ","method":"POST","headers":{"content-length":"162","content-type":"application/json;charset=UTF-8"},"body":"" }responseInfo:{"statusCode":200,"code":200,"headers":{"content-type":"application/json"},"body":"xxx"}

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,055]|DEBUG||253753916688722|Complete execute diagram,element Id diagram_N3,cost:7(ms),element execute info is…

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,321]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N2,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,448]|INFO||253753916688722|End Element Execution[Element Id:diagram_N2,xxx]>>>

....

Among them, diagram_N1 is the identifier of the graphic element N1, which represents the graphic element N1, and the graphic element N1 indicates the API service N1, so the diagram_N1 can also be regarded as the identifier of the API service N1; the diagram_N3 is the identifier of the graphic element N3, which represents the graphic element N3, The graphic element N3 indicates the API service N3, and diagram_N3 can also be considered as the identifier of the API service N3; diagram_N2 is the identifier of the graphic element N2, which represents the graphic element N2, the graphic element N2 indicates the API service N2, and the diagram_N2 can also be considered as the API service N2. ID; 2018-09-21 14:31:14,031 is the first timestamp; 2018-09-21 14:31:15,448 is the second timestamp; INFO is the log level of the target debugging log; 253753916688722 is the application to the target API The trace instance identifier for debugging (that is, the identifier of the test case for debugging the target API application, or the trace instance identifier of the target debugging log); applicationImpl TheadPool-4 is the thread identifier of the thread pool, indicating that the target API The debugging of the application is performed by the thread indicated by applicationImpl TheadPool-4. The above target commissioning log includes the call log of API service N1, the call log of API service N3, and the call log of API service N2, indicating that during the commissioning of the target API application, the API service N1 and API of the target API application are called in sequence. Service N3 and API Service N2. in,

The call log of API service N1 can be call log 1, and the content of call log 1 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,031]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,056]|INFO||253753916688722|End Element Execution[Element Id:diagram_N1,xxx]>>>”

The call log of API service N1 indicates that the call (keyword BeginElement Execution) API service N1 (keyword diagram_N1) starts at 2018-09-21 14:31:14,031, and ends at 2018-09-21 14:31:14,056 (keyword Word End Element Execution) API service N1.

The call log of API service N3 can be call log 3, and the content of call log 3 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,039]|DEBUG||253753916688722|Start execute diagram,element Id diagram_N3…,inputs:{“rest3_POST_xxxInfo”:{“a”:” stringa","b":intb},outputs:{"rest3_POST_xxxInfo":{"a":"stringa","b":intb}.requestInfo:{"reqUrl":"http://www.example.com ","method":"POST","headers":{"content-length":"162","content-type":"application/json;charset=UTF-8"},"body":"" }responseInfo:{"statusCode":200,"code":200,"headers":{"content-type":"application/json"},"body":"xxx"}

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,055]|DEBUG||253753916688722|Complete execute diagram,element Id diagram_N3,cost:7(ms),element execute info is…

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>”

The call log of API service N3 indicates that API service N3 (keyword diagram_N3) was called at 2018-09-21 14:31:15,021 (keyword BeginElement Execution), and ended at 2018-09-21 14:31:15,098 (keyword Word End Element Execution) API service N3, the input information (keyword inputs) of API service N3 is {"rest3_POST_xxxInfo":{"a":"stringa","b":intb}, and the output information (keyword outputs) is {"rest3_POST_xxxInfo":{"a":"stringa","b":intb}, the request information (keyword requestInfo) is {"reqUrl":"http://www.example.com","method": "POST", "headers": {"content-length": "162", "content-type": "application/json; charset=UTF-8"}, "body": ""}, response information (key The word responseInfo) is {"statusCode":200,"code":200,"headers":{"content-type":"application/json"},"body":"xxx"}, the consumption of calling API service N3 time (keyword cost) is 7 milliseconds.

The call log of API service N2 can be call log 2, and the content of call log 2 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,321]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N2,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,448]|INFO||253753916688722|End Element Execution[Element Id:diagram_N2,xxx]>>>”

The call log of API service N2 indicates that the call (keyword BeginElement Execution) API service N2 (keyword diagram_N2) starts at 2018-09-21 14:31:15,321, and ends at 2018-09-21 14:31:15,448 (keyword Word End Element Execution) API service N2.

Step 104: Determine the calling sequence of the API service in the target API application according to the target commissioning log.

Optionally, the API application debugging apparatus may analyze the target debugging log in a regular manner, and determine the calling sequence of the API services called in the target API application. The API application commissioning apparatus can analyze the target commissioning log in a regular manner according to the call keywords in the target commissioning log, and determine the calling sequence of the API services called in the target API application. Wherein, the call keyword may include a call start keyword (eg, Begin Element Execution), a call end keyword (eg, End Element Execution), a primitive identifier (eg, diagram_N1 ), and the like.

For example, the API application debugging apparatus determines, according to the target debugging log in step 103, that the calling sequence of the API service in the target API application is: API service N1->API service N3->API service N2.

In some scenarios, the calling sequence is also called execution sequence, and the execution sequence may be embodied in the form of a list. For example, the execution sequence may be an execution sequence list [API service N1, API service N3, API service N2].

Step 105: Obtain call logs of each called API service from the target commissioning log.

Optionally, the apparatus for debugging the API application may acquire the call log of each called API service from the target debugging log according to the feature tag of the called API service. In some scenarios, call logs are also called feature logs.

Please refer to FIG. 5 , which shows a flowchart of a method for obtaining call logs of each called API service from a target commissioning log provided by an embodiment of the present application. Referring to FIG. 5 , the method may include:

Sub-step 1051: Determine the characteristic labels of each called API service, where the characteristic labels include the identifier of the called API service and the identifier of the trace instance for debugging the target API application.

Wherein, if the identifier of an API service exists in the target debugging log, it means that the API service is called during the debugging of the target API application.

Optionally, the API application debugging apparatus may generate a feature label of each called API service according to the identifier of each called API service and the tracking instance identifier for debugging the target API application.

For example, the trace instance identifier for debugging the target API application is 253753916688722, the identifier of API service 1 may be diagram_N1, the identifier of API service 2 may be diagram_N2, the identifier of API service 3 may be diagram_N3, and API service 1, API If both service 2 and API service 3 are called API services, the feature label of API service 1 can be {253753916688722, diagram_N1}, the feature label of API service 2 can be {253753916688722, diagram_N2}, and the feature label of API service 3 can be is {253753916688722, diagram_N3}.

Sub-step 1052: Extract the call log of each called API service from the target commissioning log according to the feature tag of each called API service.

Optionally, the API application debugging apparatus may determine the calling log of each called API service from the target debugging log according to the feature tag of each called API service and in combination with the calling time keyword in the target debugging log, And extract the call log of each called API service. The call time keyword may include a call start keyword (eg, Begin Element Execution) and a call end keyword (eg, End Element Execution).

For example, the API application commissioning device extracts the call log 1 of API service 1 from the target commissioning log in step 103 according to {253753916688722, diagram_N1}, Begin ElementExecution and End Element Execution, according to {253753916688722, diagram_N2}, Begin Element Execution and End ElementExecution, extract the call log 2 of API service 2 from the target commissioning log in step 103, and extract API service 3 from the target commissioning log in step 103 according to {253753916688722, diagram_N3}, Begin Element Execution and End Element Execution The call log of 3.

Step 106: Establish an association relationship between the called API service and the calling log according to each called API service and the corresponding calling log.

Optionally, the API application debugging apparatus may associate each called API service with a call log of the called API service, and obtain an association relationship between the called API service and the call log. For example, the API application debugging apparatus associates the API service 1 with the call log 1, associates the API service 2 with the call log 2, and associates the API service 3 with the call log 3, and obtains the association relationship between the called API service and the call log It can be shown in Table 1 below:

Table 1

API service call log API Service 1 call log 1 API Service 2 call log 2 API Service 3 call log 3

Step 107 , present the calling track of the API service according to the calling sequence of the API service in the target API application.

The API application debugging apparatus can present the API service calling track according to the calling sequence of the API service in the target API application, for example, display the API service calling track. Wherein, the API service calling track includes at least the picture element of the called API service and the trajectory line connecting the picture elements of at least two called API services according to the calling sequence, and the picture element of the API service indicates the API service. In some implementation scenarios, the call trajectory is also referred to as the execution trajectory.

In this embodiment of the present application, the API service calling track may be a normal track or an abnormal track. The API application debugging apparatus presents the API service calling trace according to the calling sequence of the API services in the target API application, which may include: when the API service calling trace is a normal trace, the API application debugging apparatus presents the API service calling trace according to the calling sequence. The call trace includes the primitives of the called API service and the trace lines connecting the primitives of all the called API services in the calling sequence. When the API service invocation trace is an abnormal trace, the API application debugging device presents the API service invocation trace according to the invocation sequence and the API service arrangement order. Primitives, the trace lines connecting the primitives of all called API services in the calling order, the arranging lines connecting all the primitives of the API services that have not been called according to the API service orchestration order, and, connecting the called API services in the order of API service orchestration The arrangement line of the primitives of the API service and the primitives of the API services that have not been called. The called API services include calling normal API services and calling abnormal API services, calling normal API services, and calling abnormal API services. The presentation forms of the primitives of the API service and the primitives of the API services that have not been called are different. In order to more intuitively present the API service call track as a normal track or an abnormal track, the API application debugging device can also present the API service arrangement sequence, so that the tester can intuitively determine the API service call track as the normal track according to the API service arrangement sequence. or abnormal trajectory.

For example, please refer to FIG. 6 , which shows a schematic diagram of an API service invocation trace provided by an embodiment of the present application, and FIG. 6 also shows an API service arrangement sequence. Referring to FIG. 6 , the API service call trace includes the graphic elements of API service N1, API service N3 and API service N2 (the called API service) and the graphic elements connecting API service N1, API service N3 and API service N2 in the calling sequence. Trajectory line, Fig. 6 shows that in the process of debugging the target API application, API service N1, API service N3 and API service N2 are called in sequence, and API service N1, API service N3 and API service N2 are all called normally. The API service call trace shown in Figure 6 is a normal trace.

For example, please refer to FIG. 7 , which shows a schematic diagram of another API service invocation trace provided by an embodiment of the present application, and FIG. 7 also shows an API service arrangement sequence. Referring to Fig. 7, the API service call trace includes the primitives of API service N1 and API service N3 (all API services that are called), the primitives of API service N2 (all API services that have not been called), and the API services are connected in the calling sequence. Trajectory lines of primitives of N1 and API service N3 (all called API services), choreography lines connecting primitives of API service N2 (not called API services) in the order of API service choreography, and choreography according to API services An arrangement line that sequentially connects the primitives of API service N3 (the invoked API service) and the primitives of API service N2 (the API service that has not been invoked). The invoked API services include API service N1 (the normal API service is invoked) and API service N3 (calling abnormal API service), API service N1 (calling normal API service) graphic element, API service N3 (calling abnormal API service) graphic element and API service N2 (not calling API service) ) are rendered differently. Figure 7 shows that in the process of debugging the target API application, the API service N2 and the API service N3 are called in sequence, the API service N2 is not called, the API service N1 is called normally, and the API service N3 is called abnormally, as shown in Figure 7 The API service call trace is abnormal trace.

Step 108: Obtain the target call log of the target API service from the target commissioning log.

The target API service is any API service that is called in the process of debugging the target API application, and the target API service can be an API service that calls abnormally, or can call a normal API service.

Optionally, before step 108, the API application debugging apparatus may determine the calling sequence of the API services in the target API application according to the target debugging log, and present the API service calls according to the calling sequence of the API services in the target API application. After the API application debugging device presents the API service call trace, the tester can trigger the acquisition instruction for the graphic element of the target API service according to the API service call trace (for example, click the graphic element acquisition instruction of the target API service in the API service call trace) ); when the API application debugging device detects the acquisition instruction triggered by the graphic element of the target API service, the API application debugging device can obtain the target calling log of the target API service from the target debugging log. Optionally, the API application debugging apparatus may obtain the target invocation log of the target API service from the association relationship between the invoked API service and the invocation log. The relationship between the called API service and the call log can be the relationship between the identifier of the called API service and the call log. The API application debugging device can query the relationship between the called API service and the call log according to the identifier of the target API service. Association relationship, get the target call log, and get the target call log.

Illustratively, taking FIG. 6 as an example, the API service calling trace is shown in FIG. 6 , and the target API service is API service N3 (calling a normal API service). According to the API service call trace shown in Figure 6, the tester can trigger the acquisition instruction for the graphic element of the API service N3. When the API application debugging device detects the acquisition instruction triggered by the graphic element of the API service N3, the API application debugging The device may obtain the call log 3 (target call log) of the API service N3 from the above Table 1.

For example, the content of call log 3 (target call log) is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,039]|DEBUG||253753916688722|Start execute diagram,element Id diagram_N3…,inputs:{“rest3_POST_xxxInfo”:{“a”:” stringa","b":intb},outputs:{"rest3_POST_xxxInfo":{"a":"stringa","b":intb}.requestInfo:{"reqUrl":"http://www.example.com ","method":"POST","headers":{"content-length":"162","content-type":"application/json;charset=UTF-8"},"body":"" }responseInfo:{"statusCode":200,"code":200,"headers":{"content-type":"application/json"},"body":"xxx"}

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,055]|DEBUG||253753916688722|Complete execute diagram,element Id diagram_N3,cost:7(ms),element execute info is…

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>”.

Step 109: Acquire key information in the target call log.

The key information may include, but is not limited to: input information (keyword inputs), output information (keyword outputs), request information (keyword requestInfo), response information (keyword responseInfo) and exception information (keyword Exception). When the target API service is a normal API service, the key information in the target call log includes input information, output information, request information and response information. When the target API service is an abnormal API service, the key information in the target call log The information includes exception information.

Optionally, the API application debugging apparatus may obtain key information in the target call log in combination with the identifier of the target API service and the keyword. 6 as an example, the target API service is API service N3, and the API application debugging device obtains the target call according to the identifier diagram_N3 of the API service N3, the keyword inputs, the keyword outputs, the keyword requestInfo and the keyword responseInfo. The key information in the log (call log 3 in step 108), the key information can be: "inputs:{"rest3_POST_xxxInfo":{"a":"stringa","b":intb}, outputs:{"rest3_POST_xxxInfo" ":{"a":"stringa","b":intb}.requestInfo:{"reqUrl":"http://www.example.com","method":"POST","headers":{ "content-length":"162","content-type":"application/json;charset=UTF-8"},"body":""}responseInfo:{"statusCode":200,"code":200 ,"headers":{"content-type":"application/json"},"body":"xxx"}".

Step 110, presenting key information.

After acquiring the key information in the target call log, the API application debugging apparatus can present the key information, so that the tester can know the key information. Optionally, the API application debugging apparatus has a display interface, and the API application debugging apparatus can display key information in the target call log on the display interface.

Optionally, the target invocation log may include key information and non-critical information, and the API application commissioning apparatus presenting the key information in the target invocation log may include: the API application commissioning apparatus presents the target invocation log in a format different from the non-critical information. form to present key information.

For example, the API application commissioning apparatus displaying the target call log, and presenting the key information in a form different from the non-critical information may include: the API application commissioning apparatus displays the target call log, and the font size of the key information is larger than the font size of the non-critical information; The API application commissioning device displays the target call log, and the font of the key information is different from the font of the non-critical information; the API application commissioning device displays the target call log, and the key information is highlighted, and the non-critical information is not highlighted; API application commissioning The device displays the target call log, and the font of the key information is bold, and the font of the non-critical information is not bold; the API application debugging device displays the target call log, and the font of the key information is oblique, and the font of the non-critical information is not oblique, etc. .

For example, the API application debugging device displays the target call log, and the font of key information is bold, and the font of non-critical information is not bold, and the key information (target call log) displayed by the API application debugging device may be as follows:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,039]|DEBUG||253753916688722|Start execute diagram,element Id diagram_N3…,inputs:{“rest3_POST_xxxInfo”:{“a”:” stringa","b":intb},outputs:{"rest3_POST_xxxInfo":{"a":"stringa","b":intb}.requestInfo:{"reqUrl":"http://www.example.com ","method":"POST","headers":{"content-length":"162","content-type":"application/json;charset=UTF-8"},"body":"" }responseInfo:{"statusCode":200,"code":200,"headers":{"content-type":"application/json"},"body":"xxx"}

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,055]|DEBUG||253753916688722|Complete execute diagram,element Id diagram_N3,cost:7(ms),element execute info is…

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>”.

It should be pointed out that steps 108 to 110 are illustrated by taking the target API service as an example of calling a normal API service. When the target API service is an API service with an abnormal call, the corresponding implementation process can refer to steps 108 to 110 . For example, when the target API service is an API service with an abnormal call, the key information (target call log) acquired and presented by the API application debugging apparatus may be as follows:

“||com.huawei.xxx.service.executeByLocal(xxx.java:17)>>>

javax.script.ScriptException: rebate amt over limit in <eval>at linenumber 5at column number 8"

Among them, "Exception" is the exception keyword, and the presentation form of "Exception" is different from that of non-critical information. Therefore, after the API application debugging device presents the key information, the tester can Exception", quickly identify the problem of API layout. In the solution provided by the embodiment of the present application, the API application commissioning apparatus can automatically analyze the commissioning execution process, which is convenient for the tester to quickly determine the problem point.

It should be pointed out that, in the embodiment of the present application, the API application debugging device may include an API development unit and an API debugging unit, and the above steps 101 to 110 may be completed by the API development unit and the API debugging unit, for example, by the API The development unit performs the steps related to the orchestration of the target API application, deploying the target API application on the API gateway, etc., and the API commissioning unit performs the steps related to the acquisition and analysis of the target commissioning log.

It should also be pointed out that, in the embodiments of the present application, the commissioning execution process is analyzed when the commissioning execution result is normal. Those skilled in the art should understand that in practical applications, the commissioning execution process may only be performed when the commissioning execution result is abnormal. When the commissioning execution result is normal, the commissioning execution process may not be analyzed. The specific circumstances under which the commissioning execution process is analyzed can be determined according to the operation of the tester on the commissioning execution result (for example, according to the commissioning personnel The operation in the display interface shown in FIG. 4 is determined), which is not limited in this embodiment of the present application.

Those skilled in the art can easily understand that the sequence of steps of the API application debugging method provided in the embodiments of the present application can be appropriately adjusted. Corresponding increases and decreases can also be made according to the situation. Any person skilled in the art who is familiar with the technical scope disclosed in the present application can easily think of the changed methods, which should be covered by the protection scope of the present application, so they will not be repeated.

To sum up, the API application debugging method provided in the embodiment of the present application obtains the target debugging log, obtains the target calling log of the target API service from the target debugging log, obtains the key information in the target calling log, and presents the Key information, since the key information in the call log can be obtained and presented without manual analysis, it helps to reduce the time-consuming of API application commissioning, improve the commissioning efficiency of API applications, and improve user experience. In addition, because the API service call trace can be presented in the form of graphic elements, it is convenient for the commissioner to know the call flow and call branch of the commissioning process, so the visualization effect of API application commissioning is better; further, when the API service call trace is presented, After that, the target call log of the target API service can be obtained according to the acquisition instruction triggered by the primitive of the target API service, and the key information of the target call log can be displayed, so it is convenient for the tester to quickly view the key information and locate the problem point of the API layout. The problem of API arrangement is corrected in time, and the debugging efficiency is high.

In this embodiment of the present application, before presenting the API service calling track (step 107 ), the API application debugging apparatus may first determine whether the API service calling track is a normal track. Please refer to FIG. 8 , which shows a flowchart of a method for determining whether an API service call trace is a normal trace provided by an embodiment of the present application. Referring to FIG. 8 , the method may include:

Step 201: Determine the last called API service according to the calling sequence of the API services in the target API application.

Optionally, the API application debugging apparatus determines the last API service in the calling sequence of the API services as the last API service to be called. For example, assuming that the calling sequence of the API service in the target API application is: API service N1 -> API service N3 -> API service N2, the API application debugging apparatus determines API service N2 as the last API service to be called; As another example, assuming that the calling sequence of API services in the target API application is: API service N1 -> API service N3, the API application debugging apparatus determines API service N3 as the last API service to be called.

Step 202: Determine the ending API service of the target API application according to the API service arrangement sequence of the target API application.

Optionally, the API application debugging apparatus determines the last API service in the sequence of the API services of the target API application as the ending API service of the target API application. For example, the sequence of API services in the target API application is: API service N1 -> API service N3 -> API service N2, then the API application debugging apparatus determines API service N2 as the ending API service of the target API application.

Step 203: Determine whether the last API service called is the end API service of the target API application.

Optionally, the API application debugging apparatus may determine the identifier of the last API service called (for example, the identifier of the graphic element of the called API service) and the identifier of the target API application that ends the API service (for example, the image of the finished API service). Meta ID), compare the ID of the last API service called with the ID of the end API service of the target API application to determine whether the last API service called is the end API service of the target API application, if the last API service is the end API service of the target API application. The identifier of a called API service is the same as the identifier of the end API service of the target API application, then the last API service called is the end API service of the target API application. If the identifier of the last API service called is the same as that of the target API If the identifiers of the end API services of the application are different, the last API service called is not the end API service of the target API application.

For example, assuming that the last API service called is API service N2, and the end API service of the target API application is API service N2, the API application debugging apparatus can determine that the last API service called is the target API service by comparing the identifiers. The end API service of the API application; for another example, assuming that the last API service called is API service N3, and the end API service of the target API application is API service N2, the API application debugging device can determine the final API service by comparing the identifiers. A called API service is not the end API service of the target API application.

Step 204: When the last API service called is the ending API service of the target API application, determine that the API service calling track is a normal track.

If the API application debugging apparatus determines in step 203 that the last API service called is the ending API service of the target API application, the API application debugging apparatus determines that the API service calling track is a normal track. For example, when the last API service called is API service N2, and the ending API service of the target API application is API service N2, the API application debugging apparatus determines that the API service calling track is a normal track.

Step 205 , when the last API service called is not the end API service of the target API application, determine that the API service calling track is an abnormal track.

If the API application debugging apparatus determines in step 203 that the last API service called is not the end API service of the target API application, the API application debugging apparatus determines that the API service calling track is an abnormal track. For example, when the last API service called is API service N3, and the ending API service of the target API application is API service N2, the API application debugging apparatus determines that the API service calling track is an abnormal track.

It should be noted that when the API service call trace is an abnormal trace, when the API service call trace is presented, the last called API service can be set as the abnormal API service in the API service call trace (for example, Figure 7 API service in 3).

In the embodiment of the present application, the API service calling track may be a normal track or an abnormal track. The normal track is different from the abnormal track. Before presenting the API service calling track, the API application debugging device determines whether the API service calling track is a normal track, which can facilitate Rendering of API service call traces.

The following are apparatus embodiments of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

Please refer to FIG. 9 , which shows a schematic diagram of a logical structure of an API application debugging apparatus 300 provided by an embodiment of the present application. The API application debugging apparatus 300 may be used to perform the API application debugging provided by the above-mentioned embodiments. For the method, referring to FIG. 9 , the API application debugging apparatus 300 may include, but is not limited to:

The first obtaining module 301 is configured to obtain a target commissioning log, where the target commissioning log is a commissioning log generated during commissioning of a target API application, and the target API application is composed of at least one API service;

The second obtaining module 302 is configured to obtain the target call log of the target API service from the target debugging log, where the target API service is any API service that is called in the process of debugging the target API application;

The third obtaining module 303 is used to obtain the key information in the target call log;

The first presentation module 304 is used for presenting key information.

To sum up, in the API application debugging device provided by the embodiment of the present application, after the first obtaining module obtains the target debugging log, the second obtaining module obtains the target calling log of the target API service from the target debugging log, and the third obtaining module obtains the target calling log of the target API service from the target debugging log. The module obtains the key information in the target call log, and the first presentation module presents the key information. Since the key information in the call log can be obtained and presented without manual analysis, it is helpful to reduce the time-consuming of API application debugging and improve the The debugging efficiency of API applications improves the user experience.

Optionally, the second obtaining module 302 is configured to obtain the target call log of the target API service from the relationship between the called API service and the call log, and the relationship between the called API service and the call log is based on the target call log. The test log is created.

Optionally, please refer to FIG. 10 , which shows a schematic diagram of a logical structure of another API application debugging apparatus 300 provided by an embodiment of the present application. Referring to FIG. 10 , on the basis of FIG. 9 , the API application debugging The measuring device 300 also includes:

The first determining module 305 is configured to determine the calling sequence of the API service in the target API application according to the target debugging log;

The fourth obtaining module 306 is configured to obtain the call log of each called API service from the target commissioning log;

The establishing module 307 is configured to establish an association relationship between the called API service and the calling log according to each called API service and the corresponding calling log.

Optionally, the fourth obtaining module 306 is used for:

Determine the characteristic label of each called API service, and the characteristic label includes the identifier of the called API service and the identifier of the tracking instance for debugging the target API application;

According to the feature tag of each called API service, the call log of each called API service is extracted from the target commissioning log.

Optionally, please continue to refer to FIG. 10 , the API application debugging apparatus 300 further includes:

The second determining module 308 is configured to determine the calling sequence of the API service in the target API application according to the target debugging log;

The second presentation module 309 is configured to present the API service calling track according to the calling sequence, where the API service calling track at least includes the picture element of the called API service and the track connecting the picture elements of at least two called API services according to the calling sequence Line, the graphic element of the API service indicates the API service;

The second acquiring module 302 is configured to acquire the target invocation log from the association relationship between the invoked API service and the invocation log when an acquisition instruction triggered by a graphic element for the target API service is detected.

Optionally, please continue to refer to FIG. 10 , the API application debugging apparatus 300 further includes:

The third determining module 310 is configured to determine the last called API service according to the calling sequence;

The fourth determining module 311 is configured to determine the ending API service of the target API application according to the API service arrangement sequence of the target API application;

The judgment module 312 is used to judge whether the last called API service is the end API service of the target API application;

The fifth determining module 313 is configured to determine that the API service calling track is a normal track when the last API service called is the ending API service of the target API application;

The sixth determining module 314 is configured to determine that the API service calling track is an abnormal track when the last API service called is not the ending API service of the target API application.

Optionally, the second presentation module 309 is used for:

When the API service calling track is a normal track, the API service calling track is presented according to the calling sequence. The API service calling track includes the graphic elements of the called API service, and the graphic elements that connect all the called API services according to the calling sequence. track line;

When the API service calling track is an abnormal track, the API service calling track is presented according to the calling sequence and the API service arrangement order. The API service calling track includes the graphics elements of the called API services and the graphics elements of the API services that have not been called. The trace lines that connect the primitives of all called API services in sequence, the choreography lines that connect the primitives of all API services that have not been called according to the API service orchestration order, and the graphs that connect the called API services in the API service orchestration order The arrangement line of the primitives and the primitives of the API services that have not been called. The invoked API services include the normal API services and the abnormal API services, the primitives that call the normal API services, and the primitives that call the abnormal API services. And the rendering form of the primitives of the API service that is not called is different.

Optionally, the first determining module 305 is configured to analyze the target commissioning log in a regular manner, and determine the calling sequence of the API services called in the target API application.

Optionally, the first obtaining module 301 is used for:

Send a commissioning request to the API gateway, where the commissioning request carries the API application identifier and the first timestamp, the API application identifier indicates the target API application, and the first timestamp is the start timestamp of the target API application commissioning;

Receive the commissioning response sent by the API gateway. The commissioning response includes the target commissioning log. The target commissioning log is the commissioning log generated by the API gateway for the target API application between the second timestamp and the first timestamp. The second timestamp End timestamp of application debugging for the target API.

Optionally, the commissioning response further includes a commissioning execution result. The commissioning execution result is the execution result of the API gateway commissioning the target API application. Please continue to refer to FIG. 10 . The API application commissioning apparatus 300 further includes:

The fifth obtaining module 315 is configured to obtain a commissioning execution result, where the commissioning execution result is an execution result of commissioning the target API application;

a third presentation module 316, configured to present the commissioning execution result;

The first acquiring module 301 is configured to acquire a target commissioning log when an analysis instruction triggered according to a commissioning execution result is received.

To sum up, in the API application debugging device provided by the embodiment of the present application, after the first obtaining module obtains the target debugging log, the second obtaining module obtains the target calling log of the target API service from the target debugging log, and the third obtaining module obtains the target calling log of the target API service from the target debugging log. The module obtains the key information in the target call log, and the first presentation module presents the key information. Since the key information in the call log can be obtained and presented without manual analysis, it is helpful to reduce the time-consuming of API application debugging and improve the The debugging efficiency of API applications improves the user experience. In addition, because the API service call trace can be presented in the form of graphic elements, it is convenient for the commissioner to know the call flow and call branch of the commissioning process, so the visualization effect of API application commissioning is better; further, when the API service call trace is presented, After that, the target call log of the target API service can be obtained according to the acquisition instruction triggered by the primitive of the target API service, and the key information of the target call log can be displayed, so it is convenient for the tester to quickly view the key information and locate the problem point of the API layout. The problem of API arrangement is corrected in time, and the debugging efficiency is high.

Please refer to FIG. 11 , which shows a schematic diagram of a hardware structure of an API application debugging apparatus 400 provided by an embodiment of the present application. Referring to FIG. 11 , the API application debugging apparatus 400 includes a processor 402 , a memory 404 , and a communication interface 406 And bus 408, processor 402, memory 404 and communication interface 406 are connected by bus 408. Memory 404 may be used to store instructions 4042 and data 4044 . It is easy to understand that the connection between the processor 402, the memory 404 and the communication interface 406 shown in FIG. 11 is only exemplary, and in the specific implementation process, the processor 402, the memory 404 and the communication interface 406 can also use other than the bus Other connection methods other than 408 are communicatively connected to each other.

The processor 402 may be a general-purpose processor, and the general-purpose processor may be a processor that performs specific steps and/or operations by reading and executing instructions (eg, instructions 4042 ) stored in a memory (eg, memory 404 ). The processor may use data (eg, data 4044 ) stored in memory (eg, memory 404 ) in performing the steps and/or operations described above. A general-purpose processor may be, for example, but not limited to, a central processing unit (CPU). Additionally, processor 402 may also be a special purpose processor, which may be a processor specially designed to perform particular steps and/or operations, such as, but not limited to, a digital signal processor ( digital signal processor, DSP), application specific integrated circuit (application specific integrated circuit, ASIC) and field programmable gate array (field programmable gate array, FPGA) and so on. In addition, the processor 402 may also be a combination of multiple processors, such as a multi-core processor. The processor 402 may include at least one circuit to perform the steps of the API application debugging method in the following embodiments.

The memory 404 may be various types of storage media, such as random access memory (RAM), ROM, non-volatile RAM (NVRAM), programmable ROM (PROM), erasable In addition to PROM (erasable PROM, EPROM), electrically erasable PROM (electrically Erasable PROM, EEPROM), flash memory, optical memory and registers, etc. The memory 404 is specifically used to store the instructions 4042 and the data 4044. When the processor 402 is a general-purpose processor, the processor 402 can perform specific steps and/or operations by reading and executing the instructions 4042 stored in the memory 404. Data 4044 may be required during the above steps and/or operations.

Depending on the API application debugging device, the communication interface 406 may include transceivers, multiple antennas, or I/O (input/output, input/output) interfaces, etc., the I/O interfaces are used to receive instructions from peripheral devices and/or or data, and output commands and/or data to peripheral devices. The antenna is connected to the transceiver, and the transceiver transmits and receives signals through at least one antenna connected thereto.

In a specific implementation process, the processor 402 may be used to perform, for example, but not limited to, commissioning related processing, and the transceiver may be used to perform, for example, but not limited to, transceiver-related processing. The above-mentioned devices may be respectively arranged on chips that are independent of each other, or at least part or all of them may be arranged on the same chip. For example, the processor 402 can be further divided into an analog baseband processor and a digital baseband processor, wherein the analog baseband processor and the transceiver can be integrated on the same chip, and the digital baseband processor can be provided on a separate chip. With the continuous development of integrated circuit technology, more and more devices can be integrated on the same chip. For example, a digital baseband processor can be combined with a variety of application processors (such as but not limited to graphics processors, multimedia processors, etc.) integrated on the same chip. Such a chip may be referred to as a System on Chip. Whether each device is independently arranged on different chips or integrated on one or more chips often depends on the specific needs of product design. The embodiments of the present application do not limit the specific implementation form of the above device.

It is easy to understand that the API application debugging apparatus 400 shown in FIG. 11 is only exemplary, and in the specific implementation process, the API application debugging apparatus 400 may also include other hardware devices, which are not listed one by one herein. The specific functions of the hardware devices in the API application debugging apparatus 400 will be described in detail below.

Embodiments of the present application provide a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a processing component of a computer, the processing component causes the processing component to execute the API application call provided by the foregoing embodiments. measurement method.

The embodiments of the present application provide a computer program product containing instructions, when the computer program product runs on a computer, the computer enables the computer to execute the API application debugging method provided by the foregoing embodiments.

Embodiments of the present application provide a chip, where the chip includes a programmable logic circuit and/or program instructions, and is used to implement the API application debugging method provided by the above embodiments when the chip is running.

In the embodiments of this application, the term "and/or" is only an association relationship to describe associated objects, indicating that there may be three relationships, for example, A and/or B, which may indicate that A exists alone, and A and B exist at the same time , there are three cases of B alone. In addition, the character "/" in this document generally indicates that the related objects are an "or" relationship.

In the embodiments of the present application, the term "at least one" refers to one or more, and a plurality refers to more than one, for example, two.

Those of ordinary skill in the art can understand that all or part of the steps of implementing the above embodiments can be completed by hardware, or can be completed by instructing relevant hardware through a program, and the program can be stored in a computer-readable storage medium. The storage medium mentioned may be a read-only memory, a magnetic disk or an optical disk, etc.

The above descriptions are only optional embodiments of the present application, and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the protection of the present application. within the range.

Claims (24)

1. A method for API application debugging, the method comprising:

acquiring a target debugging log, wherein the target debugging log is generated in the debugging process of a target API application, and the target API application is formed by arranging at least one API service;

acquiring a target call log of a target API service from the target call log, wherein the target API service is any API service called in the process of calling and testing the target API application;

acquiring key information in the target call log;

and presenting the key information.

2. The method of claim 1, wherein obtaining a target call log of a target API service from the target call log comprises:

and acquiring the target call log from the association relationship between the called API service and the call log, wherein the association relationship between the called API service and the call log is established according to the target call log.

3. The method of claim 2, wherein before obtaining the target call log from the association of the called API service with the call log, the method further comprises:

determining a calling sequence of API services in the target API application according to the target debugging log;

obtaining a call log of each called API service from the target call log;

and establishing an association relation between the called API service and the call log according to each called API service and the corresponding call log.

4. The method of claim 3, wherein obtaining a call log for each called API service from the target call log comprises:

determining a feature tag of each called API service, wherein the feature tag comprises an identifier of the called API service and a tracking instance identifier for testing the target API application;

and extracting the call logs of the called API services from the target call logs according to the feature tags of the called API services.

5. The method of claim 1,

before obtaining the target call log of the target API service from the target call log, the method further includes:

determining a calling sequence of API services in the target API application according to the target debugging log;

presenting an API service calling track according to the calling sequence, wherein the API service calling track at least comprises primitives of the called API service and trajectory lines for connecting the primitives of at least two called API services according to the calling sequence, and the primitives of the API service indicate the API service;

obtaining a target call log of a target API service from the target call log, including:

and when an acquisition instruction triggered by the graphic element of the target API service is detected, acquiring a target call log of the target API service from the target call log.

6. The method of claim 5, wherein prior to presenting API service call traces according to the call order, the method further comprises:

determining the last called API service according to the calling sequence;

determining the end API service of the target API application according to the API service arrangement sequence of the target API application;

judging whether the last called API service is the ending API service of the target API application;

when the last called API service is the ending API service of the target API application, determining that the API service calling track is a normal track;

and when the last called API service is not the ending API service of the target API application, determining that the API service calling track is an abnormal track.

7. The method of claim 6, wherein presenting API service call tracks according to the call order comprises:

when the API service calling track is a normal track, presenting the API service calling track according to the calling sequence, wherein the API service calling track comprises primitives of the called API service and trajectory lines for connecting all the primitives of the called API service according to the calling sequence;

when the API service calling track is an abnormal track, presenting the API service calling track according to the calling sequence and the API service arranging sequence, the API service call trace includes primitives for called API services, primitives for un-called API services, connecting the trajectory lines of the primitives of all the called API services according to the calling sequence, connecting the layout lines of the primitives of all the un-called API services according to the API service layout sequence, and an arrangement line connecting the primitives of the called API service and the primitives of the un-called API service according to the API service arrangement sequence, the called API service includes calling a normal API service and calling an abnormal API service, and the presentation forms of the primitive calling the normal API service, the primitive calling the abnormal API service and the primitive not called the API service are different.

8. The method of claim 3, wherein determining the calling order of the API services in the target API application from the target commissioning log comprises:

and analyzing the target debugging log in a regular mode, and determining the calling sequence of the called API service in the target API application.

9. The method of claim 1, wherein obtaining a target commissioning log, the target commissioning log being a commissioning log generated during commissioning of a target API application, comprises:

sending a debugging request to an API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates the target API application, and the first timestamp is a starting timestamp of debugging of the target API application;

receiving a debugging response sent by the API gateway, wherein the debugging response comprises the target debugging log, the target debugging log is the debugging log generated by the API gateway aiming at the target API application between a second timestamp and the first timestamp, and the second timestamp is an ending timestamp of the target API application debugging.

10. The method of any of claims 1 to 9, wherein prior to obtaining the target commissioning log, the method further comprises:

obtaining a debugging execution result, wherein the debugging execution result is an execution result of debugging the target API application;

presenting the debugging execution result;

the acquiring of the target survey log includes:

and when an analysis instruction triggered according to the debugging execution result is received, acquiring the target debugging log.

11. An apparatus for API application debugging, the apparatus comprising:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a target debugging log, the target debugging log is generated in the debugging process of a target API application, and the target API application is formed by arranging at least one API service;

a second obtaining module, configured to obtain a target call log of a target API service from the target call log, where the target API service is any API service that is called in a process of testing the target API application;

the third acquisition module is used for acquiring key information in the target call log;

and the first presentation module is used for presenting the key information.

12. The apparatus of claim 11,

the second obtaining module is configured to obtain a target call log of the target API service from an association relationship between the called API service and the call log, where the association relationship between the called API service and the call log is established according to the target call log.

13. The apparatus of claim 12, further comprising:

a first determining module, configured to determine, according to the target debug log, a call order of API services in the target API application;

a fourth obtaining module, configured to obtain, from the target call log, a call log of each called API service;

and the establishing module is used for establishing the association relationship between the called API service and the call log according to each called API service and the corresponding call log.

14. The apparatus of claim 13, wherein the fourth obtaining module is configured to:

determining a feature tag of each called API service, wherein the feature tag comprises an identifier of the called API service and a tracking instance identifier for testing the target API application;

and extracting the call logs of the called API services from the target call logs according to the feature tags of the called API services.

15. The apparatus of claim 11, further comprising:

a second determining module, configured to determine, according to the target debug log, a call order of API services in the target API application;

the second presentation module is used for presenting an API service calling track according to the calling sequence, wherein the API service calling track at least comprises primitives of the called API service and trajectory lines for connecting at least two primitives of the called API service according to the calling sequence, and the primitives of the API service indicate the API service;

and the second obtaining module is used for obtaining a target call log of the target API service from the target call log when an obtaining instruction triggered by the primitive aiming at the target API service is detected.

16. The apparatus of claim 15, further comprising:

a third determining module, configured to determine, according to the call order, a last called API service;

a fourth determining module, configured to determine, according to the API service arrangement order of the target API application, an end API service of the target API application;

the judging module is used for judging whether the last called API service is the ending API service of the target API application;

a fifth determining module, configured to determine that the API service calling track is a normal track when the last called API service is an end API service of the target API application;

a sixth determining module, configured to determine that the API service call trajectory is an abnormal trajectory when the last called API service is not the end API service of the target API application.

17. The apparatus of claim 16, wherein the second rendering module is configured to:

when the API service calling track is a normal track, presenting the API service calling track according to the calling sequence, wherein the API service calling track comprises primitives of the called API service and trajectory lines for connecting all the primitives of the called API service according to the calling sequence;

when the API service calling track is an abnormal track, presenting the API service calling track according to the calling sequence and the API service arranging sequence, the API service call trace includes primitives for called API services, primitives for un-called API services, connecting the trajectory lines of the primitives of all the called API services according to the calling sequence, connecting the layout lines of the primitives of all the un-called API services according to the API service layout sequence, and an arrangement line connecting the primitives of the called API service and the primitives of the un-called API service according to the API service arrangement sequence, the called API service includes calling a normal API service and calling an abnormal API service, and the presentation forms of the primitive calling the normal API service, the primitive calling the abnormal API service and the primitive not called the API service are different.

18. The apparatus of claim 13,

the first determining module is configured to analyze the target debugging log in a regular manner, and determine a calling order of the called API service in the target API application.

19. The apparatus of claim 11, wherein the first obtaining module is configured to:

sending a debugging request to an API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates the target API application, and the first timestamp is a starting timestamp of debugging of the target API application;

receiving a debugging response sent by the API gateway, wherein the debugging response comprises the target debugging log, the target debugging log is the debugging log generated by the API gateway aiming at the target API application between a second timestamp and the first timestamp, and the second timestamp is an ending timestamp of the target API application debugging.

20. The apparatus of any one of claims 11 to 19, further comprising:

a fifth obtaining module, configured to obtain a debugging execution result, where the debugging execution result is an execution result of debugging the target API application;

the third presentation module is used for presenting the debugging execution result;

the first obtaining module is used for obtaining the target debugging log when receiving an analysis instruction triggered according to the debugging execution result.

21. An API application deployment test apparatus, comprising: a processor, a communication interface, a memory, and a bus, the processor to execute instructions stored in the memory to implement the API application commissioning method of any one of claims 1 to 10.

22. A computer-readable storage medium having stored therein instructions which, when run on a processing component of a computer, cause the processing component to perform the API application commissioning method of any one of claims 1 to 10.

23. A computer program product comprising instructions for causing a computer to perform the API application commissioning method of any one of claims 1 to 10 when said computer program product is run on the computer.

24. A chip comprising programmable logic circuitry and/or program instructions for implementing the API application commissioning method of any one of claims 1 to 10 when said chip is run.

Images