A method, apparatus and device for idempotency detection

Abstract

Embodiments of the present specification disclose an idempotency validity detection method, device and equipment. The scheme comprises: obtaining a sent service request, the sent service request being a service request received by a to-be-tested service interface and having fed back a first response result; sending the sent service request to the to-be-tested service interface again until the number of sending reaches a preset threshold; judging whether each second response result corresponding to each sent service request sent again and fed back by the to-be-tested service interface is consistent, and determining the idempotency validity of the to-be-tested service interface according to the judgment result.

Description

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus and device for idempotency detection. Background Technology

[0002] During application runtime, situations frequently arise where a business request is submitted repeatedly. For example, this can occur when a user resubmits the request due to network failures preventing them from receiving a response, or due to frontend instability. To ensure proper application operation, it's essential to guarantee that executing one or more requests for a resource has the same impact on the requested resource; in other words, the application must be idempotent. Currently, testing the idempotency of an application typically involves manually identifying a business interface to be tested. Then, business requests already received and responded to by this interface are resent, and the response is received again. The idempotency of the interface is then manually analyzed and interpreted to determine its validity. This method is inefficient.

[0003] Therefore, there is a need to provide an idempotency validity detection scheme with high operating efficiency. Summary of the Invention

[0004] In view of this, embodiments of this application provide an idempotency validity detection method, apparatus, and device to address the need for a highly efficient idempotency validity detection scheme.

[0005] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows:

[0006] This specification provides an idempotency validity detection method, comprising:

[0007] Obtain the sent service request; the sent service request is a service request sent by the first application to the service interface under test of the second application, and the service interface under test has returned a first response result in response to the sent service request;

[0008] The previously sent service request is sent again to the service interface under test until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0009] Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent of the sent service request.

[0010] Determine whether the results of the various second responses are consistent to obtain the first determination result;

[0011] Based on the first judgment result, the idempotency validity of the service interface to be tested is determined.

[0012] An idempotency detection device provided in the embodiments of this specification includes:

[0013] The first acquisition module is used to acquire sent service requests; the sent service requests are service requests sent by the first application to the service interface under test of the second application, and the service interface under test has returned a first response result for the sent service requests;

[0014] The service request sending module is used to resend the already sent service request to the service interface under test until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0015] The second acquisition module is used to acquire each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resentment of the sent service request.

[0016] The first judgment module is used to determine whether the results of the various second responses are consistent, and to obtain the first judgment result;

[0017] The idempotency determination module is used to determine the idempotency of the service interface under test based on the first judgment result.

[0018] This specification provides an idempotency detection device, comprising:

[0019] At least one processor; and,

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0022] Obtain the sent service request; the sent service request is a service request sent by the first application to the service interface under test of the second application, and the service interface under test has returned a first response result in response to the sent service request;

[0023] The previously sent service request is sent again to the service interface under test until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0024] Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent of the sent service request.

[0025] Determine whether the results of the various second responses are consistent to obtain the first determination result;

[0026] Based on the first judgment result, the idempotency validity of the service interface to be tested is determined.

[0027] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0028] The process involves acquiring sent service requests—those that the service interface under test has received and responded with a first response to—and resending these requests to the service interface under test until a preset threshold is reached. It then determines whether the second response results from the service interface under test are consistent with those from each resent request. Based on the determination, the idempotency of the service interface under test is identified. This process eliminates the need for manual intervention, improving the efficiency of idempotency detection. Attached Figure Description

[0029] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0030] Figure 1 This is a flowchart illustrating an idempotency detection method provided in Embodiment 1 of this specification.

[0031] Figure 2 This is a flowchart illustrating a highly accurate idempotency validity detection method provided in Embodiment 2 of this specification.

[0032] Figure 3 The embodiment provided in this specification corresponds to Example 3. Figure 1 A schematic diagram of an idempotency validity detection device using Chinese methods;

[0033] Figure 4 This is a schematic diagram of the structure of an idempotency validity detection device provided in Embodiment 4 of this specification. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0036] Before describing the present invention, a brief explanation of the concepts involved in the present invention will be given first.

[0037] Idempotency (i.e., idempotency): This means that (except for errors or termination issues) executing the same request once or multiple times has the same effect. In other words, the effect of executing multiple identical requests on a resource is the same as the effect of executing a request on the resource only once.

[0038] Interface: In object-oriented programming languages, an interface is a relatively independent set of attributes and methods that can perform a specific function.

[0039] Interface recording and playback: Recording refers to recording the request operation behavior in the data link; playback refers to sending a request message that has been received by an interface back to the interface.

