WO2016169420A1

WO2016169420A1 - Method, device and system for querying service request execution state

Info

Publication number: WO2016169420A1
Application number: PCT/CN2016/079050
Authority: WO
Inventors: 黄孟俊; 姬广军
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2015-04-20
Filing date: 2016-04-12
Publication date: 2016-10-27
Also published as: CN106156185B; CN106156185A

Abstract

Disclosed is a method for querying a service request execution state, the method satisfying different time limit requirements for obtaining an execution state of different services having an unclear state. The method comprises: obtaining an identifier code and service characteristic of the service having an unclear state; and querying, according to the service characteristic and by utilizing the identifier code, the execution state of the service having an unclear state. Also disclosed in the present application are a device and system for querying the service request execution state.

Description

Method, device and system for querying service request execution status

The present application claims priority to Chinese Patent Application No. 201510189103.1, entitled "Inquiring Method, Apparatus and System for Execution Status of Business Requests", filed on April 20, 2015, the entire contents of which are incorporated herein by reference. In the application.

Technical field

The present application relates to the field of computer technologies, and in particular, to a method, device, and system for querying a service request execution state.

Background technique

With the booming Internet, more and more Internet service requests and systems for executing business requests have emerged. The system that sends the service request can be referred to as the business system, and the system that executes the service request is called the execution system. Usually, the service system sends the service request to the execution system. After the execution system performs the service request, the service system returns a clear execution status to the service system, and the execution status may be completion or failure. However, due to network reasons or two system reasons, the execution system may not send an execution status to the service system, or the service system does not receive the execution status of the service request, or the execution system sends an execution status to the service system that the service request is unclear ( As in the process, it causes the business system to not know whether the execution status of the service request is successful. This kind of situation that does not know whether the execution status of the service request is successful can be called a dropout. It can be considered that any execution without clearing the service request can be considered. The status (including the execution status with unclear business request) is the execution status without obtaining the service request; the business request for the lost order can be called the lost order service. After the order is deleted, you need to query the execution status of the single service.

In the prior art, the method for querying the execution status of a single service is that the service system periodically sends a query request to the execution system for the execution status of the lost service within a certain period of time. For example, the service system sends some query requests for the execution status of the lost order to the execution system every 1 minute to obtain the execution status of these lost orders.

At present, the business of different types of business, often have different requirements for obtaining the corresponding execution time limit. For example, some of the lost orders need to get the execution status within 10 seconds after the order is dropped, and some of the lost orders require the execution status within 2 minutes after the order is placed. However, if the method of dropping the execution status of a single service according to the existing query is queried according to the order of the services to be logged out, there may be a time limit that cannot satisfy the execution status of the lost service. For example, in order of succession, it is found that the single business 1 (referred to as 1) and the single business Service 2 (referred to as 2), lost order service 3 (referred to as 3), lost order service 4 (referred to as 4), if the execution status of these lost orders is queried twice, the first query 1 and 2, the second time Query 3 and 4, however, in actual cases, the time limit for obtaining 1, 2, 3, and 4 execution states is 1 minute, 5 seconds, 5 seconds, and 1 minute, respectively, since they are queried in order, so It may cause the time limit for obtaining the 3 execution state to be unsatisfied.

Summary of the invention

The embodiment of the present application provides a method for querying the execution status of a service request, which is used to meet different time limit requirements for different release services to obtain an execution status.

The embodiment of the present application provides a query device for performing a service request execution state, which is used to meet different time limit requirements for different release services to obtain an execution state.

The embodiment of the present application provides an inquiry system for the execution status of a service request, which is used to meet different time limit requirements for different cancellation services to obtain an execution status.

The embodiments of the present application adopt the following technical solutions:

A method for querying a service request execution state includes: obtaining an identification code and a service feature of a single service; and using the identification code to query an execution status of the lost service according to the service feature.

An apparatus for querying a service request execution state, comprising: an obtaining unit, configured to acquire an identification code and a service feature of a single service, and a query unit, configured to use the identifier code to query a single service according to the service feature Execution status.

An inquiry system for a service request execution state, comprising: a service system, configured to: send an identification code and a service feature of a lost service to an inquiry system; and the query system is configured to: receive an identification code of the lost service sent by the service system And the service feature; according to the service feature, using the identifier code to query the execution status of the lost service.

The above at least one technical solution adopted by the embodiment of the present application can achieve the following beneficial effects:

The performance of the single service can be queried according to the service characteristics, and the service feature can represent the time limit of the service to obtain the execution status. Therefore, the technical solution can support the task of optimizing the query and the single service according to the different time limit requirements, and the difference is satisfied. The drop-off service requires different time limits for the execution status.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the present application, and are intended to be a part of this application. In the drawing:

FIG. 1 is a flowchart showing a specific implementation process of a method for querying a service request execution state according to Embodiment 1 of the present application. intention;

2 is a schematic structural diagram of a device for querying a service request execution state according to Embodiment 2 of the present application;

3 is a schematic structural diagram of an inquiry system for a service request execution state according to Embodiment 3 of the present application;

FIG. 4 is a schematic flowchart of a payment service according to Embodiment 4 of the present application.

detailed description

The technical solutions of the present application will be clearly and completely described in the following with reference to the specific embodiments of the present application and the corresponding drawings. It is apparent that the described embodiments are only a part of the embodiments of the present application, and not all of them. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Example 1

The embodiment 1 provides a query method for the execution status of the service request, which is used to meet different time limit requirements for different order-issuing services for obtaining the execution status. A schematic diagram of the specific process of the method is shown in FIG. 1 and includes the following steps:

In step 11, the identification code and the service feature of the single service are obtained.

The lost order service may be determined by judging whether the execution status (success or failure) of the service request is received. For example, if the service request 1 is sent but the execution status of the service request 1 is not received, or the execution status of the service request 1 is "in process", it can be determined that the service request 1 has a lost order. The identification code of the lost service is a unique identifier indicating a service request for the lost order. For example, the serial number of the business request, etc. The service feature is a feature that indicates a service request that has a lost order. For the step 11, the service feature may include, but is not limited to, any information that can identify the time limit requirement for the single service to obtain the corresponding execution state, and may include, for example, At least one of the following:

Business type; business size; user level corresponding to the service; and so on.

Specifically, the service type may include at least one of the following: an online service type; an offline business type. The offline service requires a higher time limit for obtaining the execution status of the lost order service (within 10 seconds). Therefore, if the order is lost, the execution status of the single service needs to be queried immediately, and the query result is fed back to the user; The time limit requirement for obtaining the execution status of the lost service is not necessarily too high (within 2 minutes), so if there is a lost order, it may not be necessary to feedback the execution status to the user in a very timely manner compared to the offline service (2 minutes) Feedback to the user can be). Therefore, different service types have different time limits for obtaining the execution status of the lost service.

