一种订单查询方法及装置

技术领域

本申请涉及订单数据处理技术领域，尤其是涉及一种订单查询方法及装置。

背景技术

目前，应用于MRO工业用品的订单数据源丰富多样化，数据量巨大，订单查询过程涉及不同系统之间的查询交互。

而订单查询往往涉及用户的个人信息和订单数据，如何在保证查询效率的同时实现订单数据的安全性和隐私保护是订单查询过程中的一个技术难点。

发明内容

为了改善订单查询过程中的数据安全性问题，本申请提供了一种订单查询方法及装置。

第一方面，本申请提供一种订单查询方法。

本申请是通过以下技术方案得以实现的：

一种订单查询方法，包括以下步骤，

先从用于订单交易的交易域获取来自用户端的订单号和对应的用户身份标识；

基于所述用户身份标识，在用于风险防控的安全域交换用户端和服务端的查询码；

发布与所述订单号对应的订单查询任务消息至队列存储容器中，并返回交换的所述查询码至所述用户端；

再从所述交易域获取认证信息和待核验的所述查询码；

在所述安全域核验所述查询码，以及，

判断是否核验成功；

当核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果；

将所述查询结果返回至所述用户端。

本申请在一较佳示例中可以进一步配置为：所述发布与所述订单号对应的订单查询任务消息至队列存储容器中的步骤前，还包括，

判断订单的最后更新时间与当前时间的差值的绝对值是否超过预设时间阈值；

若订单的最后更新时间与当前时间的差值的绝对值超过预设时间阈值，则发布与所述订单号对应的订单查询任务消息至队列存储容器中。

本申请在一较佳示例中可以进一步配置为：所述当核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果的同时，还包括以下步骤，

缓存所述查询结果至所述交易域，直至再次发布与所述订单号对应的订单查询任务消息时，删除位于所述交易域的所述查询结果；

当再次获取到所述用户端的同一订单号时，默认返回与所述订单号对应的查询结果至所述用户端。

本申请在一较佳示例中可以进一步配置为：将所述查询结果返回至所述用户端的同时，还包括，

将所述查询结果以分页形式返回至所述用户端。

本申请在一较佳示例中可以进一步配置为：还包括以下步骤，

按照预设的数据格式拆分和拼接所述查询结果，得到第一数据；

为所述第一数据增加当次查询时间属性，得到第二数据。

本申请在一较佳示例中可以进一步配置为：还包括以下步骤，

当获取到用户端的订单号时，先索引与所述订单号对应的第二数据；

若存在与所述订单号对应的第二数据，则基于所述第二数据，修改和更新与所述订单号对应的所述订单查询任务，包括，

删除所述订单查询任务中的、满足目标查询结果已包含于所述第二数据中的查询指令；

当所述交易域执行更新的所述订单查询任务后，根据执行结果修改第二数据，得到查询结果。

本申请在一较佳示例中可以进一步配置为：还包括以下步骤，

预测和增加与各订单状态对应的拟流转用时属性至所述第二数据中；

当接收到用户端的用于商品更换的订单修订请求时，获取与订单号对应的第二数据；

基于所述第二数据，判断所述订单修订请求是否满足预设条件；

若所述订单修订请求满足预设条件，则通过所述订单修订请求，更新拟更换商品的库存数据和释放已取消商品的库存数据，并将所述订单修订请求的生效信息反馈至所述用户端。

本申请在一较佳示例中可以进一步配置为：还包括以下步骤，

若所述订单修订请求不满足预设条件，则拒绝所述订单修订请求，并将所述订单修订请求的失败信息反馈至所述用户端。

本申请在一较佳示例中可以进一步配置为：基于所述第二数据，判断所述订单修订请求是否满足预设条件的步骤包括，

基于当前查询时间，从所述第二数据中获取上一查询时间对应的订单状态和拟流转用时；

将所述当前查询时间与所述上一查询时间作差值，结合所述第二数据中与各订单状态对应的拟流转用时属性，预测当前查询时间对应的订单状态；

若所述订单未经历待揽收状态，则判定所述订单修订请求满足预设条件，否则，判定所述订单修订请求不满足预设条件。

第二方面，本申请提供一种订单查询装置。

