一种订单处理方法、信息查询方法、及装置与流程

1.本发明涉及物流技术领域，特别涉及一种订单处理方法、信息查询方法、及装置。


背景技术：

2.现有接单系统中，一般使用订单管理中心接单，接单系统的系统架构如图1所示，其具体的接单流程为：用户通过isv、app、web等方式下单，订单管理中心负责接单并通过消息队列(mq)发给业务前台系统，如快递系统、冷链系统、大件系统等。由于订单管理中心要负责接单相关的处理逻辑，使得订单管理中心与前台业务系统紧密耦合，不利于接单系统的扩展。


技术实现要素：

3.有鉴于此，本发明的目的在于提供了一种订单处理方法、信息查询方法、及装置，能够解耦合订单管理中心和前台业务系统，提高接单系统的可扩展性。
4.为了达到上述目的，本发明提供了如下技术方案：
5.一种订单处理方法，应用于接口平台，该方法包括：
6.接收用户的下单请求；
7.确定所述下单请求的目标前台业务系统；
8.请求所述目标前台业务系统生成所述下单请求对应的订单；
9.确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
10.一种信息查询方法，该方法应用于接口平台，包括：
11.接收用户的查询请求；
12.根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求；
13.当确定所述查询请求是针对订单的通用查询请求时，将所述查询请求发送到订单管理中心，以使订单管理中心根据所述查询请求进行订单查询并返回查询结果，将查询结果反馈给用户；
14.当确定所述查询请求时针对业务的个性查询请求时，确定所述查询请求的目标前台业务系统，将所述查询请求发送到该目标前台业务系统，以使该目标前台业务系统根据所述查询请求进行业务查询并返回查询结果，将查询结果反馈给用户。
15.一种订单处理装置，应用于接口平台，该装置包括：
16.接收单元，用于接收用户的下单请求；
17.确定单元，用于确定所述下单请求的目标前台业务系统；
18.请求单元，用于请求所述目标前台业务系统生成所述下单请求对应的订单；
19.发送单元，用于确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
20.一种信息查询装置，该装置应用于接口平台，包括：
21.接收单元，用于接收用户的查询请求；
22.判断单元，用于根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求；
23.第一处理单元，用于当判断单元确定所述查询请求是针对订单的通用查询请求时，将所述查询请求发送到订单管理中心，以使订单管理中心根据所述查询请求进行订单查询并返回查询结果，将查询结果反馈给用户；
24.第二处理单元，用于当判断单元确定所述查询请求时针对业务的个性查询请求时，确定所述查询请求的目标前台业务系统，将所述查询请求发送到该目标前台业务系统，以使该目标前台业务系统根据所述查询请求进行业务查询并返回查询结果，将查询结果反馈给用户。
25.一种电子设备，包括：至少一个处理器，以及与所述至少一个处理器通过总线相连的存储器；所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序；所述至少一个处理器执行所述一个或多个计算机程序时实现上述订单处理方法中的步骤，或实现上述信息查询方法中的步骤。
26.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个计算机程序，所述一个或多个计算机程序被处理器执行时实现上述订单处理方法中的步骤，或实现上述信息查询方法中的步骤。
27.由上面的技术方案可知，本发明中，在接单系统中部署一接口平台，利用该接口平台连接接单系统中的订单管理中心及各前台业务系统，利用该接口平台代替订单管理中心执行接单系统的接单逻辑，即：接收下单请求，将该下单请求发送到其目标前台业务系统进行订单生成，再由该接口平台将下单请求及其对应的订单信息发送到订单管理中心进行存储。同时还利用该接口平台代替订单管理中心执行接单系统的查询逻辑，即：接收用户的查询请求，根据所述查询请求携带的查询类型，根据查询类型将查询请求发送到订单管理中心进行订单查询或将查询请求发送到前台业务系统进行业务查询。可以看出，本实施例中，利用接口平台替代订单管理中心执行接单系统的接单逻辑和查询逻辑，能够解耦合订单管理中心和前台业务系统，进而可以有效提高接单系统的可扩展性。
附图说明
28.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
29.图1是现有技术接单系统的架构示意图；
30.图2是本发明实施例接单系统的架构示意图；
31.图3是本发明实施例一订单处理方法流程图；
32.图4是本发明实施例二订单处理方法流程图；
33.图5是本发明实施例三订单处理方法流程图；
34.图6是本发明实施例四订单处理方法流程图；
35.图7是本发明实施例信息查询方法流程图；
36.图8是本发明实施例订单处理装置的结构示意图；
37.图9是本发明实施例信息查询装置的结构示意图；
38.图10是本发明实施例提供的电子设备的结构示意图。
具体实施方式
39.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
40.本发明实施例中，在接单系统中新增一接口平台，如图2所示，利用新增的接口平台代替订单管理中心执行接单相关的处理逻辑，可以使得订单管理中心和前台业务系统解耦和，从而可以有效提高接单系统的可扩展性。
41.以下结合附图对本发明提供的技术方案进行详细说明：
42.参见图3，图3是本发明实施例一订单处理方法流程图，该方法应用于接单系统中新增的接口平台，其中，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图3所示，该方法具体可以包括以下步骤：
43.步骤301、接收用户的下单请求；
44.步骤302、确定所述下单请求的目标前台业务系统；
45.步骤303、请求所述目标前台业务系统生成所述下单请求对应的订单；
46.步骤304、确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
47.根据图3所示方法可以看出，本实施例中，利用新部署在接单系统中的接口平台代替订单管理中心执行接单系统的接单逻辑，即：接收下单请求，确定该下单请求的目标前台业务系统并请求该目标前台业务系统生成该下单请求对应的订单，之后再由该接口平台将下单请求及其对应的订单信息发送到订单管理中心进行存储。可以看出，本实施例中，通过接口平台替代订单管理中心执行接单系统的接单逻辑，使得订单管理中心和前台业务系统解耦合，可以有效提高接单系统的可扩展性。
48.参见图4，图4是本发明实施例二订单处理方法流程图，该方法应用于接单系统中新增的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图4所示，该方法具体可以包括以下步骤：
49.步骤401、接收用户的下单请求；
50.本实施例中，接收到用户的下单请求后，执行后续步骤20a之前，还可以先对用户进行身份验证，具体可以是验证用户是物品购买者还是物品提供者。
51.正常情况下，只有物品购买者会下单，物品提供者则不会下单，因此，当接收到用户的下单请求后，如果验证用户是物品提供者，则可以直接拒绝该下单请求，不再执行后续步骤。
52.步骤40a、为所述下单请求预分配订单编号；
53.本实施例中，可以在生成所述下单请求对应的订单之前预占用一个订单编号，并
在生成所述下单请求对应的订单之后作为该订单的订单编号，这样可以避免不同前台业务系统生成订单时可能出现的订单编号冲突。
54.步骤402、确定所述下单请求的目标前台业务系统；
55.步骤403、请求所述目标前台业务系统生成所述下单请求对应的订单；
56.步骤404、确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将为所述下单请求预分配的订单编号确定为所述下单请求对应的订单的订单编号，并将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
57.本实施例中，确定所述目标前台业务系统成功生成所述下单请求对应的订单后，还可以返回下单成功信息给用户，使得用户明确下单成功。
58.本实施例中，如果确定所述目标前台业务系统未能成功生成所述下单请求对应的订单，则可以返回下单失败消息给用户，使得用户明确下单失败。
59.根据图4所示方法可以看出，本实施例中，利用新部署在接单系统中的接口平台代替订单管理中心执行接单系统的接单逻辑，即：接收下单请求，预分配订单编号，确定该下单请求的目标前台业务系统并请求该目标前台业务系统生成该下单请求对应的订单，将预占订单编号分配给该订单，之后再由该接口平台将下单请求及其对应的订单信息发送到订单管理中心进行存储。可以看出，本实施例中，通过接口平台替代订单管理中心执行接单系统的接单逻辑，能够使得订单管理中心和前台业务系统的功能各自独立，由紧耦合转变为松耦合，可以有效提高接单系统的可扩展性；另外，本实施例还通过预占订单编号的方式避免不同前台业务系统生成订单时可能出现的订单编号冲突。
60.参见图5，图5是本发明实施例三订单处理方法流程图，该方法应用于接单系统中新增的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图5所示，该方法具体可以包括以下步骤：
61.步骤501、接收用户的下单请求；
62.本实施例中，接收到用户的下单请求后，执行后续步骤20a之前，还可以先对用户进行身份验证，具体可以是验证用户是物品购买者还是物品提供者。
63.正常情况下，只有物品购买者会下单，物品提供者则不会下单，因此，当接收到用户的下单请求后，如果验证用户是物品提供者，则可以直接拒绝该下单请求，不再执行后续步骤。
64.步骤50a、为所述下单请求预分配订单编号；
65.本实施例中，可以在生成所述下单请求对应的订单之前预占用一个订单编号，并在生成所述下单请求对应的订单之后作为该订单的订单编号，这样可以避免不同前台业务系统生成订单时可能出现的订单编号冲突。
66.步骤50b、存储所述下单请求和为所述下单请求预分配的订单编号，并将所述下单请求标记为未结束的下单请求。
67.本实施例中，可以将所述下单请求和为所述下单请求预分配的订单编号作为一条下单记录存储到数据库中，并通过加未结束标记的方式，表明所述下单请求是尚未结束的请求。
68.步骤502、确定所述下单请求的目标前台业务系统；
69.步骤503、请求所述目标前台业务系统生成所述下单请求对应的订单；
70.本实施例中，所述目标前台业务系统成功生成所述下单请求对应的订单后，可以将所述下单请求的订单状态标记为订单已生成。如果所述目标前台业务系统未成功生成所述下单请求对应的订单，则可以将所述下单请求的订单状态标记为订单未生成。
71.步骤504、确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将为所述下单请求预分配的订单编号确定为所述下单请求对应的订单的订单编号，并将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
72.本实施例中，确定所述目标前台业务系统成功生成所述下单请求对应的订单后，还可以返回下单成功信息给用户，使得用户明确下单成功。
73.本实施例中，如果确定所述目标前台业务系统未能成功生成所述下单请求对应的订单，则可以返回下单失败消息给用户，使得用户明确下单失败。
74.步骤50c、将所述下单请求标记为已结束的下单请求。
75.本实施例中，通过在为所述下单请求预分配一订单编号之后，请求所述目标前台业务系统生成所述下单请求对应的订单之前，将所述下单请求标记为未结束的下单请求；而在确定所述目标前台业务系统成功生成所述下单请求对应的订单后将所述下单请求标记为已结束的订单请求，使得所述下单请求的执行状态能够根据执行进程保持一致性。
76.然而，将所述下单请求标记为未结束的下单请求后，如果接口平台因某些原因，如掉电，而发生重启时，在重启成功之前所述目标前台业务系统可能已经成功生成所述下单请求对应的订单，这种情况下，接口平台在重启成功后也可能不会将所述下单请求标记成已结束的下单请求，导致出现所述下单请求的执行状态不一致的问题。
77.对于上述问题，本实施例中，可以利用一个定期检测任务解决，具体地，可以定期检测存储的所有下单请求，找到标记为未结束的下单请求，通过向每一下单请求的目标前台业务系统查询该下单请求的订单状态，从而保证该下单请求的执行状态一致性。
78.本实施例中，定期检测任务的执行步骤具体包括：
79.s11、定期在存储的下单请求中查找标记为未结束的下单请求；
80.s12、对于查找到的每一下单请求，执行以下操作步骤s12a至s12b：
81.s12a、确定该下单请求的目标前台业务系统；
82.s12b、向该目标前台业务系统查询该下单请求的订单状态；
83.上述步骤s12b中，向该目标前台业务系统查询该下单请求的订单状态，具体包括：向该目标前台业务系统发送针对该下单请求的订单状态查询请求，接收该目标前台业务系统反馈的该下单请求的订单状态。
84.其中，该目标前台业务系统接收到针对该下单请求的订单状态查询请求后，可以查找该下单请求的订单状态，如果查找到且该下单请求的订单状态为订单已生成，则反馈该下单请求的订单状态为订单已生成，如果未查找到、或虽然查找到但是该下单请求的订单状态为订单未生成，则反馈该下单请求的订单状态为订单未生成。
85.s12c、判断该下单请求的订单状态，如果该下单请求的订单状态为订单已生成，则执行步骤s12d，如果该下单请求的订单状态为订单未生成，则执行步骤s12e；
86.s12d、将该下单请求标记为已结束的下单请求；
87.s12e、请求该目标前台业务系统生成该下单请求对应的订单，并在确定该目标前台业务系统成功生成该下单请求对应的订单后，将该下单请求标记为已结束的下单请求。
88.上述步骤s12e中，请求该目标前台业务系统生成该下单请求对应的订单的具体方法将在后续进行详细介绍，此处不做赘述。
89.根据图5所示方法可以看出，本实施例中，利用新部署在接单系统中的接口平台代替订单管理中心执行接单系统的接单逻辑，即：接收下单请求，预分配订单编号并将所述下单请求标记为未结束的下单请求，确定该下单请求的目标前台业务系统并请求该目标前台业务系统生成该下单请求对应的订单，将预占订单编号分配给该订单，之后再由该接口平台将下单请求及其对应的订单信息发送到订单管理中心进行存储，并将所述下单请求标记为已结束的下单请求。可以看出，本实施例中，通过接口平台替代订单管理中心执行接单系统的接单逻辑，能够使得订单管理中心和前台业务系统的功能各自独立，由紧耦合转变为松耦合，可以有效提高接单系统的可扩展性；另外，本实施例还通过预占订单编号的方式避免不同前台业务系统生成订单时可能出现的订单编号冲突；此外还可以保证下单请求的执行状态的一致性。
90.参见图6，图6是本发明实施例四订单处理方法流程图，该方法应用于接单系统中新增的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图6所示，该方法具体可以包括以下步骤：
91.步骤601、接收用户的下单请求；
92.本实施例中，接收到用户的下单请求后，执行后续步骤之前，还可以先对用户进行身份验证，具体可以是验证用户是物品购买者还是物品提供者。
93.正常情况下，只有物品购买者会下单，物品提供者则不会下单，因此，当接收到用户的下单请求后，如果验证用户是物品提供者，则可以直接拒绝该下单请求，不再执行后续步骤。
94.步骤602、确定所述下单请求的目标前台业务系统；
95.本实施例中，所述接单系统中的前台业务系统包括冷链系统、快递系统、大件系统等。
96.本实施例中，可以预先设置所述接单系统中的每一前台业务系统对应的下单类型。例如冷链系统对应的下单类型为冷链类型；快递系统对应的下单类型为快递类型；大件系统对应的下单类型为大件类型。
97.本实施例中，确定所述下单请求的目标前台业务系统，可具体包括：确定所述接单系统中下单类型为所述下单请求携带的下单类型的前台业务系统，将该前台业务系统确定为所述下单请求的目标前台业务系统。
98.步骤6031、向所述目标前台业务系统发送针对所述下单请求的订单生成请求，接收所述目标前台业务系统返回的订单生成响应；
99.本实施例中，所述目标前台业务系统接收到针对所述下单请求的订单生成请求后，会根据所述下单请求生成对应的订单，如果成功生成订单，则反馈指示成功生成订单的订单生成响应，否则，反馈指示生成订单失败的订单生成响应。其中，指示成功生成订单的订单生成响应中还携带成功生成的订单信息。
100.步骤6032、判断所述订单生成响应是否指示生成订单成功，如果是，则执行步骤6033，否则，执行步骤6034；
101.步骤6033、确定所述目标前台业务系统成功生成所述下单请求对应的订单，并将
所述订单生成响应中携带的订单信息确定为所述下单请求对应的订单信息，转至步骤604；
102.步骤6034、确定所述目标前台业务系统未成功生成所述下单请求对应的订单。
103.以上步骤6031至步骤6034是图3所示步骤303的具体细化。上述实施例三中的步骤s12e中，“请求该目标前台业务系统生成该下单请求对应的订单”也可以采用以上步骤6031至步骤6034实现。
104.步骤604、将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
105.本实施例中，确定所述目标前台业务系统成功生成所述下单请求对应的订单后，还可以返回下单成功信息给用户，使得用户明确下单成功。
106.本实施例中，如果确定所述目标前台业务系统未能成功生成所述下单请求对应的订单，则可以返回下单失败消息给用户，使得用户明确下单失败。
107.根据图6所示方法可以看出，本实施例中，利用新部署在接单系统中的接口平台代替订单管理中心执行接单系统的接单逻辑，即：接收下单请求，确定该下单请求的目标前台业务系统并请求该目标前台业务系统生成该下单请求对应的订单，之后再由该接口平台将下单请求及其对应的订单信息发送到订单管理中心进行存储。可以看出，本实施例中，通过接口平台替代订单管理中心执行接单系统的接单逻辑，使得订单管理中心和前台业务系统解耦合，可以有效提高接单系统的可扩展性。
108.图3至图6所示方法中，对于接单系统新部署的接口平台替代订单管理中心承担接单相关的处理逻辑进行了详细说明，本发明实施例中，接单系统新部署的接口平台还可以替代订单管理中心承担查询订单信息、查询业务信息相关的处理逻辑，以下结合图7进行说明。
109.参见图7，图7是本发明实施例信息查询方法流程图，该方法应用于接单系统中新增的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图7所示，该方法具体可以包括以下步骤：
110.步骤701、接收用户的查询请求；
111.本发明中，所述接口平台在执行接单相关的处理逻辑时，将下单请求和订单信息均发送到订单管理中心存储，因此订单管理中心可以提供对订单相关信息的查询，而根据下单请求生成订单的业务仍然由前台业务系统处理，因此前台业务系统可以提供业务相关信息的查询。
112.本发明实施例中，所述接口平台替代订单管理中心实现订单、业务相关的查询逻辑，具体是接收用户的查询请求，确定查询请求的查询类型，根据查询类型确定是将查询请求发送到订单管理中心进行订单相关信息查询还是发送到前台业务系统进行业务相关信息查询。
113.本实施例中，接收到用户的查询请求后，执行后续步骤702之前，还可以先对用户进行身份验证，具体可以是验证用户是物品购买者还是物品提供者。
114.本实施例中，在对用户进行身份验证之后，还可以检测用户身份和查询类型是否匹配，如果不匹配则可以拒绝查询，例如用户是物品购买者的情况下，不允许执行针对业务的查询，即查询请求携带的查询类型不可以是订单查询；用户是物品提供者的情况下，不允许执行针对订单的查询，即查询请求携带的查询类型不可以是业务查询。
115.步骤702、根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求，如果所述查询请求是针对订单的通用查询请求，则执行步骤703，如果所述查询请求时针对业务的个性查询请求，则执行步骤704；
116.本实施例中，所述查询类型包括订单查询和业务查询；
117.本实施例中，根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求，具体包括：
118.s21、当所述查询请求携带的查询类型是订单查询时，确定所述查询请求是针对订单的通用查询请求；
119.s22、当所述查询请求携带的查询类型是业务查询时，确定所述查询请求是针对业务的个性查询请求。
120.步骤703、将所述查询请求发送到订单管理中心，以使订单管理中心根据所述查询请求进行订单查询并返回查询结果，将查询结果反馈给用户；
121.步骤704、确定所述查询请求的目标前台业务系统，将所述查询请求发送到该目标前台业务系统，以使该目标前台业务系统根据所述查询请求进行业务查询并返回查询结果，将查询结果反馈给用户。
122.本实施例中，可以预先设置所述接单系统中每一前台业务系统对应的业务类型。
123.本实施例中，确定所述查询请求的目标前台业务系统，具体包括：确定所述接单系统中业务类为所述查询请求携带的业务类型的前台业务系统，将该前台业务系统确定为所述查询请求的目标前台业务系统。
124.根据图7所示方法可以看出，本实施例中，利用新部署在接单系统中的接口平台代替订单管理中心执行接单系统的接单逻辑，另外还负责对用户的查询请求根据查询类型分发到订单管理中心或前台业务系统进行相应的结果查询，替代了订单管理中心执行查询请求的分发，可以进一步减少订单管理中心和前台业务系统的耦合，能够有效提高接单系统的可扩展性。
125.以上对本发明实施例订单处理方法和信息查询方法分别进行了详细说明，本发明实施例还提供了一种订单处理装置和一种信息查询装置，以下结合图8、9进行详细说明。
126.参见图8，图8是本发明实施例订单处理装置的结构示意图，该装置应用于接单系统中的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图8所示，该装置包括：
127.接收单元801，用于接收用户的下单请求；
128.确定单元802，用于确定所述下单请求的目标前台业务系统；
129.请求单元803，用于请求所述目标前台业务系统生成所述下单请求对应的订单；
130.发送单元804，用于确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将所述下单请求和所述下单请求对应的订单信息发送到订单管理中心存储。
131.图8所示装置中，
132.所述请求单元803，请求所述目标前台业务系统生成所述下单请求对应的订单之前，进一步包括：为所述下单请求预分配订单编号；
133.所述发送单元804，确定所述目标前台业务系统成功生成所述下单请求对应的订单时，将为所述下单请求预分配的订单编号确定为所述下单请求对应的订单的订单编号。
134.图8所示装置中，
135.所述请求单元803，为所述下单请求预分配一订单编号之后，请求所述目标前台业务系统生成所述下单请求对应的订单之前，进一步包括：存储所述下单请求和为所述下单请求预分配的订单编号，并将所述下单请求标记为未结束的下单请求；
136.所述发送单元804，确定所述目标前台业务系统成功生成所述下单请求对应的订单后，进一步包括：将所述下单请求标记为已结束的下单请求。
137.图8所示装置还包括：定期任务单元805；
138.所述定期任务单元805，用于：
139.定期在存储的下单请求中查找标记为未结束的下单请求；
140.对于查找到的每一下单请求，执行以下操作：
141.确定该下单请求的目标前台业务系统；
142.向该目标前台业务系统查询该下单请求的订单状态；
143.如果该下单请求的订单状态为订单已生成，则将该下单请求标记为已结束的下单请求；
144.如果该下单请求的订单状态为订单未生成，则请求该目标前台业务系统生成该下单请求对应的订单，并在确定该目标前台业务系统成功生成该下单请求对应的订单后，将该下单请求标记为已结束的下单请求。
145.图8所示装置中，
146.所述请求单元803，请求所述目标前台业务系统生成所述下单请求对应的订单，包括：
147.向所述目标前台业务系统发送针对所述下单请求的订单生成请求，接收所述目标前台业务系统返回的订单生成响应；
148.如果所述订单生成响应指示生成订单成功，则确定所述目标前台业务系统成功生成所述下单请求对应的订单，并将所述订单生成响应中携带的订单信息确定为所述下单请求对应的订单信息；
149.如果所述订单生成响应指示生成订单失败，则确定所述目标前台业务系统未成功生成所述下单请求对应的订单。
150.图8所示装置中，还包括配置单元806；
151.所述配置单元806，用于预先设置所述接单系统中的每一前台业务系统对应的下单类型；
152.所述确定单元802，确定所述下单请求的目标前台业务系统，包括：确定所述接单系统中下单类型为所述下单请求携带的下单类型的前台业务系统，将该前台业务系统确定为所述下单请求的目标前台业务系统。
153.参见图9，图9是本发明实施例信息查询装置的结构示意图，该装置应用于接单系统中的接口平台，所述接口平台分别与所述接单系统中的订单管理中心和所述接单系统中的各前台业务系统相连，如图9所示，该装置包括：
154.接收单元901，还用于接收用户的查询请求；
155.判断单元902，用于根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求；
156.第一处理单元903，用于当判断单元902确定所述查询请求是针对订单的通用查询请求时，将所述查询请求发送到订单管理中心，以使订单管理中心根据所述查询请求进行订单查询并返回查询结果，将查询结果反馈给用户；
157.第二处理单元904，用于当判断单元902确定所述查询请求时针对业务的个性查询请求时，确定所述查询请求的目标前台业务系统，将所述查询请求发送到该目标前台业务系统，以使该目标前台业务系统根据所述查询请求进行业务查询并返回查询结果，将查询结果反馈给用户。
158.图9所示装置中，
159.所述判断单元902，根据所述查询请求携带的查询类型，判断所述查询请求是针对订单的通用查询请求还是针对业务的个性查询请求，包括：
160.当所述查询请求携带的查询类型是订单查询时，确定所述查询请求是针对订单的通用查询请求；
161.当所述查询请求携带的查询类型是业务查询时，确定所述查询请求是针对业务的个性查询请求。
162.图9所示装置中，还包括配置单元905；
163.所述配置单元905，用于预先设置所述接单系统中每一前台业务系统对应的业务类型；
164.所述判断单元902，确定所述查询请求的目标前台业务系统，包括：确定所述接单系统中业务类为所述查询请求携带的业务类型的前台业务系统，将该前台业务系统确定为所述查询请求的目标前台业务系统。
165.本发明实施例还提供了一种电子设备，如图10所示，该电子设备包括：至少一个处理器1001，以及与所述至少一个处理器1001通过总线相连的存储器1002；所述存储器1002存储有可被所述至少一个处理器1001执行的一个或多个计算机程序；所述至少一个处理器执行所述一个或多个计算机程序时实现如图3
‑
6中任一流程图所示的订单处理方法中的步骤，或实现如图7所示的信息查询方法中的步骤。
166.本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个计算机程序，所述一个或多个计算机程序被处理器执行时实现如图3
‑
6中任一流程图所示的订单处理方法中的步骤，或实现如图7所示的信息查询方法中的步骤。
167.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。