Business size can refer to the amount of execution in a business. For example, how much is the volume of goods traded, the amount of trading Size and so on. In the actual situation, for large-scale businesses (such as the flow of funds of more than 10,000 yuan), users are more worried about whether they are successfully completed. Therefore, if there is a loss, the execution status of the single service needs to be queried as soon as possible so that timely feedback can be given. Users; but for small-scale businesses (such as the flow of funds below 500 yuan) users are not very worried, if there is a dropout, feedback to the user's execution status within a few minutes. Therefore, different service scales have different time limits for obtaining the execution status of the lost service.

The user level corresponding to the service may be the level of the user who sent the service request. The level here may include, for example, a Very Important Person (VIP) level, a general level, and the like. In the actual situation, if the service request of the user of the VIP level appears to be lost, the execution status of the single service can be queried as soon as possible (for example, within 5 seconds); and for the user of the ordinary level, if the service request is lost, The execution status of the service can be fed back to the user within a few minutes.

In this step, the identification code and the service feature of the lost service may be obtained from the terminal or obtained from the server.

Step 12: Query the execution status of the single service by using the identification code according to the service feature.

As shown in step 11, the lost order service with different service characteristics has different time limit requirements for obtaining the corresponding execution status. Therefore, for step 12, querying the execution status of the lost service according to the service feature may include: determining the time limit requirement of the lost service according to the service feature; and using the identification code to query the lost order according to the time limit requirement The execution status of the business.

Specifically, according to different service characteristics, the time limit requirement for the single service is determined first. For example, the online business is a small amount. If there is a lost order, you can set the execution status of the single business within 1 minute, and then feed the query result back to the user; for example, use mobile The terminal pays 5,000 yuan for this service, which is offline business, and it is a large amount. If there is a lost order, it needs to set the execution status of the single-off service within 10 seconds, and feedback the query result in time. user. After determining the time limit requirement for the outgoing service, the identity of the lost service is used to query the execution status of the lost service according to the time limit requirement.

In actual applications, there may be many lost orders in the cache for the execution status of the query. Therefore, after each time obtaining the identification code and the service feature of the new lost service, the time limit of the newly acquired lost service can be determined first, and then all the execution states to be queried are adjusted according to the time limit requirement. The order of query for a single business. For example, there are a single service A (abbreviated as A), a single-off service B (abbreviated as B), and a single-off service C in the cache, according to the service characteristics of the three lost services (A and B are offline services, C is a line) On the service, you can find the time limit for obtaining the execution status of the three lost orders according to the mapping table of service characteristics and time limit in Table 1 below: 10 seconds, 10 seconds, 1 minute, and the next 5 seconds. In the task of querying the single business execution status, the query will be queried simultaneously. The execution status of A and B. Now, the new lost order service D (referred to as D) is obtained, and the time limit for obtaining the execution status of D (offline service) is also 10 seconds, so the task of querying the single business execution status in the next 5 seconds is performed. In the middle, the execution status of A, B, and D will be queried at the same time.

