CN106156185B - 一种业务请求执行状态的查询方法、装置及系统 - Google Patents

Abstract

本申请公开了一种业务请求执行状态的查询方法，用于满足不同掉单业务对于获得执行状态的不同时限要求。方法包括：获取掉单业务的标识码和业务特征；根据所述业务特征，利用所述标识码，查询掉单业务的执行状态。本申请还公开了一种业务请求执行状态的查询装置及系统。

Description

一种业务请求执行状态的查询方法、装置及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务请求执行状态的查询方法、装置及系统。

背景技术

随着互联网的蓬勃发展，出现了越来越多的互联网业务请求，以及执行业务请求的系统。可以把发送业务请求的系统称为业务系统，执行业务请求的系统称为执行系统。通常业务系统将业务请求发送到执行系统中，执行系统执行业务请求后，会反馈给业务系统该业务请求一个明确的执行状态，该执行状态可以是完成、或失败。但由于网络原因或两系统原因，可能出现执行系统没有给业务系统发送执行状态，或者业务系统没有接收到业务请求的执行状态，又或者执行系统给业务系统发送了业务请求不明确的执行状态(如处理中),都导致了业务系统不知道业务请求的执行状态是否成功，这种不知道业务请求的执行状态是否成功的情况可以称为掉单，可以认为：凡是没有获得业务请求明确的执行状态(包括获得业务请求不明确的执行状态)都是没有获得业务请求的执行状态；掉单的业务请求可以称为掉单业务。出现掉单后，就需要查询掉单业务的执行状态。

现有技术中，查询掉单业务执行状态的方法是，业务系统定期向执行系统发送某个时间段内掉单业务执行状态的查询请求。比如，业务系统每隔1分钟向执行系统发送一些掉单业务执行状态的查询请求，来获得这些掉单业务的执行状态。

目前，业务类型不同的掉单业务，往往对于获得相应的执行状态的时限有着不同要求。比如，一些掉单业务需要在出现掉单后10秒内获得执行状态，另一些掉单业务则要求在出现掉单后2分钟之内获得执行状态即可。但是，如果按照现有的查询掉单业务执行状态的方法，会按照掉单业务的先后顺序来查询，就可能会出现不能满足获得掉单业务执行状态的时限要求。比如，按照先后顺序，分别发现掉单业务1(简称1)、掉单业务2(简称2)、掉单业务3(简称3)、掉单业务4(简称4)，如果分两次查询这些掉单业务的执行状态，则第一次查询1和2、第二次查询3和4，然而，实际情况下，获得1、2、3、4执行状态的时限要求分别是1分钟、5秒钟、5秒钟、1分钟，由于是按照先后顺序来查询，所以就可能造成不能满足获得3执行状态的时限要求。

发明内容

本申请实施例提供一种业务请求执行状态的查询方法，用于满足不同掉单业务对于获得执行状态的不同时限要求。

本申请实施例提供一种业务请求执行状态的查询装置，用于满足不同掉单业务对于获得执行状态的不同时限要求。

本申请实施例提供一种业务请求执行状态的查询系统，用于满足不同掉单业务对于获得执行状态的不同时限要求。

本申请实施例采用下述技术方案：

一种业务请求执行状态的查询方法，包括：获取掉单业务的标识码和业务特征；根据所述业务特征，利用所述标识码，查询掉单业务的执行状态。

一种业务请求执行状态的查询装置，包括：获取单元，用于获取掉单业务的标识码和业务特征；查询单元，用于根据所述业务特征，利用所述标识码，查询掉单业务的执行状态。

一种业务请求执行状态的查询系统，包括：业务系统，用于：将掉单业务的标识码和业务特征发送给查询系统；查询系统，用于：接收业务系统发送的掉单业务的标识码和业务特征；根据所述业务特征，利用所述标识码，查询掉单业务的执行状态。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

由于可以根据业务特征，来查询掉单业务的执行状态，而业务特征可以表征业务对于获得执行状态的时限要求，从而该技术方案可以支持根据不同时限要求优化查询掉单业务的任务，满足了不同掉单业务对于获得执行状态的不同时限要求。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例1提供的一种业务请求执行状态的查询方法的具体实现流程示意图；

图2为本申请实施例2提供的一种业务请求执行状态的查询装置的具体结构示意图；

图3为本申请实施例3提供的一种业务请求执行状态的查询系统的结构示意图；

图4为本申请实施例4提供的一种支付业务的流程示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