[0040] Business circuit breaking: After the target business is circuit broken, when a subsequent request to call the target business is received, the target business will no longer be called. Instead, the failure message of the target business call will be returned directly to quickly release resources.

[0041] As mentioned in the background section, current methods for testing the idempotency of applications rely on manual operation and analysis of response results. For example, in a payment scenario, to test the idempotency of a billing / charging application's (hereinafter referred to as "billing application") interface, staff need to extract a payment request that the interface has received and successfully processed from the application's historical messages, replay the request, and if the response from the interface corresponds to the replayed payment request, indicating that the application only deducted money from the user's account once, then the interface is considered idempotent. This method of idempotency testing based on manual operation and analysis is not only inefficient but also prone to misjudgment of the idempotency of the tested interface due to differing interpretations of the same response result by different staff members, or due to staff negligence or errors, thus affecting the accuracy of the test results.

[0042] To address this issue, the inventors noted that when a business request that has already been received and responded to by a certain business interface is replayed multiple times, if the business interface is idempotent, the response results from each replayed business request will be consistent. A digital comparison detection method can be used to compare each response result and obtain a comparison result regarding whether the response results are consistent. This method has high operating efficiency and provides a foundation for improving the detection efficiency of detection methods.

[0043] In view of this, the present invention proposes that, when detecting the idempotency of a service interface under test, service requests that have already been received and for which responses have been returned can be sent to the service interface under test multiple times. The idempotency of the service interface under test can be determined by judging whether the responses returned by the service interface under test are consistent with the responses corresponding to each of the resent service requests. This eliminates the need for manual intervention in the detection process and improves the efficiency of idempotency detection.

[0044] This concludes the brief explanation of the concepts involved in this invention and the basic principles of the embodiments thereof. The following will be combined with… Figures 1 to 4 The specific implementation process of the present invention will be further described in detail below.

[0045] Figure 1 This is a flowchart illustrating an idempotency detection method provided in Embodiment 1 of this specification. From a programming perspective, the execution entity of the process can be a detection application with idempotency detection functionality hosted on a server. This method can be applied to scenarios requiring idempotency detection of business interfaces under test, wherein the business interfaces under test include, but are not limited to, interfaces supporting Hypertext Transfer Protocol (HTTP) calls, interfaces supporting TR calls, or interfaces supporting Message calls. Figure 1 As shown, the process may include the following steps:

[0046] Step 101: Obtain the sent service request; the sent service request is the service request that the first application has sent to the test service interface of the second application, and the test service interface has returned a first response result for the sent service request.

[0047] In this embodiment, it is assumed that the second application is an application with an interface to the service under test. The first application is an application used to generate the sent service request. The first application can send the sent service request to the interface to be tested of the second application, and the testing application with idempotency detection function can obtain the sent service request from the second application. Specifically, the testing application can obtain all request parameters corresponding to the sent service request in order to resend the sent service request.

[0048] In practical applications, the detection application can first acquire service requests that the service interface under test has received but not responded to, and wait for the service interface under test to send back a first response result generated in response to the received but unresponded service request. At this time, the received but unresponded service request is the sent service request. The first response result can be information indicating that the received but unresponded service request was successfully processed.

[0049] Step 102: Send the previously sent service request to the service interface under test again until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0050] Step 103: Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent service request that was sent.

[0051] Step 104: Determine whether the results of each second response are consistent to obtain the first determination result.

[0052] Step 105: Determine the idempotency of the service interface under test based on the first judgment result.

[0053] In the embodiments of this specification, if the service interface under test of the second application is idempotent, then all the second response results should be consistent. Therefore, the idempotency validity detection result of the service interface under test can be obtained based on the first judgment result. Specifically, determining the idempotency validity of the service interface under test based on the first judgment result may include: determining that the service interface under test is idempotent when the first judgment result indicates that all the second response results are consistent; and determining that the service interface under test is not idempotent when the first judgment result indicates that all the second response results are inconsistent.

[0054] In Embodiment 1 of this specification, a sent service request refers to a service request that the service interface under test has received and has responded with a first response result. This sent service request is repeatedly sent to the service interface under test; it is then determined whether the second response results returned by the service interface under test are consistent with those corresponding to each subsequent sent service request. Based on the determination result, the idempotency validity of the service interface under test is determined. This eliminates the need for manual intervention in the detection process, thus improving the efficiency of idempotency validity detection.

[0055] based on Figure 1 The method described herein also provides some specific implementations of this method. For ease of description, the following example illustrates the specific implementation of this method by applying it to a scenario where idempotency validity checks are required on the charging interface in a billing application. It is understood that using this method to generate idempotency validity check results for the charging interface in a billing application is merely an illustrative example and should not be construed as a limitation of the method.

