一种网约车订单处理方法、装置和电子设备

技术领域

本公开涉及网约车技术领域，具体涉及一种网约车订单处理方法、装置和电子设备。

背景技术

随着网约车市场的发展，网约车公司的约车服务越来越多的嵌入合作方平台，如百度、高德等。此种模式下，乘客在合作方的打车App上下单、付款，由网约车公司提供乘客接送服务。乘客到达目的地后网约车公司的订单状态变为待支付，当合作方收到乘客付款后通知网约车公司，之后网约车公司修改订单状态为已完成。

但是如果因为各种原因(如网络异常导致服务接口调用失败、合作方系统问题导致未能在乘客支付后及时通知网约车公司、网约车公司系统问题导致更新订单状态为已完成时失败等)导致实际在合作方已支付的订单无法在网约车公司系统及时被修改为已完成就会造成在网约车公司系统订单长时间处于待支付状态。因为系统设计当存在未支付的订单时，乘客必须先支付上一笔订单才能下新订单。因此当订单长时间处于待支付状态时，网约车公司就不能继续为该乘客提供网约车服务。

发明内容

本公开实施例提出一种网约车订单处理方案，以解决现有技术在异常情况下订单长时间处于待支付状态的问题。

本公开实施例的第一方面提供了一种网约车订单处理方法，包括：

获取创建时间在预设范围内，且订单状态为待支付的订单，以及每个所述订单的合作方信息；

查询所述订单的合作方订单支付状态，如果所述合作方订单支付状态为支付成功，则将所述订单的状态更新为已完成。

在在一些实施例中，所述方法还包括：

如果所述合作方订单支付状态不为支付成功，则保持所述订单的状态不变。

在一些实施例中，所述获取创建时间在预设范围内，且订单状态为待支付的订单包括：

计算查询开始时间和查询结束时间；

从数据库中获取订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单。

在一些实施例中，所述计算查询开始时间和查询结束时间包括：

执行定时任务，所述定时任务从配置文件获取预设范围和预设间隔；

获取服务器当前时间；

基于所述服务器当前时间计算所述查询开始时间和所述查询结束时间，其中,

查询开始时间＝服务器当前时间-预设范围，

查询结束时间＝服务器当前时间-预设间隔；

在一些实施例中，所述从数据库中获取订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单包括：

从数据库中查询订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单总数；

计算分页查询次数；

按照所述分页查询次数分多次从所述数据库中获取所述订单。

在一些实施例中，分页查询次数＝订单总数％预设最佳并发查询数。

在一些实施例中，获取每个所述订单的合作方信息包括：

对每个所述订单，从所述订单的订单属性获取所述订单的渠道号；

通过所述渠道号查询所述订单的合作方信息。

在一些实施例中，所述查询所述订单的合作方订单支付状态包括：

调用合作方订单支付状态查询接口，其中，所述查询接口用于通过请求参数获得所述订单在合作方系统的支付状态，所述查询接口的请求参数至少包括调用时间戳和订单号；

获取并解析合作方订单支付状态查询接口的返回值。

本公开实施例的第二方面提供了一种网约车订单处理装置，包括：

获取模块，用于获取创建时间在预设范围内，且订单状态为待支付的订单，以及每个所述订单的合作方信息；

更新模块，用于查询所述订单的合作方订单支付状态，如果所述合作方订单支付状态为支付成功，则将所述订单的状态更新为已完成。

本公开实施例的第三方面提供了一种电子设备，包括存储器和处理器，

所述存储器，用于存储计算机程序；

所述处理器，用于当执行所述计算机程序时，实现根据本公开第一方面所述的方法。

本公开实施例的第四方面提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，当所述计算机程序被处理器执行时，实现根据本公开第一方面所述的方法。

本公开实施例的第五方面提供了一种计算机程序产品，包括计算机程序、指令，当所述计算机程序、指令被处理器执行时，实现根据本公开第一方面所述的方法。