本申请是通过以下技术方案得以实现的：

一种订单查询装置，包括，

第一数据模块，用于先从用于订单交易的交易域获取来自用户端的订单号和对应的用户身份标识；

前置模块，用于基于所述用户身份标识，在用于风险防控的安全域交换用户端和服务端的查询码；

消息发布模块，用于发布与所述订单号对应的订单查询任务消息至队列存储容器中，并返回交换的所述查询码至所述用户端；

第二数据模块，用于再从所述交易域获取认证信息和待核验的所述查询码；

验证模块，用于在所述安全域核验所述查询码，判断是否核验成功；

查询模块，用于在核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果；

反馈模块，用于将所述查询结果返回至所述用户端。

本申请在一较佳示例中可以进一步配置为：还包括，

周期检测模块，用于判断订单的最后更新时间与当前时间的差值的绝对值是否超过预设时间阈值；

定期发布模块，用于在订单的最后更新时间与当前时间的差值的绝对值超过预设时间阈值时，发布与所述订单号对应的订单查询任务消息至队列存储容器中。

本申请在一较佳示例中可以进一步配置为：还包括，

定期缓存模块，用于缓存所述查询结果至所述交易域，直至再次发布与所述订单号对应的订单查询任务消息时，删除位于所述交易域的所述查询结果；

免验证模块，用于当再次获取到所述用户端的同一订单号时，默认返回与所述订单号对应的查询结果至所述用户端。

本申请在一较佳示例中可以进一步配置为：所述反馈模块包括，

分页单元，用于将所述查询结果以分页形式返回至所述用户端。

本申请在一较佳示例中可以进一步配置为：还包括，

数据统一模块，用于按照预设的数据格式拆分和拼接所述查询结果，得到第一数据；

第一处理模块，用于为所述第一数据增加当次查询时间属性，得到第二数据。

本申请在一较佳示例中可以进一步配置为：还包括，

数据匹配模块，用于当获取到用户端的订单号时，先索引与所述订单号对应的第二数据；

指令修改模块，用于在存在与所述订单号对应的第二数据时，基于所述第二数据，修改和更新与所述订单号对应的所述订单查询任务，包括，删除所述订单查询任务中的、满足目标查询结果已包含于所述第二数据中的查询指令；

数据更新模块，用于当所述交易域执行更新的所述订单查询任务后，根据执行结果修改第二数据，得到查询结果。

本申请在一较佳示例中可以进一步配置为：还包括，

第二处理模块，用于预测和增加与各订单状态对应的拟流转用时属性至所述第二数据中；

修订请求模块，用于当接收到用户端的用于商品更换的订单修订请求时，获取与订单号对应的第二数据；

修订判断模块，用于基于所述第二数据，判断所述订单修订请求是否满足预设条件；

修订通过模块，用于在所述订单修订请求满足预设条件时，通过所述订单修订请求，更新拟更换商品的库存数据和释放已取消商品的库存数据，并将所述订单修订请求的生效信息反馈至所述用户端。

本申请在一较佳示例中可以进一步配置为：还包括，

修订拒绝模块，用于在所述订单修订请求不满足预设条件时，拒绝所述订单修订请求，并将所述订单修订请求的失败信息反馈至所述用户端。

本申请在一较佳示例中可以进一步配置为：所述修订判断模块包括，

关联单元，用于基于当前查询时间，从所述第二数据中获取上一查询时间对应的订单状态和拟流转用时；

预测单元，用于将所述当前查询时间与所述上一查询时间作差值，结合所述第二数据中与各订单状态对应的拟流转用时属性，预测当前查询时间对应的订单状态；

判断单元，用于在所述订单未经历待揽收状态时，判定所述订单修订请求满足预设条件，否则，判定所述订单修订请求不满足预设条件。

第三方面，本申请提供一种计算机设备。

本申请是通过以下技术方案得以实现的：

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意一种订单查询方法的步骤。

第四方面，本申请提供一种计算机可读存储介质。

本申请是通过以下技术方案得以实现的：

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种订单查询方法的步骤。

综上所述，与现有技术相比，本申请提供的技术方案带来的有益效果至少包括：