[0056] In one implementation of the embodiments of this specification, a method for obtaining sent service requests is provided. This implementation can be based on interface recording technology.

[0057] Specifically, obtaining the sent service requests may include: recording data of the service interface to be tested in the second application to obtain a recording file; and determining the sent service requests based on the recording file.

[0058] In the implementation of Embodiment 1 of this specification, the detection application with idempotency detection function has the function of recording and playing back the data transmitted by the interface. Specifically, the detection application can record the data transmitted by the test service interface of the second application within a certain period of time to obtain a recording file. The recording file includes the service request information received by the test service interface within a certain period of time and the response result information fed back by the test service interface.

[0059] In practical applications, a received and responded business request can be identified from the recording file as the sent business request. For example, suppose that when the detection application is recording the billing interface of the billing software, a user makes a payment using the client of the payment application software. Correspondingly, the payment application software sends a payment request to the billing interface of the billing software, instructing that 10 yuan be deducted from the user's payment account balance. The payment request is successfully processed, and the billing software sends a first response result back to the payment application software through the billing interface. Based on this application scenario, the resulting recording file can contain all the request parameters for the payment request instructing that 10 yuan be deducted from the user's payment account balance, as well as the first response result information generated for the payment request, including the payment order number and payment success identifier. In this case, according to the recording file, the payment request instructing that 10 yuan be deducted from the user's payment account balance can be identified as the sent business request.

[0060] Accordingly, this specification also provides an implementation method for resending the previously sent service request to the service interface under test in the embodiments. This implementation method can be based on interface replay technology.

[0061] Specifically, the step of resending the sent service request to the service interface under test until the number of times it is sent reaches a preset threshold may include: replaying the sent service request until the number of replays equals the preset threshold.

[0062] In the implementation of Embodiment 1 of this specification, all request parameters of the sent service request can be determined from the recording file. Based on these parameters, the sent service request can be replayed, thereby resending it to the service interface under test. Specifically, the sent service request can be replayed; each time the sent service request is replayed, the replay count is incremented by 1. It is then determined whether the replay count equals a preset threshold. If not, the replay of the sent service request continues until the replay count equals the preset threshold.

[0063] In practical applications, a preset threshold can be set according to actual needs. Specifically, the smaller the preset threshold, the higher the detection efficiency. Conversely, appropriately increasing the preset threshold can increase the number of obtained second response results, and the reliability of the detection results determined based on a larger number of second response results is also higher.

[0064] In the above implementation of Embodiment 1 of this specification, a method is provided based on the recording and playback technology of the interface to obtain the sent business requests and send the sent business requests to the business interface under test multiple times. This method has good versatility and can realize the multiple playback of the sent business requests without manual operation, which can improve the running efficiency of the idempotency validity detection method.

[0065] In practical applications, it is essential to ensure the idempotency of the service interface under test to guarantee the normal operation of the services it provides. When the service interface under test is not idempotent, measures must be taken to mitigate the risks and impacts arising from this lack of idempotency. Currently, handling service interfaces with operational risks typically relies on the experience of staff. This risk management approach is inefficient and suffers from low consistency and effectiveness due to its reliance on operator experience. Therefore, this specification provides several implementation methods for managing non-idempotent service interfaces under test to improve the operational efficiency of risk management. One implementation method is to directly generate instructions to disable the service interface under test; another method is to issue an alarm to control the disabling of the service interface under test through other applications.

[0066] In the first implementation described above, after the first judgment result indicates that the various second response results are inconsistent and it is determined that the interface under test is not idempotent, it may further include:

[0067] Generate a control instruction, which can be used to instruct the shutdown of a preset service interface, including the service interface to be tested or a service interface related to the service interface to be tested.

[0068] In the second implementation described above, after the first judgment result indicates that the various second response results are inconsistent and it is determined that the business interface under test is not idempotent, it may further include:

[0069] A first alarm message is generated, which can be used to indicate that the service interface under test is not idempotent.

[0070] The first alarm information is sent to the emergency management server so that the emergency management server can generate a management instruction based on the first alarm information. The management instruction can be used to instruct the shutdown of a preset service interface, which includes the service interface to be tested or a service interface related to the service interface to be tested.

[0071] In both implementation methods described above, disabling the preset service interface means that the preset service interface will no longer invoke the service requested by the subsequently received service request when a service request is received. The service interface related to the service interface under test can be a service interface related to the service provided by the service interface under test. For example, when the service interface under test is the billing interface of billing software, this billing interface provides billing services, and the service interfaces related to this billing service can also include the deduction interfaces of various banks.