业务特征Business characteristics	时限要求Time limit requirement
线下业务Offline business	10秒10 seconds
线上业务Online business	1分钟1 minute

Table 1

To avoid the network congestion caused by a large number of queries or queries, the execution status of the single-service service may include at least one of the following: querying the execution status of the single-traffic service according to the set period; The query rule of the lost order service, querying the execution status of the lost service.

Specifically, in order to avoid network congestion caused by querying a lot of lost services at a time, the execution status of the lost service may be queried each time according to the query rule of the specified number of lost transactions. For example, in order to ensure the smooth flow of the network and the stable performance of the computing power, the query rule may be an execution state of querying 10 lost transactions each time. To avoid network congestion caused by frequent queries, you can query the execution status of the lost service according to the set period. For example, in order to ensure the smooth flow of the network and the stable performance of computing power, query every 10 seconds. While avoiding network congestion, it also better meets the needs of users.

In practical applications, step 12 can be flexibly executed according to some query rule. For example, determine 100 time-out services that need to obtain an execution status within 10 seconds, and determine the time-out sequence of the 100-time-down transactions according to the time-out requirements for determining the status of each of the lost orders (and the time limit for obtaining the status of each lost order service). The order is divided into 4 times, and the execution status of the top 25 lost orders is queried every 2.5 seconds until the 100 lost orders are queried in 10 seconds.

In an implementation manner, in order to complete the feedback on the execution status of the lost service, the method may further include:

Step 13: Modify the execution status of the service request according to the execution status of the queried order service.

For step 13, when the service request is lost, there is no execution status. Therefore, according to the execution status of the lost service that is queried in step 12, the execution status of the service request may be modified, and the executed execution status may be queried. It is completed, failed, or processed.

With the method provided in Embodiment 1, since the execution status of the single service can be queried according to the service feature, the task of querying the single service can be optimized according to different time limit requirements, thereby satisfying the different execution status of the lost business. Different time limits.

It should be noted that the execution bodies of the steps of the method provided in Embodiment 1 may all be the same device, or the steps of the method may also be performed by different devices. For example, the execution body of

steps

11 and 12 It may be device 1; for example, the execution body of step 11 may be device 1, the execution body of step 12 and may be device 2;

Example 2

Based on the same inventive concept, the embodiment 2 provides a querying device for the service request execution state, which is used to meet different time limit requirements for different order-issuing services to obtain an execution state. As shown in Figure 2, the device comprises:

The obtaining unit 21 is configured to obtain an identification code and a service feature of the single service.

The querying unit 22 may be configured to query, according to the service feature, the execution status of the lost service by using the identifier code.

In an embodiment, the device further comprises:

The modifying unit 23 can be configured to modify the execution status of the service request according to the execution status of the queried order service.

In an implementation manner, the query unit 22 may be configured to: determine, according to the service feature, a time limit requirement for the lost service; and use the identifier code to query the execution status of the lost service according to the time limit requirement.

In an embodiment, the service feature may include at least one of the following: a service type; a service size; and a user level corresponding to the service.

In an embodiment, the service type may include at least one of the following: an online service type; an offline business type.

In an embodiment, the query unit 22 is configured to perform at least one of the following operations: querying the execution status of the single service according to the time period; and querying the execution status of the single service according to the fixed number.

With the device provided in Embodiment 2, since the execution status of the single service can be queried according to the service feature, the task of querying the single service can be optimized according to different time limit requirements, thereby satisfying the different execution status of the lost service. Different time limits.

Example 3

Based on the same inventive concept, the embodiment 3 provides an inquiry system for the execution status of the service request, which is used to meet different time limit requirements for different release orders for obtaining the execution status. As shown in Figure 3, the system includes:

The service system 31 may be configured to: send the identifier of the lost service and the service feature to the query system;

The querying system 32 can be configured to: receive an identification code and a service feature of the lost service sent by the service system; and use the identification code to query the execution status of the lost service according to the service feature.

In an embodiment, the querying system 32 is further configured to modify the execution status of the service request in the service system 31 according to the execution status of the logged-out service.

In an embodiment, the query system 32 is further configured to: send the executed execution status of the logged-out service to the service system 31.

In an embodiment, the service system 31 is further configured to: receive an execution status of the lost service queried by the query system 32; and modify an execution status of the single service.

It should be noted that the service system 31 and the query system 32 mentioned in Embodiment 3 may be two separate systems in the same device, or two separate modules in the same system;