综上所述，本公开各实施例提供的网约车订单处理方法、装置、电子设备、计算机可读存储介质和计算机程序产品，通过定时根据合作方的订单支付状态修改网约车公司订单的完成状态，解决了异常情况下订单长时间处于待支付状态的问题，从而可以继续为乘客提供网约车服务，提高了客户满意度。

附图说明

通过参考附图会更加清楚的理解本公开的特征和优点，附图是示意性的而不应理解为对本公开进行任何限制，在附图中：

图1是本公开适用的一种计算机系统的示意图；

图2是根据本公开的一些实施例所示的一种网约车订单处理方法的流程图；

图3是根据本公开的另外一些实施例所示的一种网约车订单处理方法的详细流程图；

图4根据本公开的一些实施例所示的一种网约车订单处理装置的示意图；

图5是本公开的一些实施例所示的一种电子设备示意图。

具体实施方式

在下面的详细描述中，通过示例阐述了本公开的许多具体细节，以便提供对相关披露的透彻理解。然而，对于本领域的普通技术人员来讲，本公开显而易见的可以在没有这些细节的情况下实施。应当理解的是，本公开中使用“系统”、“装置”、“单元”和/或“模块”术语，是用于区分在顺序排列中不同级别的不同部件、元件、部分或组件的一种方法。然而，如果其他表达式可以实现相同的目的，这些术语可以被其他表达式替换。

应当理解的是，当设备、单元或模块被称为“在……上”、“连接到”或“耦合到”另一设备、单元或模块时，其可以直接在另一设备、单元或模块上，连接或耦合到或与其他设备、单元或模块通信，或者可以存在中间设备、单元或模块，除非上下文明确提示例外情形。例如，本公开所使用的术语“和/或”包括一个或多个相关所列条目的任何一个和所有组合。

本公开所用术语仅为了描述特定实施例，而非限制本公开范围。如本公开说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的特征、整体、步骤、操作、元素和/或组件，而该类表述并不构成一个排它性的罗列，其他特征、整体、步骤、操作、元素和/或组件也可以包含在内。

参看下面的说明以及附图，本公开的这些或其他特征和特点、操作方法、结构的相关元素的功能、部分的结合以及制造的经济性可以被更好地理解，其中说明和附图形成了说明书的一部分。然而，可以清楚地理解，附图仅用作说明和描述的目的，并不意在限定本公开的保护范围。可以理解的是，附图并非按比例绘制。

本公开中使用了多种结构图用来说明根据本公开的实施例的各种变形。应当理解的是，前面或下面的结构并不是用来限定本公开。本公开的保护范围以权利要求为准。

图1是本公开适用的一种计算机系统的示意图。如图1所示的系统，网约车公司订单系统和合作方订单系统网络连接，网约车公司订单系统定时根据合作方订单系统订单支付状态修改网约车公司订单的完成状态。

如图1所示的系统，乘客通过合作方APP购买网约车服务，在合作方订单系统生成合作方订单。合作方同时向网约车公司发布网约车服务请求，网约车公司接受所述网约车服务请求，分配网约车，提供承运服务，同时在网约车公司订单系统生成网约车公司订单。当网约车服务结束乘客付款后，合作方订单系统修改订单状态为支付成功，同时向网约车公司订单系统发送乘客已付款的消息。网约车公司订单系统收到此消息后，将网约车公司订单状态修改为已完成。

但当因为异常情况导致网约车公司订单系统未收到乘客已付款的消息时，网约车公司订单状态就会长时间保持在未完成的状态，从而导致网约车公司不能继续向该乘客提供服务。所述异常情况包括但不限于：网络异常导致服务接口调用失败、合作方系统问题导致未能在乘客支付后及时通知网约车公司、网约车公司系统问题导致更新订单状态为已完成时失败等。本申请中，网约车公司订单系统定时根据合作方的订单支付状态修改网约车公司订单的完成状态，解决了异常情况下订单长时间处于待支付状态的问题，从而可以继续为乘客提供网约车服务，提高了客户满意度。