[0072] Regarding the two implementation methods described above, in the first implementation method, the detection application automatically generates instructions to disable the service interface under test, thereby controlling the disabling of the non-idempotent service interface under test and / or related service interfaces. This control method is simple and effective. In the second implementation method, the detection application issues an alarm for non-idempotent service interfaces, allowing other applications to control the disabling of the service interface under test and / or related service interfaces. This reduces the complexity of the detection application and facilitates its development and maintenance.

[0073] The control instructions in the two implementation methods described above can correspond to various control methods. One method is to instruct the circuit breaker to interrupt the services provided by the preset service interface. Another method is to instruct the temporary suspension of processing service requests that the preset service interface has received but not yet responded to.

[0074] Specifically, "circuit breaking" means that when the preset service interface receives a subsequent service request, it can choose not to invoke the resource requested by the subsequent service request and instead directly return a request failure message. "Delaying processing of service requests received but not yet responded to by the preset service interface" means that when the preset service interface receives a subsequent service request, it can cache the received service request and then process the cached service request after receiving permission to process it, thereby delaying the processing of service requests received but not yet responded to by the preset service interface.

[0075] In practical applications, the control command can be used to instruct the same control method to be applied to all preset service interfaces, or it can be used to instruct different control methods to be applied to different preset service interfaces. Specifically, the control method of the control command for each preset service interface can be determined according to actual needs. For example, the control method of the control command can be determined according to the response level of each preset service interface. For example, it is assumed that the lower the response level of the preset service interface, the shorter the maximum allowed response time. If the maximum allowed response time for a preset service interface with a response level of 1 is 1 second, and the maximum allowed response time for a preset service interface with a response level of 2 is 2 minutes, to ensure that the service requests received by the test service interface with a response level of 1 (which is not idempotent) are responded to within the allowed response time limit, and that the received service requests are not further processed, the control command can instruct the circuit breaker to suspend the service provided by the test service interface; at this time, the control command can also be used to instruct the circuit breaker to suspend other preset service interfaces with a response level of 2, or the control command can also be used to instruct the temporary suspension of processing other preset service interfaces with a response level of 2.

[0076] The above implementation provides multiple control methods for control commands. By circuit breaking the services provided by the preset service interface, the preset service interface can quickly provide response information without processing subsequent received service requests. This reduces the risk caused by the non-idempotency of the service interface under test, quickly releases resources to avoid resource exhaustion in the application system where the preset service interface is located, and reduces the waiting time for users to receive the response results, thus improving the user experience. By temporarily suspending the processing of service requests received but not yet responded to by the preset service interface, and responding to the suspended service requests when conditions permit later, the service request failure rate can be reduced, ensuring the stability of service operation and improving users' evaluation of the operational stability of the application where the preset service interface is located.

[0077] In practical applications, factors such as network jitter may cause the interface under test to respond abnormally to a resentment of the previously sent service request. In this case, the second response result from the interface under test cannot be used to determine the idempotency of the interface under test. If the second response result indicating abnormal response generated by factors such as network jitter is not distinguished, the accuracy of the idempotency validity detection result will be affected. Therefore, Embodiment 2 of this specification also proposes a more accurate idempotency validity detection method, such as... Figure 2 As shown, this method includes the following steps:

[0078] Step 201: Obtain the sent service request; the sent service request is the service request that the first application has sent to the test service interface of the second application, and the test service interface has returned a first response result for the sent service request.

[0079] Step 202: Send the previously sent service request to the service interface under test again until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0080] Step 203: Obtain each second response result fed back by the interface of the service to be tested. The second response result is the response result generated by the second application in response to the resent service request that was sent.

[0081] Step 204: Determine the result type of each second response result; the result type includes at least one of the following: business request processing success type, business request processing failure type, or business request processing exception type.

[0082] Step 205: Determine whether the number of second response results with the result type of business request processing exception is zero, and obtain the second judgment result.

[0083] Step 206: When the number of second response results indicating that the result type is business request processing exception is zero, determine whether the various second response results are consistent to obtain the first judgment result. When the first judgment result indicates that the various second response results are consistent, proceed to step 208; when the first judgment result indicates that the various second response results are inconsistent, proceed to step 209.

[0084] Step 207: When the number of second response results indicating that the result type is a business request processing exception type is not zero, the current idempotency validity test is determined to be invalid.

[0085] Step 208: Determine that the interface to be tested is idempotent.

[0086] Step 209: Determine that the interface to be tested is not idempotent.

[0087] In Embodiment 2 of this specification, the implementation methods of steps 201-203, 206, and 208-209 are the same as those of steps 101-105 in Embodiment 1, and will not be repeated here.