通过在安全域交换用户端和服务端的查询码，防止查询码在本地泄漏的情况发生，以及在获取认证信息的同时，对查询码进行核验，增加前置验证以确认用户身份的合法性后再进行订单查询，改善了订单查询过程中的数据安全性问题，前置验证也减少了订单查询时的耗时；同时，在订单查询前先发布订单查询任务消息至队列存储容器中，以便于异步执行订单查询任务，提高查询效率。

附图说明

图1为本申请一个示例性实施例提供的一种订单查询方法的交互示意图。

图2为本申请又一个示例性实施例提供的一种订单查询方法的整体流程示意图。

图3为本申请另一个示例性实施例提供的一种订单查询方法的周期发布订单查询任务消息的流程图。

图4为本申请一个示例性实施例提供的一种订单查询方法的已核验通过的用户的再次订单查询流程图。

图5为本申请一个示例性实施例提供的一种订单查询方法的订单数据分页查询示意图。

图6为本申请一个示例性实施例提供的一种订单查询方法的查询结果处理流程图。

图7为本申请一个示例性实施例提供的一种订单查询方法的订单修改流程图。

图8为本申请一个示例性实施例提供的一种订单查询装置的结构框图。

具体实施方式

本具体实施例仅仅是对本申请的解释，其并不是对本申请的限制，本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本申请的权利要求范围内都受到专利法的保护。

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

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。

下面结合说明书附图对本申请实施例作进一步详细描述。

参照图1和图2，本申请实施例提供一种订单查询方法，所述方法的主要步骤描述如下。

S1:先从用于订单交易的交易域获取来自用户端的订单号和对应的用户身份标识；

S2:基于所述用户身份标识，在用于风险防控的安全域交换用户端和服务端的查询码；

S3:发布与所述订单号对应的订单查询任务消息至队列存储容器中，并返回交换的所述查询码至所述用户端；

S4:再从所述交易域获取认证信息和待核验的所述查询码；

S5:在所述安全域核验所述查询码，以及，

S6:判断是否核验成功；

S7:当核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果；

S8:将所述查询结果返回至所述用户端。

具体地，设计用于订单交易的交易域，实现购物车、询价单生成、订单生成、订单支付等订单交易功能，交易域内可以设计订单系统OMS、销售管理系统SAP、物流系统TMS等，以及，设计用于风险防控的安全域，以基于预设的风控规则对订单系统进行风险防控，同时，创建队列存储容器Queue用于存储消息以异步处理消息。

一个域可以包含多个系统。系统是具体的实体，可以在某一个域中进行定义、设计和实现。

交易域更注重订单交易属性，安全域更注重订单数据的风控属性，并在交易域中设计订单系统OMS、销售管理系统SAP、物流系统TMS等，以体现组件、部件或元素之间的相互关系和协作，并实现订单管理、销售管理、物流管理等目标，以统一管理各种订单数据，便于订单数据的查询。

通过增加前置验证功能，当用户登录用户端后，在交易域内录入订单号时，交易域获取来自用户端的订单号和对应的用户身份标识，根据用户登录身份分配一查询码(查询握手码)，查询码与用户身份标识一一对应，以验证用户身份的有效性，前置验证也减少了订单查询时的耗时。

再基于用户身份标识，在安全域将用户端的查询码与服务端的查询码进行交换，通过将服务端的查询码存储于安全域内，以避免数据在本地泄漏而引发安全隐患的问题。

接着，从交易域发布与订单号对应的订单查询任务消息至队列存储容器中，同时，交易域返回交换的查询码至用户端。

将订单查询任务消息预存储至队列存储容器中，能够在用户身份核验通过后立即异步执行订单查询任务，提高订单查询效率。

查询订单时，用户输入必填的认证信息和已交换的查询码，认证信息可包括账号、密码等，交易域获取认证信息和待核验的查询码，并将查询码发送至安全域进行验证，根据核验结果执行查询操作，以增加前置验证功能，确认用户身份的合法性后再进行订单查询，改善了订单查询过程中的数据安全性问题。

当核验成功时，即查询码验证通过，在交易域执行与订单号对应的订单查询任务，借助接口从订单系统OMS、销售管理系统SAP、物流系统TMS等查询本地订单数据，得到查询结果，通过二阶段查询返回本地订单数据。