With the system provided in Embodiment 3, since the execution status of the single service can be queried according to the service characteristics, the task of querying the single service can be optimized according to different time limit requirements, thereby satisfying the different execution status of the lost business. Different time limits.

Example 4

Based on the same inventive concept, the embodiment 4 provides a query method for the execution status of the payment service, which is used to meet different time limit requirements for different offline transactions for obtaining the execution status, and provides a better payment experience for the user. A schematic diagram of the method is shown in Figure 4 and includes the following steps:

Step 41: Send 5 payment services (payment service A, payment service B, payment service C, payment service D, payment service E) to the banking system;

Step 42: The execution status of the three payment services, namely, the payment service B, the payment service C, and the payment service E, is received, and all three are successful.

Step 43: Since the execution status of the payment service A and the payment service D is not received, it is determined that the payment service A and the payment service D have a lost order, and the lost order service A (referred to as A) and the lost order service D (referred to as D) are determined. ).

In step 44, according to the service characteristics of A and D, respectively, the payment is 5,000 yuan through the offline service, and 100 yuan is transferred through the online service. You can find the time limit for obtaining the execution status of these two lost orders according to the mapping table of service characteristics and time limit requirements in Table 2 below. The time limits for A and D were determined to be 5 seconds and 2 minutes, respectively.

Table 2

In step 45, within the next 5 seconds, the flow order number of A is used to send a query request to the banking system; within the next 2 minutes, the flow order number of D is used to send a query request to the banking system.

In step 46, the execution states of both A and D are respectively "completed".

In step 47, the execution states of the payment service A and the payment service D are respectively modified.

According to the method provided in Embodiment 4, the time limit requirement for obtaining the execution status of the single service is determined according to the service feature, and then the execution status of the different lost service is queried according to the time limit requirement, and the execution status of the different lost service is satisfied. Different timeframe requirements and a better payment experience for users.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment in combination of software and hardware. Moreover, the application 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.) including computer usable program code.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. 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 device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

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

The memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium.

Computer readable media includes both permanent and non-persistent, removable and non-removable media. Information storage can be implemented by any method or technology. The 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 technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It is also to be understood that the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, Other elements not explicitly listed, or elements that are inherent to such a process, method, commodity, or equipment. An element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in a process, method, article, or device that comprises the element, without further limitation.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware. Moreover, the application 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.) including computer usable program code.

The above is only an embodiment of the present application and is not intended to limit the application. Various changes and modifications can be made to the present application by those skilled in the art. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the present application are intended to be included within the scope of the appended claims.

Claims

A method for querying a service request execution state, comprising:

Obtaining the identification code and service characteristics of the single service;

According to the service feature, the execution status of the single service is queried by using the identification code.
The method of claim 1 wherein the method further comprises:

Modify the execution status of the service request according to the execution status of the logged out service.
The method according to claim 1, wherein the querying the execution status of the lost service by using the identification code according to the service feature comprises:

Determining a time limit requirement for the lost service according to the service characteristic;

According to the time limit requirement, the execution status of the single service is queried by using the identification code.
The method of claim 1 wherein the service feature comprises at least one of the following:

business type;

Business scale

The user level corresponding to the service.
The method of claim 4 wherein the type of service comprises at least one of the following:

Online business type;

Offline business type.
The method according to claim 1, wherein the execution status of the single service is queried, including at least one of the following:

Query the execution status of the single service according to the set period;

The query execution rule of the single-service is queried according to the query rule of the specified number of lost transactions.
A device for querying the execution status of a service request, comprising:

An obtaining unit, configured to obtain an identification code and a service feature of the lost service;

The query unit is configured to query, according to the service feature, the execution status of the single service by using the identifier code.
The device of claim 7 further comprising:

The modifying unit is configured to modify the execution status of the service request according to the execution status of the logged-out service.
The apparatus according to claim 7, wherein the query unit is configured to:

Determining a time limit requirement for the lost service according to the service characteristic;

According to the time limit requirement, the execution status of the single service is queried by using the identification code.
The apparatus of claim 7 wherein the traffic characteristics comprise at least one of:

business type;

Business scale

The user level corresponding to the service.
The apparatus of claim 10, wherein the type of service comprises at least one of the following:

Online business type;

Offline business type.
The apparatus according to claim 7, wherein the query unit is configured to perform at least one of the following operations:

Query the execution status of the single service according to the time period;

According to the fixed number, query the execution status of the single service.
An inquiry system for a service request execution state, comprising: a service system; a query system, wherein:

The service system is configured to: send the identification code and the service feature of the lost service to the query system;

The query system is configured to: receive an identification code and a service feature of the lost service sent by the service system; and use the identifier to query the execution status of the lost service according to the service feature.
The system of claim 13, wherein the querying system is further configured to: modify an execution status of the service request in the service system according to the executed execution status of the lost transaction.