[0088] The second response result with the result type of "business request processing success" is information indicating that the sent business request has been successfully processed. For example, for a payment application software sending a payment request again to the billing software's billing interface, the second response result with the result type of "business request processing success" can contain information including the payment order number and payment success identifier.

[0089] The second response result, which is of the business request processing failure type, is used to indicate that the processing of the sent business request failed due to abnormal request parameters or a failure of the application to which the business interface under test belongs. For example, the second response result may be information indicating that the payment failed because the payment amount exceeded the single transaction limit of the user account.

[0090] The second response result, which is of the type "Business Request Processing Exception", is information indicating that the sent business request cannot be processed due to factors such as network failure. For example, the second response result may contain information including an unknown error identifier or a network fault code.

[0091] In practical applications, it is assumed that the previously sent service request is resent twice, resulting in two second response results. If the first second response result indicates that the resource requested by the previously sent service request was processed only once, analysis of the first second response result shows that the service interface under test is idempotent. The second second response result indicates that a network jitter fault has occurred. In this application scenario, because the two second response results are inconsistent, if the method in Embodiment 1 is used to determine the service interface under test, it will incorrectly determine that the service interface under test is not idempotent. However, in Embodiment 2, by identifying the result type of each second response result, when there is a second response result with the result type of a service request processing exception, the idempotency validity test is determined to be invalid, which can improve the accuracy of the idempotency validity test result of the service interface under test.

[0092] Since it is generally necessary to ensure that the success rate of processing each business request is not lower than the target value, if the result type of the second response is a business request processing failure type, then the operational stability of the business interface under test is at risk. Based on this, this specification also provides an implementation method that is conducive to improving the operational stability of the business interface under test.

[0093] Specifically, after step 206 or step 208, the following steps may also be included:

[0094] The third judgment result is obtained by determining whether the number of second response results of the result type "business request processing failure" is zero.

[0095] When the number of second response results indicating that the result type is business request processing failure is not zero, a second alarm message is generated. The second alarm message is used to indicate that there is a risk to the stability of the business interface under test.

[0096] In the implementation of Embodiment 2 of this specification, when there is a second response result of the type of business request processing failure, an alarm is triggered to indicate that there is a risk to the stability of the business interface under test, which can facilitate the improvement of the operational stability of the business interface under test and its application.

[0097] In practical applications, the detection process requires manual initiation, which is time-consuming and results in poor timeliness. Furthermore, the need for manual identification of newly added service interfaces to be tested makes them prone to being missed. Therefore, this specification also provides some specific implementation methods based on Embodiment 1 or Embodiment 2 to improve the timeliness of detecting service interfaces to be tested.

[0098] Specifically, before step 101 or step 201, the process may include: obtaining a newly added service interface to be tested; and adding the newly added service interface to be tested to the list of service interfaces to be tested.

[0099] The step of obtaining the sent service request may specifically include: obtaining the sent service request from one of the service interfaces to be tested in the list of service interfaces to be tested according to a preset period.

[0100] In practical applications, newly added service interfaces to be tested can be automatically acquired and added to the list of service interfaces to be tested. According to a preset period, a testing task is established for each service interface to be tested in the list. When the testing task is started, the idempotency validity testing steps in Embodiment 1 or Embodiment 2 are executed to test the service interface to be tested.

[0101] In this implementation, each business interface to be tested is automatically tested periodically according to a preset period, without the need for manual intervention, which can improve the testing efficiency and real-time performance.

[0102] Specifically, the step of obtaining the interface for newly added services to be tested may include:

[0103] Obtain a first set of applications from the application management server. The first set of applications includes a second application and a third application. The second application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested. The third application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested.

[0104] Based on the list of service interfaces to be tested, a second application set is determined, and the second application set includes the second application.

[0105] Based on the second set of applications, a third set of applications is determined from the first set of applications, the third set of applications including the third application.

[0106] The business interfaces to be tested in all applications in the third application set are identified as newly added business interfaces to be tested.

[0107] In the above implementation of obtaining the interface for newly added services to be tested, the application management server is used to manage applications that need to undergo idempotency testing. Specifically, applications undergoing idempotency testing can connect to the application management server so that the testing application can obtain information about the applications requiring idempotency testing from the application management server, thus obtaining a first set of applications.

[0108] The testing application can record the applications belonging to the business interfaces under test for which testing tasks have been established, as the applications in the second application set. The third application set is determined by taking the difference between the first and second application sets.

[0109] In practical applications, the business interfaces to be tested from all applications in the third application set can be identified as new business interfaces to be tested. For example, when the applications in the third application set use the Spring framework, the Servlet layer interfaces of all applications in the third application set can be identified as new business interfaces to be tested to ensure the comprehensiveness of the acquired new business interfaces to be tested.