实施例1提供了一种业务请求执行状态的查询方法，用于满足不同掉单业务对于获得执行状态的不同时限要求。该方法的具体流程示意图如图1所示，包括下述步骤：

步骤11，获取掉单业务的标识码和业务特征。

掉单业务可以是通过判断是否接收到业务请求的执行状态(成功或失败) 确定出的。比如，发送了业务请求1，但是没有接收到业务请求1的执行状态，或接收到业务请求1的执行状态为“处理中”，就可以确定出业务请求1出现掉单。掉单业务的标识码，是表示某个出现掉单的业务请求的唯一标识。比如，业务请求的流水单号等。业务特征是表示某个出现掉单的业务请求的特征，针对步骤11而言，业务特征，可以但不限于包括任何可以表征掉单业务对于获得相应的执行状态的时限要求的信息，比如可以包括下述至少一种：

业务类型；业务规模；业务对应的用户等级；等等。

具体地，业务类型，可以包括下述至少一种：线上业务类型；线下业务类型。线下业务对获得掉单业务执行状态的时限要求较高(10秒以内)，所以如果出现掉单，就需要马上查询掉单业务的执行状态，并将查询结果反馈给用户；而线上业务对获得掉单业务执行状态的时限要求要求则没必要太高(2分钟以内)，所以如果出现掉单，相比于线下业务，可能不需要非常及时地将执行状态反馈给用户(2分钟之内反馈给用户即可)。所以不同的业务类型，对于获得掉单业务执行状态的时限要求是不同的。

业务规模可以是指某项业务中执行数额的多少。比如，货物交易量多少，金额交易大小等。实际情况中，对于规模较大的业务(如1万元以上的资金流)，用户都比较担心是否顺利完成，所以如果出现掉单，就需要尽快查询掉单业务的执行状态，以便及时反馈给用户；但对规模较小的业务(如500元以下的资金流)用户则不是很担心，如果出现掉单，在几分钟之内反馈给用户该业务的执行状态就可以了。所以不同的业务规模，对于获得掉单业务执行状态的时限要求也是不同的。

业务对应的用户等级可以是指发送业务请求的用户的等级。这里的等级比如可以包括非常重要人员(Very Important Person，VIP)等级，以及普通等级等。实际情况中，如果VIP等级的用户的业务请求出现掉单，可以为其尽快(比如5秒内)查询掉单业务的执行状态；而对于普通等级的用户，若其业务请求出现掉单，则可以在几分钟之内反馈给用户该业务的执行状态。

该步骤中，掉单业务的标识码和业务特征，可以是从终端获取，也可以是从服务器中获取。

步骤12，根据业务特征，利用标识码，查询掉单业务的执行状态。

在步骤11中已经介绍，具备不同业务特征的掉单业务，对于获得相应的执行状态会有不同的时限要求。所以，针对步骤12而言，根据业务特征，利用标识码，查询掉单业务的执行状态，可以包括：根据业务特征，确定掉单业务的时限要求；根据时限要求，利用标识码，查询掉单业务的执行状态。

具体地，根据业务特征的不同，先确定出掉单业务的时限要求。比如，线上业务，又是数额很小的，如果出现掉单，就可以设定在1分钟之内查询掉单业务的执行状态，再将查询结果反馈给用户即可；又比如对于用移动终端支付了5000元这个业务，是线下业务，又是数额较大的，如果出现掉单，就需要设定在10秒钟之内查询掉单业务的执行状态，并将查询结果及时反馈给用户。在确定出掉单业务的时限要求后，再根据该时限要求，利用掉单业务的标识码，查询掉单业务的执行状态。

在实际应用中，缓存中可能会存在很多待查询执行状态的掉单业务。所以，在每次获取到新的掉单业务的标识码和业务特征后，都可以先确定获取到的新的掉单业务的时限要求，然后根据该时限要求，调整所有待查询执行状态的掉单业务的查询顺序。比如：缓存中存在掉单业务A(简称A)、掉单业务B(简称B)、掉单业务C，根据这三个掉单业务的业务特征(A和B为线下业务、C 为线上业务)，可以按照下表1业务特征和时限要求的映射关系表，查找到获得这三个掉单业务执行状态的时限要求分别为10秒、10秒钟、1分钟，下个5 秒内进行的查询掉单业务执行状态的任务中，将同时查询A和B的执行状态。现获取到新的掉单业务D(简称D)，并查找出获得D(线下业务)执行状态的时限要求也为10秒，所以在下个5秒内进行的查询掉单业务执行状态的任务中，将同时查询A、B和D的执行状态。