网约车公司订单系统与合作方订单系统都库可以是单机、集群或分布式数据库中的的任一种。

图2是根据本公开的一些实施例所示的一种网约车订单处理方法的流程图。在一些实施例中，所述网约车订单处理方法可以由图1所示的网约车公司订单系统执行。如图2所示，所述网约车订单处理方法包括以下步骤：

S201，获取创建时间在预设范围内，且订单状态为待支付的订单，以及每个所述订单的合作方信息。

具体的，在本公开的一些实施例中，所述方法还包括如果所述合作方订单支付状态不为支付成功，则保持所述订单的状态不变。

在本公开的一些实施例中，获取创建时间在预设范围内，且订单状态为待支付的订单包括：

计算查询开始时间和查询结束时间；

从数据库中获取订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单。

在本公开的一些实施例中，所述计算查询开始时间和查询结束时间包括：

执行定时任务，所述定时任务从配置文件获取预设范围和预设间隔；

获取服务器当前时间；

基于所述服务器当前时间计算所述查询开始时间和所述查询结束时间，其中,

查询开始时间＝服务器当前时间-预设范围，

查询结束时间＝服务器当前时间-预设间隔。

在本公开的一些实施例中，所述从数据库中获取订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单包括：

从数据库中查询订单状态为待支付，同时满足创建时间不早于查询开始时间且早于查询结束时间的订单总数；

计算分页查询次数；

按照所述分页查询次数分多次从所述数据库中获取所述订单。

在本公开的一些实施例中，分页查询次数＝订单总数％预设最佳并发查询数。

其中，预设最佳并发查询数是基于单条数据的大小评估出来的。如果每次查询的条数太多，则每次返回的数据量太大，就会过多占用系统内存、网络带宽等；如果每次查询的调试太少，则会频繁查询数据库、频繁执行网络请求。

在本公开的一些实施例中，预设最佳并发查询数是50.

S202，查询所述订单的合作方订单支付状态，如果所述合作方订单支付状态为支付成功，则将所述订单的状态更新为已完成。

具体的，在本公开的一些实施例中，网约车公司订单的订单属性包括渠道号，渠道号是对请求本次网约车服务的合作方公司的编号。

获取每个所述订单的合作方信息包括：

对每个所述订单，从所述订单的订单属性获取所述订单的渠道号；

通过所述渠道号查询所述订单的合作方信息。

所述查询所述订单的合作方订单支付状态包括：

调用合作方订单支付状态查询接口，其中，所述查询接口用于通过请求参数获得所述订单在合作方系统的支付状态，所述查询接口的请求参数至少包括调用时间戳和订单号；

获取并解析合作方订单支付状态查询接口的返回值。

图3是根据本公开的另外一些实施例所示的一种网约车订单处理方法的详细流程图。如图3所示，所述方法包括：

本申请是一种通过定时任务的方式，每天定时查询待支付状态的订单并主动调用合作方订单支付状态查询接口，从而及时更新网约车公司订单状态为已完成的方法

本申请中定时任务每天0:00分开始执行

本发明的前置条件是需要合作方具备通过订单号查询支付状态的服务接口。接口的核心入参为订单号，如：B210121180601591000；接口的核心出参为支付状态标识，如0为待支付，1为已支付

定时任务的具体执行步骤如下：

步骤1：定时任务开始执行

步骤2：从配置文件中读取周期配置，记为N

配置文件的示例如下：

count_period＝3

以上配置示例的含义为：让定时任务处理订单创建时间在最近3天内，且状态为待支付的订单。读取配置后N的值为3

步骤3：获取服务器当前时间，记为P。P的值如：2022-01-1100:00:01

步骤4：计算订单创建开始时间，记为A。计算方式如下：将服务器当前时间P减去周期N得到订单创建开始时间A

如P＝2022-01-1100:00:01，N＝3，则A＝2022-01-0800:00:01