[0110] The above implementation method can automatically identify newly added business interfaces to be tested without manual analysis, has good real-time performance, and obtains a relatively comprehensive list of newly added business interfaces to be tested.

[0111] Based on the same idea, Embodiment 3 of this specification also provides an apparatus corresponding to the above method. Figure 3 The embodiment provided in this specification corresponds to Example 3. Figure 1 A schematic diagram of an idempotency validity detection device using Chinese methods. Figure 3 As shown, the device may include:

[0112] The first acquisition module 301 is used to acquire the sent service request; the sent service request is a service request sent by the first application to the test service interface of the second application, and the test service interface has returned a first response result for the sent service request.

[0113] The service request sending module 302 is used to send the already sent service request to the service interface under test again until the number of sending times reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0114] The second acquisition module 303 is used to acquire each second response result fed back by the service interface under test. The second response result is the response result generated by the second application in response to the resent service request that has already been sent.

[0115] The first judgment module 304 is used to determine whether the various second response results are consistent, and to obtain the first judgment result.

[0116] The idempotency determination module 305 is used to determine the idempotency of the service interface under test based on the first judgment result.

[0117] In Embodiment 3 of this specification, the service request sending module 302 repeatedly sends the previously sent service request to the service interface under test; the first judgment module 304 judges whether the feedback from the service interface under test is consistent with the second response results corresponding to each of the previously sent service requests, so that the idempotency determination module 305 can determine the idempotency of the service interface under test based on the judgment results. This idempotency detection device does not require manual intervention in the detection process, which can improve the efficiency of idempotency detection.

[0118] In Embodiment 3 of this specification, the first acquisition module 301 can be used to record data of the business interface to be tested of the second application to obtain a recording file; and to determine the sent business requests based on the recording file.

[0119] In Embodiment 3 of this specification, the device may further include: an alarm information generation module and a first alarm information sending module.

[0120] The alarm information generation module can be used to generate a first alarm information when the first judgment result indicates that the various second response results are inconsistent and it is determined that the service interface under test is not idempotent. The first alarm information is used to indicate that the service interface under test is not idempotent.

[0121] The first alarm information sending module can be used to send the first alarm information to the emergency management server, so that the emergency management server can generate a management instruction based on the first alarm information. The management instruction is used to instruct the shutdown of a preset service interface, which includes the service interface to be tested or a service interface related to the service interface to be tested.

[0122] In Embodiment 3 of this specification, the apparatus may further include a control instruction generation module. The control instruction generation module is used to generate a control instruction when the first judgment result indicates that the various second response results are inconsistent, and it is determined that the service interface under test is not idempotent. The control instruction is used to instruct the disabling of a preset service interface, which includes the service interface under test or a service interface related to the service interface under test.

[0123] In Embodiment 3 of this specification, the device may further include: a result type determination module, a second judgment module, and a detection invalidity determination module.

[0124] The result type determination module can be used to: determine the result type of each second response result; the result type includes at least one of the following: business request processing success type, business request processing failure type, or business request processing exception type.

[0125] The second judgment module can be used to: determine whether the number of second response results of the result type being a business request processing exception type is zero, and obtain the second judgment result.

[0126] The invalid detection determination module can be used to determine that the current idempotency validity detection is invalid when the number of second response results indicating that the result type is a business request processing exception type is not zero.

[0127] In Embodiment 3 of this specification, the device may further include: a third judgment module and a second alarm information generation module.

[0128] The third judgment module can be used to determine whether the number of second response results with the result type of business request processing failure is zero, and obtain the third judgment result.

[0129] The second alarm information generation module can be used to generate a second alarm information when the number of second response results indicating that the result type is business request processing failure is not zero, and the second alarm information is used to indicate that there is a risk to the stability of the business interface under test.

[0130] In Embodiment 3 of this specification, the device may further include: a third acquisition module and an addition module.

[0131] The third acquisition module can be used to acquire newly added business interfaces to be tested.

[0132] The addition module can be used to add the newly added business interface to be tested to the list of business interfaces to be tested.

[0133] Specifically, the first acquisition module can be used to: acquire sent service requests from one of the service interfaces to be tested in the list of service interfaces to be tested according to a preset period.

[0134] In Embodiment 3 of this specification, the third acquisition module can specifically be used for:

[0135] Obtain a first set of applications from the application management server. The first set of applications includes a second application and a third application. The second application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested. The third application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested.

[0136] Based on the list of service interfaces to be tested, a second application set is determined, and the second application set includes the second application.