最后将查询结果返回至用户端。本实施例中，查询结果可以为订单及物流信息。

参照图3，在一实施例中，S3:发布与所述订单号对应的订单查询任务消息至队列存储容器中的步骤前，还包括，

S31:判断订单的最后更新时间与当前时间的差值的绝对值是否超过预设时间阈值；

S32:若订单的最后更新时间与当前时间的差值的绝对值超过预设时间阈值，则发布与所述订单号对应的订单查询任务消息至队列存储容器中。

通过设置订单更新周期作为时间阈值，以根据订单在库状态，在发布订单查询任务消息前，先判断订单的最后更新时间与当前时间的差值的绝对值是否超过预设时间阈值。本实施例中，时间阈值可以为10分钟。

若订单的最后更新时间与当前时间的差值的绝对值超过时间阈值，即满足订单更新条件，此时允许发布订单查询任务消息至队列存储容器，避免订单查询任务执行过于频繁的问题，改善系统计算资源的占用情况，同时，借助队列存储容器异步处理订单查询任务消息，提升了订单查询效率。

参照图4，在一实施例中，S7:当核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果的同时，还包括以下步骤，

S9:缓存所述查询结果至所述交易域，直至再次发布与所述订单号对应的订单查询任务消息时，删除位于所述交易域的所述查询结果；

S10:当再次获取到所述用户端的同一订单号时，默认返回与所述订单号对应的查询结果至所述用户端。

将查询结果缓存至交易域的本地数据库中。

具体地，通过将查询结果缓存至交易域，当再次获取到同一用户端的已通过核验的用户发出的同一订单查询请求时，无需身份认证和前置验证，大大提高了订单的查询效率，同时，在订单更新周期内缓存同一订单号的查询结果以备再次查询时使用，当再次获取到该用户端的同一订单号时，默认返回与订单号对应的查询结果至用户端，无需反复执行相同的订单查询任务，极大改善了系统计算资源的占用情况，提升了订单查询效率。

参照图5，在一实施例中，将所述查询结果返回至所述用户端的同时，还包括，

将所述查询结果以分页形式返回至所述用户端。

例如，查询码已核验通过的用户，当进行订单查询时，在用户端发送分页查询订单请求至交易域，从交易域的本地数据库调取已缓存的查询结果并分页返回至用户端，以限制查询的订单数量，减少计算资源，进而改善交易域发生繁忙情况而影响其他订单功能正常进行的现象。

参照图6，在一实施例中，还包括以下步骤，

S01:按照预设的数据格式拆分和拼接所述查询结果，得到第一数据；

S11:为所述第一数据增加当次查询时间属性，得到第二数据。

因订单数据来自订单系统OMS、销售管理系统SAP、物流系统TMS等，订单数据源丰富多样化，为了减小订单数据的处理难度，加快订单数据的查询效率，在交易域执行订单查询任务，得到查询结果后，先按照预设的数据格式拆分和拼接查询结果，统一订单数据的数据格式，得到第一数据；以及，为第一数据增加当次查询时间属性，得到第二数据，使得订单数据的数据构成更具体与丰富，颗粒度更细，有利于订单数据的有效利用。

在一实施例中，还包括以下步骤，

S111:当获取到用户端的订单号时，先索引与所述订单号对应的第二数据；

S112:若存在与所述订单号对应的第二数据，则基于所述第二数据，修改和更新与所述订单号对应的所述订单查询任务，包括，删除所述订单查询任务中的、满足目标查询结果已包含于所述第二数据中的查询指令；

S113:当所述交易域执行更新的所述订单查询任务后，根据执行结果修改第二数据，得到查询结果。

具体地，当获取到用户端的订单号时，先索引与订单号对应的第二数据，以获取订单的时间属性，用于预测和确定订单的当前状态，并修改和更新订单查询任务，包括删除订单查询任务中的、满足目标查询结果已包含于所述第二数据中的查询指令，例如，若上一次查询时已确定订单处于备货状态，即目标商品的库存已满足要求，则此次订单查询任务中的库存查询指令为目标查询结果已包含于第二数据中的查询指令，可删除，仅执行发生状态变化的查询指令并返回执行结果，再根据执行结果修改第二数据，如将已有的第二数据中的订单状态修改为待揽收状态，得到查询结果，进而减小了订单查询的任务量，及时减少已有查询结果的商品查询指令，节省了系统的计算资源，减少系统算力，也提高了订单的查询效率。