业务特征	时限要求
		线下业务	10秒
线上业务	1分钟

表1

为了避免一次查询很多或查询太频繁造成的网络拥堵，查询掉单业务的执行状态，可以包括下述至少一种：按照设定的周期，查询掉单业务的执行状态；按照一次查询指定个数的掉单业务的查询规则，查询掉单业务的执行状态。

具体地，为了避免一次查询很多掉单业务造成网络拥堵，可以每次按照一次查询指定个数的掉单业务的查询规则对掉单业务执行状态进行查询。比如，为了保证网络畅通和计算能力的稳定发挥，查询规则可以是，每次查询10个掉单业务的执行状态。为了避免查询太频繁造成网络拥堵，可以按照设定的周期对掉单业务执行状态进行查询。比如，依然为了保证网络畅通和计算能力的稳定发挥，每10秒钟查询一次。避免了网络拥堵的同时，还更好的满足了用户的需求。

实际应用中，可以按照某种查询规则，灵活执行步骤12。比如，确定出 100个需要在10秒内获得执行状态的掉单业务，将这100个掉单业务按照确定出这些掉单业务(以及获得每个掉单业务执行状态的时限要求)的时间先后顺序，分成4次，每2.5秒查询顺序靠前的25个掉单业务的执行状态，直到利用 10秒钟查询完这100个掉单业务为止。

在一种实施方式中，为了完成对掉单业务的执行状态的反馈，该方法还可以包括：

步骤13，根据查询到的掉单业务的执行状态，修改业务请求的执行状态。

针对步骤13而言，由于业务请求出现掉单时，是没有执行状态的，所以可以根据执行步骤12查询到的掉单业务的执行状态，修改业务请求的执行状态，查询到的执行状态有可能是完成、失败、或者处理中。

采用实施例1提供的该方法，由于可以根据业务特征，来查询掉单业务的执行状态，也就可以根据不同时限要求优化查询掉单业务的任务，从而满足了不同掉单业务对于获得执行状态的不同时限要求。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法的各步骤也可以由不同设备作为执行主体。比如，步骤11 和步骤12的执行主体可以为设备1；又比如，步骤11的执行主体可以为设备 1，步骤12和的执行主体可以为设备2；等等。

实施例2

基于相同的发明构思，实施例2提供了一种业务请求执行状态的查询装置，用于满足不同掉单业务对于获得执行状态的不同时限要求。如图2所示，该装置包括：

获取单元21，可以用于获取掉单业务的标识码和业务特征；

查询单元22，可以用于根据所述业务特征，利用所述标识码，查询掉单业务的执行状态。

在一种实施方式中，该装置还包括：

修改单元23，可以用于根据查询到的掉单业务的执行状态，修改业务请求的执行状态。

在一种实施方式中，查询单元22，可以用于：根据所述业务特征，确定掉单业务的时限要求；根据所述时限要求，利用所述标识码，查询掉单业务的执行状态。

在一种实施方式中，业务特征，可以包括下述至少一种：业务类型；业务规模；业务对应的用户等级。

在一种实施方式中，业务类型，可以包括下述至少一种：线上业务类型；线下业务类型。

在一种实施方式中，查询单元22，用于执行下述至少一种操作：按照时间周期，查询掉单业务的执行状态；按照固定个数，查询掉单业务的执行状态。

采用实施例2提供的该装置，由于可以根据业务特征，来查询掉单业务的执行状态，也就可以根据不同时限要求优化查询掉单业务的任务，从而满足了不同掉单业务对于获得执行状态的不同时限要求。

实施例3

基于相同的发明构思，实施例3提供了一种业务请求执行状态的查询系统，用于满足不同掉单业务对于获得执行状态的不同时限要求。如- 图 3 所示，该系统包括：

业务系统31，可以用于：将掉单业务的标识码和业务特征发送给查询系统；

查询系统32，可以用于：接收业务系统发送的掉单业务的标识码和业务特征；根据业务特征，利用标识码，查询掉单业务的执行状态。

在一种实施方式中，查询系统32，还可以用于：根据查询到的掉单业务的执行状态，修改业务系统31中业务请求的执行状态。

在一种实施方式中，查询系统32，还可以用于：将查询到的掉单业务的执行状态，发送给业务系统31。

在一种实施方式中，业务系统31，还可以用于：接收查询系统32查询到的掉单业务的执行状态；修改掉单业务的执行状态。