[0137] Based on the second set of applications, a third set of applications is determined from the first set of applications, the third set of applications including the third application.

[0138] The business interfaces to be tested in all applications in the third application set are identified as newly added business interfaces to be tested.

[0139] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments. Figure 4 This is a schematic diagram of the structure of an idempotency detection device provided in Embodiment 4 of this specification. Figure 4 As shown, the device 400 may include:

[0140] At least one processor 410; and,

[0141] Memory 430 communicatively connected to the at least one processor; wherein,

[0142] The memory stores instructions 420 that can be executed by the at least one processor 410, the instructions being executed by the at least one processor 410 to enable the at least one processor 410 to:

[0143] Obtain the sent service request; the sent service request is the service request that the first application has sent to the service interface under test of the second application, and the service interface under test has returned a first response result in response to the sent service request.

[0144] The previously sent service request is sent again to the service interface under test until the number of times it is sent reaches a preset threshold, wherein the preset threshold is greater than or equal to 2.

[0145] Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent of the previously sent service request.

[0146] Determine whether the results of the various second responses are consistent to obtain the first determination result.

[0147] Based on the first judgment result, the idempotency validity of the service interface to be tested is determined.

[0148] In Embodiment 4 of this specification, the idempotency detection device repeatedly sends the previously sent service request to the service interface under test; it then determines whether the second response results returned by the service interface under test are consistent with the results of each subsequent resentment of the previously sent service request, and determines the idempotency of the service interface under test based on the determination results. This eliminates the need for manual intervention in the detection process, thus improving the efficiency of idempotency detection.

[0149] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0150] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0151] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0152] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

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

[0154] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0155] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0156] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0157] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0158] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0159] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0160] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0162] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0163] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for detecting idempotency, comprising: The detection application retrieves the sent business requests; The sent service request is a service request that the first application has sent to the test service interface of the second application; The detection application has idempotency detection capabilities as well as the ability to record and play back data transmitted through the interface; the sent service requests are determined based on the recorded files. The recording file is obtained by recording the data of the service interface to be tested. The second application includes billing application software; the service interface to be tested includes a billing interface; the service request includes a payment request. The previously sent service request is resent to the service interface under test until the number of resentments reaches a preset threshold, wherein the preset threshold is greater than or equal to 2. Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent of the sent service request. Determine whether the results of the various second responses are consistent to obtain the first determination result; Based on the first judgment result, the idempotency validity of the service interface to be tested is determined.

2. The method as described in claim 1, wherein obtaining the sent service request specifically includes: Record the data of the business interface to be tested in the second application to obtain a recording file; Based on the recorded file, determine the sent service requests.

3. The method as described in claim 1, further comprising, after the first determination result indicates that the various second response results are inconsistent and it is determined that the interface under test does not have idempotency, the method includes: Generate a control instruction, which is used to instruct the disabling of a preset service interface, including the service interface to be tested or a service interface related to the service interface to be tested.

4. The method as described in claim 1, further comprising, after the first determination result indicates that the various second response results are inconsistent and it is determined that the interface under test does not have idempotency, the method includes: Generate a first alarm message, which indicates that the service interface under test is not idempotent; The first alarm information is sent to the emergency management server so that the emergency management server can generate a management instruction based on the first alarm information. The management instruction is used to instruct the shutdown of a preset service interface, which includes the service interface to be tested or a service interface related to the service interface to be tested.

5. The method as described in claim 3 or 4, wherein the control instruction is specifically used to instruct the circuit breaker to disconnect the service provided by the preset service interface; Alternatively, the control instruction may be specifically used to instruct the temporary suspension of processing of business requests that have been received but not responded to by the preset business interface.

6. The method of claim 1, further comprising, before determining whether the respective second response results are consistent: Determine the result type of each of the second response results; The result type includes at least one of the following: business request processing success type, business request processing failure type, or business request processing exception type. Determine whether the number of second response results with the result type of business request processing exception is zero, and obtain the second judgment result; When the number of second response results indicating that the result type is business request processing exception is zero, determine whether the various second response results are consistent; When the number of second response results indicating that the result type is a business request processing exception is not zero, the current idempotency validity test is determined to be invalid.

7. The method of claim 6, further comprising, after the first determination result indicates that the various second response results are consistent and the test service interface is determined to be idempotent, the method includes: The third judgment result is obtained by determining whether the number of second response results with the result type of business request processing failure is zero; When the number of second response results indicating that the result type is business request processing failure is not zero, a second alarm message is generated. The second alarm message is used to indicate that there is a risk to the stability of the business interface under test.