参照图7，在一实施例中，还包括以下步骤，

S12:预测和增加与各订单状态对应的拟流转用时属性至所述第二数据中；

S121:当接收到用户端的用于商品更换的订单修订请求时，获取与订单号对应的第二数据；

S122:基于所述第二数据，判断所述订单修订请求是否满足预设条件；

S123:若所述订单修订请求满足预设条件，则通过所述订单修订请求，更新拟更换商品的库存数据和释放已取消商品的库存数据，并将所述订单修订请求的生效信息反馈至所述用户端。

针对已下单用户因下错单等想修改订单，而系统往往采取取消订单、重新下单方式而影响用户下单体验的问题，本申请通过历史订单数据情况统计，预测和增加与各订单状态对应的拟流转用时属性至第二数据中；当用户想修改订单，且为商品更换的订单修订请求时，根据各订单状态对应的拟流转用时属性，判断订单修订请求是否满足预设条件；若订单当前状态可满足修订要求，即订单修订请求满足预设条件，则在原订单的基础上修订，更新拟更换商品的库存数据和释放已取消商品的库存数据，并将订单修订请求的生效信息反馈至用户端，无需用户取消订单和重新下单，操作更便捷，改善了用户的下单体验感。

在一实施例中，还包括以下步骤，

S124:若所述订单修订请求不满足预设条件，则拒绝所述订单修订请求，并将所述订单修订请求的失败信息反馈至所述用户端。

根据各订单状态对应的拟流转用时属性，判断订单修订请求是否满足预设条件，若订单当前状态不满足修订要求，即订单修订请求不满足预设条件，此时从系统资源成本考虑，拒绝订单修订请求，并将订单修订请求的失败信息反馈至用户端，暗示用户取消订单并重新下单，节省经营成本。

在一实施例中，基于所述第二数据，判断所述订单修订请求是否满足预设条件的步骤包括，

基于当前查询时间，从所述第二数据中获取上一查询时间对应的订单状态和拟流转用时；

将所述当前查询时间与所述上一查询时间作差值，结合所述第二数据中与各订单状态对应的拟流转用时属性，预测当前查询时间对应的订单状态；

若所述订单未经历待揽收状态，则判定所述订单修订请求满足预设条件，否则，判定所述订单修订请求不满足预设条件。

根据各订单状态对应的拟流转用时属性，判断订单修订请求是否满足预设条件，将当前查询时间与上一查询时间作差值，结合第二数据中与各订单状态对应的拟流转用时属性，预测当前查询时间对应的订单状态，如订单审核状态、订单备货状态、订单待揽收状、订单配送状态、订单已完成状态等等；若订单未经历待揽收状态，则订单处于商品打包状态、订单备货状态、订单审核状态等，即来的及修订订单请求，则判定订单修订请求满足预设条件，否则，默认订单已打包或待揽收，无法进行订单请求修订，判定订单修订请求不满足预设条件。

例如，若订单修订请求为将黑色笔记本电脑更换为红色笔记本电脑，则查询拟修改订单的当前状态和预测流转时间，判断是接受修订请求还是拒绝修改请求，并在接受修订请求时更新修改商品的库存数据和释放已取消商品的库存数据。

综上所述，一种订单查询方法通过在安全域交换用户端和服务端的查询码，防止查询码在本地泄漏的情况发生，以及在获取认证信息的同时，对查询码进行核验，增加前置验证以确认用户身份的合法性后再进行订单查询，改善了订单查询过程中的数据安全性问题，前置验证也减少了订单查询时的耗时；同时，在订单查询前先发布订单查询任务消息至队列存储容器中，以便于异步执行订单查询任务，提高查询效率。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

参照图8，本申请实施例还提供一种订单查询装置，该一种订单查询装置与上述实施例中一种订单查询方法一一对应。该一种订单查询装置包括，

第一数据模块，用于先从用于订单交易的交易域获取来自用户端的订单号和对应的用户身份标识；