步骤5：计算订单创建结束时间，记为B。计算方式如下：将服务器当前时间P减去5小时得到订单创建结束时间B

如P＝2022-01-1100:00:01，减去5小时，则B＝2022-01-1019:00:01

步骤6：从数据库中查询订单创建时间在A、B范围内，且订单状态为待支付的订单总数，记为C

步骤7：计算需要分页查询数据库的次数。计算方式为：将步骤6中C的值对50取余得到分页查询次数

假设C的值为118，则C％50＝3，得到查询次数为3。即定时任务一共需要处理118个订单，为避免数据库查询结果过大，分3次查询(前两次每次查50个，最后一次只能查到18个)

步骤8：从数据库中分页查询待支付状态的订单，并逐一处理每个订单

步骤9：获取订单上的渠道号(渠道号即为合作方在我方的唯一合法性标识，其值如：partner_SM、partner_PPQ等)，通过渠道号从数据库中查询该订单所属的合作方信息

步骤10：判断合作方信息中的订单支付状态查询接口URL是否为空。若为空则执行步骤16，否则执行步骤11

步骤11：组织调用合作方订单支付状态查询接口的请求参数。请求参数包括调用时间戳(示例值：1680402609)、订单号(示例值：B210121180601591000)等

步骤12：调用合作方订单支付状态查询接口

步骤13：解析合作方订单支付状态查询接口的返回值。返回值示例如下：

{

"code":0,

"msg":"SUCCESS",

"data":{

"payStatus":1//支付状态

}

}

步骤14：判断返回结果中支付状态是否为支付成功(1表示已支付成功)。若不为1则执行步骤16，否则执行步骤15

步骤15：将订单的状态更新为已完成

步骤16：继续处理下一订单

步骤17：结束。

图4是根据本公开的一些实施例所示的一种网约车订单处理装置示意图。如图4所示，所述网约车订单处理装置400包括获取模块410、更新模块420、所述网约车订单处理功能可以由图1中的网约车公司订单系统执行。其中：

获取模块410，用于获取创建时间在预设范围内，且订单状态为待支付的订单，以及每个所述订单的合作方信息；

更新模块420，用于查询所述订单的合作方订单支付状态，如果所述合作方订单支付状态为支付成功，则将所述订单的状态更新为已完成。

本公开的一个实施例提供了一种电子设备，所述电子设备500包括存储器520和处理器510，所述存储器520，用于存储计算机程序；所述处理器510，用于当执行所述计算机程序时，实现图2中S201-S202所述的方法。

本公开的一个实施例提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，当所述计算机程序被处理器执行时，实现图2中S201-S202所述的方法。

本公开的一个实施例提供了一种计算机程序产品，包括计算机程序、指令，当所述计算机程序、指令被处理器执行时实现图2中S201-S202所述的方法。

综上所述，本公开各实施例提供的网约车订单处理方法、装置、电子设备、计算机可读存储介质和计算机程序产品，通过定时根据合作方的订单支付状态修改网约车公司订单的完成状态，解决了异常情况下订单长时间处于待支付状态的问题，从而可以继续为乘客提供网约车服务，提高了客户满意度。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述装置实施例中的对应描述，在此不再赘述。

尽管此处所述的主题是在结合操作系统和应用程序在计算机系统上的执行而执行的一般上下文中提供的，但本领域技术人员可以认识到，还可结合其他类型的程序模块来执行其他实现。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构和其他类型的结构。本领域技术人员可以理解，此处所述的本主题可以使用其他计算机系统配置来实践，包括手持式设备、多处理器系统、基于微处理器或可编程消费电子产品、小型计算机、大型计算机等，也可使用在其中任务由通过通信网络连接的远程处理设备执行的分布式计算环境中。在分布式计算环境中，程序模块可位于本地和远程存储器存储设备的两者中。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

应当理解的是，本公开的上述具体实施方式仅仅用于示例性说明或解释本公开的原理，而不构成对本公开的限制。因此，在不偏离本公开的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。此外，本公开所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。