8. The method of claim 1, further comprising: Get the newly added business interfaces to be tested; Add the newly added service interface to be tested to the list of service interfaces to be tested; The process of obtaining the sent service requests specifically includes: According to a preset period, the sent service request is obtained from one of the service interfaces to be tested in the list of service interfaces to be tested.

9. The method as described in claim 8, wherein obtaining the newly added service interface to be tested specifically includes: Obtain a first application set from the application management server. The first application set includes a second application and a third application. The second application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested. The third application is the application to which the business interface to be tested belongs in the list of business interfaces to be tested. Based on the list of service interfaces to be tested, a second application set is determined, and the second application set includes the second application. Based on the second set of applications, a third set of applications is determined from the first set of applications, the third set of applications including the third application; The business interfaces to be tested in all applications in the third application set are identified as newly added business interfaces to be tested.

10. An idempotency detection device, comprising: The first acquisition module is used to enable the detection application to acquire the sent business requests; The sent service request is a service request that the first application has sent to the test service interface of the second application; The detection application has idempotency detection capabilities as well as the ability to record and play back data transmitted through the interface; the sent service requests are determined based on the recorded files. The recording file is obtained by recording the data of the service interface to be tested. The second application includes billing application software; the service interface to be tested includes a billing interface; the service request includes a payment request. The service request sending module is used to resend the sent service request to the service interface under test until the number of resends reaches a preset threshold, wherein the preset threshold is greater than or equal to 2. The second acquisition module is used to acquire each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resentment of the sent service request. The first judgment module is used to determine whether the results of the various second responses are consistent, and to obtain the first judgment result; The idempotency determination module is used to determine the idempotency of the service interface under test based on the first judgment result.

11. The apparatus of claim 10, further comprising: An alarm information generation module is used to generate a first alarm information when the first judgment result indicates that the various second response results are inconsistent and it is determined that the service interface under test does not have idempotency. The first alarm information is used to indicate that the service interface under test does not have idempotency. The first alarm information sending module is used to send the first alarm information to the emergency management server, so that the emergency management server can generate a management instruction based on the first alarm information. The management instruction is used to instruct the shutdown of a preset service interface, which includes the service interface to be tested.

12. The apparatus of claim 10, further comprising: The result type determination module is used to determine the result type of each of the second response results; The result type includes at least one of the following: business request processing success type, business request processing failure type, or business request processing exception type. The second judgment module is used to determine whether the number of second response results with the result type of business request processing exception is zero, and to obtain the second judgment result; The invalid detection determination module is used to determine that the current idempotency validity detection is invalid when the number of second response results indicating that the result type is a business request processing exception is not zero.

13. The apparatus of claim 12, further comprising: The third judgment module is used to determine whether the number of second response results with the result type of business request processing failure is zero, and to obtain the third judgment result; The second alarm information generation module is used to generate a second alarm information when the number of second response results indicating that the result type of the third judgment result is business request processing failure is not zero. The second alarm information is used to indicate that there is a risk to the stability of the business interface under test.

14. The apparatus of claim 10, further comprising: The third acquisition module is used to acquire newly added business interfaces to be tested. An add module is used to add the newly added service interface to be tested to the list of service interfaces to be tested; The first acquisition module is specifically used to: acquire sent service requests from one of the service interfaces to be tested in the list of service interfaces to be tested according to a preset period.

15. The apparatus of claim 14, wherein the third acquisition module is specifically used for: Obtain a first set of applications from the application management server, the first set of applications including: The second application and the third application, wherein the second application is the application to which the service interface to be tested belongs in the list of service interfaces to be tested, and the third application is the application to which the service interface to be tested belongs in the list of service interfaces to be tested to be added; Based on the list of service interfaces to be tested, a second application set is determined, and the second application set includes the second application. Based on the second set of applications, a third set of applications is determined from the first set of applications, the third set of applications including the third application; The business interfaces to be tested in all applications in the third application set are identified as newly added business interfaces to be tested.

16. An idempotency validity detection device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: The detection application acquires sent service requests; the sent service requests are service requests sent by the first application to the service interface under test of the second application; the detection application has idempotency detection functions and the function of recording and playing back the data transmitted through the interface; the sent service requests are determined based on a recording file; the recording file is obtained by recording the data of the service interface under test; the second application includes billing application software; the service interface under test includes a billing interface; the service requests include payment requests; The previously sent service request is resent to the service interface under test until the number of resentments reaches a preset threshold, wherein the preset threshold is greater than or equal to 2. Obtain each second response result fed back by the interface of the service under test. The second response result is the response result generated by the second application in response to the resent of the sent service request. Determine whether the results of the various second responses are consistent to obtain the first determination result; Based on the first judgment result, the idempotency validity of the service interface to be tested is determined.

Images