前置模块，用于基于所述用户身份标识，在用于风险防控的安全域交换用户端和服务端的查询码；

消息发布模块，用于发布与所述订单号对应的订单查询任务消息至队列存储容器中，并返回交换的所述查询码至所述用户端；

第二数据模块，用于再从所述交易域获取认证信息和待核验的所述查询码；

验证模块，用于在所述安全域核验所述查询码，判断是否核验成功；

查询模块，用于在核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果；

反馈模块，用于将所述查询结果返回至所述用户端。

一种订单查询装置还包括，

周期检测模块，用于判断订单的最后更新时间与当前时间的差值的绝对值是否超过预设时间阈值；

定期发布模块，用于在订单的最后更新时间与当前时间的差值的绝对值超过预设时间阈值时，发布与所述订单号对应的订单查询任务消息至队列存储容器中。

一种订单查询装置还包括，

定期缓存模块，用于缓存所述查询结果至所述交易域，直至再次发布与所述订单号对应的订单查询任务消息时，删除位于所述交易域的所述查询结果；

免验证模块，用于当再次获取到所述用户端的同一订单号时，默认返回与所述订单号对应的查询结果至所述用户端。

进一步地，所述反馈模块包括，

分页单元，用于将所述查询结果以分页形式返回至所述用户端。

一种订单查询装置还包括，

数据统一模块，用于按照预设的数据格式拆分和拼接所述查询结果，得到第一数据；

第一处理模块，用于为所述第一数据增加当次查询时间属性，得到第二数据。

一种订单查询装置还包括，

数据匹配模块，用于当获取到用户端的订单号时，先索引与所述订单号对应的第二数据；

指令修改模块，用于在存在与所述订单号对应的第二数据时，基于所述第二数据，修改和更新与所述订单号对应的所述订单查询任务，包括，删除所述订单查询任务中的、满足目标查询结果已包含于所述第二数据中的查询指令；

数据更新模块，用于当所述交易域执行更新的所述订单查询任务后，根据执行结果修改第二数据，得到查询结果。

一种订单查询装置还包括，

第二处理模块，用于预测和增加与各订单状态对应的拟流转用时属性至所述第二数据中；

修订请求模块，用于当接收到用户端的用于商品更换的订单修订请求时，获取与订单号对应的第二数据；

修订判断模块，用于基于所述第二数据，判断所述订单修订请求是否满足预设条件；

修订通过模块，用于在所述订单修订请求满足预设条件时，通过所述订单修订请求，更新拟更换商品的库存数据和释放已取消商品的库存数据，并将所述订单修订请求的生效信息反馈至所述用户端。

一种订单查询装置还包括，

修订拒绝模块，用于在所述订单修订请求不满足预设条件时，拒绝所述订单修订请求，并将所述订单修订请求的失败信息反馈至所述用户端。

进一步地，所述修订判断模块包括，

关联单元，用于基于当前查询时间，从所述第二数据中获取上一查询时间对应的订单状态和拟流转用时；

预测单元，用于将所述当前查询时间与所述上一查询时间作差值，结合所述第二数据中与各订单状态对应的拟流转用时属性，预测当前查询时间对应的订单状态；

判断单元，用于在所述订单未经历待揽收状态时，判定所述订单修订请求满足预设条件，否则，判定所述订单修订请求不满足预设条件。

关于一种订单查询装置的具体限定可以参见上文中对于一种订单查询方法的限定，在此不再赘述。

上述一种订单查询装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现上述任意一种订单查询方法。

在一个实施例中，提供了一种计算机可读存储介质，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

S1:先从用于订单交易的交易域获取来自用户端的订单号和对应的用户身份标识；

S2:基于所述用户身份标识，在用于风险防控的安全域交换用户端和服务端的查询码；

S3:发布与所述订单号对应的订单查询任务消息至队列存储容器中，并返回交换的所述查询码至所述用户端；

S4:再从所述交易域获取认证信息和待核验的所述查询码；

S5:在所述安全域核验所述查询码，以及，

S6:判断是否核验成功；

S7:当核验成功时，于所述交易域执行与所述订单号对应的所述订单查询任务，得到查询结果；

S8:将所述查询结果返回至所述用户端。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述系统的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。