需要说明的是，实施例3中所说的业务系统31和查询系统32，可以是同一设备中的两个单独的系统，也可以是同一系统中两个单独的模块；等等。

采用实施例3提供的该系统，由于可以根据业务特征，来查询掉单业务的执行状态，也就可以根据不同时限要求优化查询掉单业务的任务，从而满足了不同掉单业务对于获得执行状态的不同时限要求。

实施例4

基于相同的发明构思，实施例4提供了一种支付业务执行状态的查询方法，用于满足不同掉单业务对于获得执行状态的不同时限要求，并为用户提供更好支付体验。该方法的示意图如图4所示，包括下述步骤：

步骤41，发送5个支付业务(支付业务A、支付业务B、支付业务C、支付业务D、支付业务E)到银行系统；

步骤42，接收到支付业务B、支付业务C和支付业务E这3个支付业务的执行状态，3个全部为执行成功。

步骤43，因为没有接收到支付业务A和支付业务D的执行状态，所以判断出支付业务A和支付业务D出现掉单，确定出掉单业务A(简称A)和掉单业务D(简称D)。

步骤44，根据A和D的业务特征分别为：通过线下业务支付5000元、通过线上业务转账100元。可以按照下表2业务特征和时限要求的映射关系表，查找到获得这两个掉单业务执行状态的时限要求。分别确定出A和D的时限要求分别是5秒和2分钟。

表2

步骤45，在下个5秒钟之内，利用A的流水单号，向银行系统发送查询掉单请求；在下个2分钟之内，利用D的流水单号，向银行系统发送查询掉单请求。

步骤46，分别获取到A和D的执行状态都为“完成”。

步骤47，分别修改支付业务A和支付业务D的执行状态。

采用实施例4提供的该方法，先根据业务特征，确定出获得掉单业务执行状态的时限要求，再根据时限要求来查询不同掉单业务的执行状态，满足了不同掉单业务对于获得执行状态的不同时限要求，并为用户提供了更好支付体验。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

1.一种业务请求执行状态的查询方法，其特征在于，包括：

获取掉单业务的标识码和业务特征；

根据所述业务特征，利用所述标识码，查询掉单业务的执行状态，其中，所述业务特征用于表征掉单业务对于获得相应的执行状态的时限要求的信息。

2.如权利要求1所述的方法，其特征在于，方法还包括：

根据查询到的掉单业务的执行状态，修改业务请求的执行状态。

3.如权利要求1所述的方法，其特征在于，业务特征，包括下述至少一种：

业务类型；

业务规模；

业务对应的用户等级。

4.如权利要求3所述的方法，其特征在于，业务类型，包括下述至少一种：

线上业务类型；

线下业务类型。

5.如权利要求1所述的方法，其特征在于，查询掉单业务的执行状态，包括下述至少一种：

按照设定的周期，查询掉单业务的执行状态；

按照一次查询指定个数的掉单业务的查询规则，查询掉单业务的执行状态。

6.一种业务请求执行状态的查询装置，其特征在于，包括：

获取单元，用于获取掉单业务的标识码和业务特征；

查询单元，用于根据所述业务特征，利用所述标识码，查询掉单业务的执行状态，其中，所述业务特征用于表征掉单业务对于获得相应的执行状态的时限要求的信息。

7.如权利要求6所述的装置，其特征在于，还包括：

修改单元，用于根据查询到的掉单业务的执行状态，修改业务请求的执行状态。

8.如权利要求6所述的装置，其特征在于，业务特征，包括下述至少一种：

业务类型；

业务规模；

业务对应的用户等级。

9.如权利要求8所述的装置，其特征在于，业务类型，包括下述至少一种：

线上业务类型；

线下业务类型。

10.如权利要求6所述的装置，其特征在于，查询单元，用于执行下述至少一种操作：

按照时间周期，查询掉单业务的执行状态；

按照固定个数，查询掉单业务的执行状态。

11.一种业务请求执行状态的查询系统，包括：业务系统；查询系统，其特征在于：

业务系统，用于：将掉单业务的标识码和业务特征发送给查询系统；

查询系统，用于：接收业务系统发送的掉单业务的标识码和业务特征；根据所述业务特征，利用所述标识码，查询掉单业务的执行状态，其中，所述业务特征用于表征掉单业务对于获得相应的执行状态的时限要求的信息。

12.如权利要求11所述的系统，其特征在于，查询系统，还用于：根据查询到的掉单业务的执行状态，修改业务系统中业务请求的执行状态。