订单信息的存储方法、系统、装置、设备及存储介质与流程

本申请涉及计算机领域，特别涉及一种订单信息的存储方法、系统、装置、设备及存储介质。
背景技术：
：景区是以旅游及相关活动为主要功能或主要功能之一的区域场所。景区中设置有基于计算机的售票系统和检票系统，简称售检票系统。相关技术中，景区所使用的售检票系统是由系统商提供的。系统商生产和制造售检票系统，在景区的售票点设置售票系统，在景区的出入口设置检票系统，以及为景区设置数据中心。该数据中心会存储有售票的订单信息。由于不同系统商提供的数据存储能力并不一致，若景区将旧系统商a切换为新系统商b，则旧系统商a所产生的订单信息无法再继续利用。技术实现要素：本申请实施例提供了一种订单信息的存储方法、系统、装置、设备及存储介质，可以将采用统一接口接收到的订单信息存储至数据库中，不论系统商是否更换，均能够保证景区工作人员对订单信息的正常使用。所述技术方案如下：根据本申请的一个方面，提供了一种订单信息的存储方法，所述方法应用于统一预订设备，所述统一预订设备是位于售检票系统和后台系统之间的设备，所述方法包括：通过订单接口向所述后台系统发送订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口；接收所述后台系统发送的订单响应报文，所述订单响应报文包括所述订单信息；将所述订单响应报文中的所述订单信息存储至数据库中。根据本申请的另一个方面，提供了一种订单信息的存储方法，所述方法应用于后台系统，所述方法包括：通过订单接口接收统一预订设备发送的订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口，所述统一预订设备是位于售检票系统和后台系统之间的设备；根据所述订单请求报文生成订单响应报文，所述订单响应报文包括所述订单信息；向所述统一预订设备发送所述订单响应报文。根据本申请的另一个方面，提供了一种订单信息的存储系统，所述系统包括：统一预订设备和数据库，所述统一预订设备是位于售检票系统和后台系统之间的设备；所述统一预订设备，用于执行上述由统一预订设备执行的所述的订单信息的存储方法，以将全量订单的订单信息存储在所述数据库中；所述数据库，用于存储所述全量订单的订单信息。根据本申请的另一个方面，提供了一种订单信息的存储装置，所述装置是位于售检票系统和后台系统之间的装置，所述装置包括：第一发送模块，用于通过订单接口向所述后台系统发送订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口；第一接收模块，用于接收所述后台系统发送的订单响应报文，所述订单响应报文包括所述订单信息；存储模块，用于将所述订单响应报文中的所述订单信息存储至数据库中。根据本申请的另一个方面，提供了一种订单信息的存储装置，所述装置包括：第二接收模块，用于通过订单接口接收统一预订设备发送的订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口，所述统一预订设备是位于售检票系统和后台系统之间的设备；第二生成模块，用于根据所述订单请求报文生成订单响应报文，所述订单响应报文包括所述订单信息；第二发送模块，用于向所述统一预订设备发送所述订单响应报文。根据本申请的另一方面，提供了一种计算机设备，所述计算机设备包括：处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如上面所述的由统一预订设备执行的订单信息的存储方法。根据本申请的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现如上面所述的由统一预订设备执行的订单信息的存储方法。根据本申请的另一方面，提供了一种计算机设备，所述计算机设备包括：处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如上面所述的由后台系统执行的订单信息的存储方法。根据本申请的另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现如上面所述的由后台系统执行的订单信息的存储方法。本申请实施例提供的技术方案带来的有益效果至少包括：通过由统一预订设备通过订单接口向后台系统发送订单请求报文，并由统一预订设备接收后台系统返回的订单响应报文，订单响应报文中包括订单信息，统一预订设备将订单信息存储至数据库中，实现了不论系统商有多少个，也不论系统商是否发生了更换，系统商的后台系统都可以通过订单接口将订单信息发送至统一预订设备中存储，进而将符合订单接口格式的订单信息沉淀在数据库中，供景区工作人员的分析和使用，提高了景区自身的数据中心的数据使用率和抗风险性。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1示出了本申请一个示例性实施例提供的计算机系统的结构框图；图2示出了本申请一个示例性实施例提供的订单信息的存储方法的流程图；图3示出了本申请另一个示例性实施例提供的订单信息的存储方法的流程图；图4示出了本申请另一个示例性实施例提供的订单信息的存储方法的流程图；图5是本申请另一个示例性实施例提供的订单信息的存储系统的示意图；图6是本申请另一个示例性实施例提供的订单信息的存储装置的示意图；图7是本申请另一个示例性实施例提供的订单信息的存储装置的示意图；图8是本申请一个示例性实施例提供的计算机设备的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。首先对本申请涉及的几个名词进行介绍：景区：是以旅游及相关活动为主要功能或主要功能之一的区域场所。渠道：是用于售卖景区门票的销售渠道。按照类型划分，渠道包括：现金窗口渠道、官方网站渠道、官方移动互联网入口渠道(比如微信)、旅行社渠道、特殊团队渠道、ota(onlinetravelagency，在线旅行社)、网上商店或其它渠道中的至少一种。同一个景区可以拥有多个渠道，同一个商家也可以拥有多个渠道。系统商：用于为景区的售检票系统，提供后台服务的服务商。可选地，售检票系统中的前端和硬件设备，也可以由系统商向景区提供。票务数据：在景区门票的售票过程和检票过程中生成的数据。票务数据包括：用户数据、订单信息、产品数据和渠道数据中的至少一种。用户数据：在票务数据中，与用户帐号的注册、登录和管理有关的数据。订单信息；在票务数据中，与门票订单的下单、核销和改签有关的数据。产品数据：在票务数据中，与门票产品的上架、下架、库存有关的数据。渠道数据：在票务数据中，与门票的售卖渠道有关的数据。统一预订设备：是在本申请中，在售检票系统和后台系统之间新增加的设备。用于实现售检票系统和后台系统之间的报文转发，以及报文格式的统一。并且，统一预订设备还用于将后台系统中的票务数据，为景区在数据库中额外备份一份。图1示出了本申请一个示例性实施例提供的计算机系统100的框图。计算机系统100包括：售检票系统120、统一预订设备140、后台系统160和数据库180。售检票系统120是一套软件系统，可以部署在每个景区以及各个渠道。以景区1为例，在部署售检票系统120后，提供一个或多个渠道的门票售卖服务。示意性的，渠道包括：现金窗口、官方网站、官方微信公众号(一种移动互联网入口)、旅行社、特殊团队、ota(onlinetravelagency，在线旅行社)或其它渠道中的至少一种。特殊团队包括：学生团队、老人团队、教师团队等。统一预订设备140用于向售检票系统120和后台系统160提供统一形式的标准化接口，简称统一接口。该统一接口用于与售检票系统120之间收发报文，和/或，该统一接口用于与后台系统160之间收发报文。示意性的，该统一接口包括：产品变更接口、订单相关接口、景区渠道设置接口、景区自营用户接口等。可选地，统一预订设备140还用于在景区和后台系统160之间进行报文的路由转发，以及在渠道和后台系统之间进行报文的路由转发。示例性的，统一路由规则中包括：景区与后台系统之间的路由规则，景区与售卖渠道之间的路由规则。后台系统160是指由售检票系统的系统商提供的计算机系统。后台系统160通过售检票系统120向景区提供售检票服务。后台系统160可以有多个。每个景区与至少一个后台系统160绑定。数据库180用于为景区120存储票务数据。其中，票务数据包括：用户数据、订单信息、产品数据和渠道数据中的至少一种。数据库180是统一预订设备140为景区120设置的数据库。可选地，每个景区120对应各自的数据库。示例性的，景区对应第一组织机构(比如政府)，统一预订设备140对应第二组织结构(比如ota平台商)，后台系统160对应第三组织结构(比如系统商)。其中，售检票系统120和统一预订设备140均由第二组织结构提供。在一个可能的设计中，售检票系统120发送第一报文，由统一预订设备140向后台系统160转发第一报文。在后台系统160反馈第一报文的响应报文后，由统一预订设备140将响应报文转发给售检票系统120。由统一预订设备140将第一报文或响应报文中的票务数据存储至数据库180中。在另一个可能的设计中，由后台系统160将第二报文推送至统一预订设备140，由统一预订设备140将第二报文中的票务数据存储至数据库180中。在本系统中，售检票系统120包括售检票系统的前端。售检票系统的前端可以是第一组织机构提供的前端，也可以是第二组织机构提供的前端，还可以是第三组织机构提供的前端。在另一个实施例中，售检票系统120可设计为云服务形式，运行在后台系统160中，各个景区或渠道可以通过浏览器形式(或应用程序的内置浏览器)来访问该售检票系统120。在本系统中，统一预订设备140和后台系统160形成售检票系统120的后端。需要说明的一点是，上述景区可以为多个，每个景区对应有自身的售检票系统。每个景区还对应有一个系统商。对于同一个景区，该景区的系统商还可能会系统商1切换为系统商2。此时，售检票系统的后台系统，也会从后台系统1切换为后台系统2。需要说明的另一点是，由于存在多个景区的售检票系统120和/或多个系统商的后台系统160，统一预订设备140具有路由转发功能。但是在某些实施例中，比如仅有一个售检票系统120和一个后台系统160时，可以不设置统一路由设备144。需要说明的另一点是，后台系统160存储有一份原始票务数据，图1中所示的数据库是用于存储供景区使用的备份票务数据。由于备份票务数据是原始票务数据的备份，因此在理想情况下，备份票务数据与原始票务数据完全相同，或者，内容相同仅数据格式不同。示例性的，在一种订单信息的存储方法中，系统商为每个景区建立售检票系统，该系统部署在景区服务器上。例如，景区1通过系统商1建立的售检票系统部署在景区1的服务器上，景区2通过系统商1建立的售检票系统部署在景区2的服务器上，景区3通过系统商2建立的售检票系统部署在景区3的服务器上。在另一种订单信息的存储方法中，系统商为每个景区建立的售检票系统部署在云服务器上。例如，景区1通过系统商1建立的售检票系统部署在云服务器1上，景区2通过系统商1建立的售检票系统也部署在云服务器1上，景区3通过系统商2建立的售检票系统部署在云服务器2上。上述两种订单信息的存储方法，如果景区想要更换系统商，不同系统商设计售检票系统的方案不同、数据存储格式不同，使数据迁移成本非常高，历史订单数据极易丢失。图2示出了本申请的一个示例性实施例提供的订单信息的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订设备140和后台系统160中来举例说明。该方法包括：步骤204，统一预订设备通过订单接口向后台系统发送订单请求报文，订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，订单接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互，订单接口是后台系统提供的接口；统一预订设备是位于售检票系统和后台系统之间的设备。订单接口是统一预订设备和后台系统之间的程序接口。订单接口是由统一预订设备向后台系统提供的程序接口，和/或，订单接口是由后台系统向统一预订设备提供的程序接口。示例性的，订单接口有统一的报文格式要求，订单请求报文是符合订单接口报文格式要求的报文。示例性的，统一预订设备按照订单接口的报文格式要求生成订单请求报文，订单请求报文中包括请求的内容。示例性的，订单接口是统一预订设备提供给至少两个后台系统使用的。即，订单接口的报文格式要求、报文模板等是由统一预订设备设定的，后台系统使用设定好的订单接口来接收、识别并处理统一预订设备通过请求接口发送的报文，或，按照设定好的订单接口向统一预订设备发送报文。示例性的，订单信息包括订单基本信息、订单消费者人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息中的至少一种。示例性的，每种订单信息在订单响应报文中都对应有多个参数字段，具体参数字段详见下文中对订单接口的具体描述。全量订单是指商家在一定时间段内的所有订单。示例性的，商家可以指景区、公司、店面等。或，商家指某个商家在某个售卖渠道上的虚拟店铺，例如，商家a在第三方销售平台上设立的虚拟店铺a。示例性的，订单请求报文中包括了需要请求的：商家的标识、指定时间段、订单数量、订单类型、订单处理状态、订单核销状态、订单生成渠道中的至少一个请求内容。例如，请求报文用于请求商家a通过第一渠道在7月22日到7月28日间生成，且已经核销过的订单的订单信息。示例性的，订单请求报文是当统一预订设备需要请求订单信息时主动向后台系统发送的。示例性的，订单请求报文可以是统一预订设备周期性地向后台系统发送的，也可以是当满足发送条件时，统一预订设备向后台系统发送的。发送条件可以是任意的，例如，当统一预订设备检测到缺失某个商家在某一日的订单信息时，向后台系统发送订单请求报文，或，当统一预订设备接收到新生成的订单时，向后台系统发送订单请求报文，或，当统一预订设备接收到景区需要更换后台系统的指令时，向后台系统发送订单请求报文。步骤205，后台系统通过订单接口接收统一预订设备发送的订单请求报文，订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，订单接口适用于统一预订设备与至少两个不同的后台系统之间的信息交互，订单接口是后台系统提供的接口；步骤206，后台系统根据订单请求报文生成订单响应报文，订单响应报文包括订单信息。示例性的，后台系统根据订单请求报文中的具体请求内容，生成对应的订单响应报文，订单响应报文中包括统一预订设备所请求的订单信息。示例性的，订单响应报文是后台系统按照订单接口的报文格式要求生成的。步骤207，后台系统向统一预订设备发送订单响应报文。步骤208，统一预订设备接收后台系统发送的订单响应报文，订单响应报文包括订单信息。步骤209，将订单响应报文中的订单信息存储至数据库中。示例性的，统一预订设备将订单响应报文中的订单信息据按照统一格式存储至数据库中。综上所述，本实施例提供的方法，通过由统一预订设备通过订单接口向后台系统发送订单请求报文，并由统一预订设备接收后台系统返回的订单响应报文，订单响应报文中包括订单信息，统一预订设备将订单信息存储至数据库中，实现了不论系统商有多少个，也不论系统商是否发生了更换，系统商的后台系统都可以通过订单接口将订单信息发送至统一预订设备中存储，进而将符合订单接口格式的订单信息沉淀在数据库中，供景区工作人员的分析和使用，提高了景区自身的数据中心的数据使用率和抗风险性。图3示出了本申请的一个示例性实施例提供的订单信息的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订设备140和后台系统160中来举例说明。该方法在图2所示的示例性实施例的基础上，步骤204之前还包括步骤201至步骤203，步骤204包括步骤2041，步骤206包括步骤2061至步骤2064、步骤209包括步骤2091至步骤2092。步骤201，统一预订设备获取订单请求报文的请求报文模板，请求报文模板的模板类型字段为订单信息请求字段。示例性的，通过订单接口发送订单请求报文有统一的请求报文模板，当统一预订设备需要向后台系统发送订单请求报文时，获取该请求报文模板。示例性的，请求报文模板包括多个参数字段，其中模板类型字段为订单信息请求字段。示例性的，订单信息请求字段被命名为“orderinforequest”。示例性的，请求报文模板中的其他参数字段，详见下文对订单接口的详细说明中，对请求的参数字段的介绍。步骤202，统一预订设备获取请求报文模板所需要的至少一个参数内容。示例性的，统一预订设备根据需要请求的内容填入请求报文模板生成订单请求报文。示例性的，请求报文模板有需要填入的参数内容，参数内容包括：获取请求报文模板所需要的商家标识id、订单渠道、每页数量、页数、开始日期、结束日期中的至少一个。例如，统一预订设备获取需要查询的订单的商家标识id“001”、订单渠道“第一渠道”、每页数量“10”、页数“5”、开始日期“2019-10-01”、结束日期“2019-11-01”。即，获取001商家通过第一渠道从2019年10月1日到2019年11月1日的10条订单信息。步骤203，统一预订设备根据请求报文模板和至少一个参数内容生成订单请求报文。示例性的，统一预订设备将具体的参数内容填入请求报文模板生成订单请求报文。示例性的，清单请求报文详见下文中对订单接口的详细说明。步骤2041，统一预订设备通过订单接口采用post方式向后台系统发送订单请求报文。示例性的，当后台系统包括第一后台系统和第二后台系统时，第一后台系统对应第一url(uniformresourcelocator,统一资源定位符)，第二后台系统对应第二url；响应于向第一后台系统发送订单请求报文，统一预订设备调用订单接口向第一url所指示的第一后台系统发送post类型的订单请求报文；响应于向第二后台系统发送订单请求报文，统一预订设备调用订单接口向第二url所指示的第二后台系统发送post类型的订单请求报文。步骤2061，后台系统识别订单请求报文的模板类型字段。示例性的，订单请求报文是统一预订设备采用post方式调用订单接口向统一资源定位符url所指示的后台系统发送的。步骤2062，后台系统响应于模板类型字段为订单信息请求字段，获取订单请求报文对应的订单响应报文的响应报文模板，响应报文模板的模板类型字段为订单信息响应字段。示例性的，当模板类型字段为订单信息请求字段“orderinforequest”时，获取对应的响应报文模板。示例性的，响应报文模板包括多个参数字段，其中模板类型字段为订单信息响应字段。示例性的，订单信息响应字段被命名为“orderinforesponse”。示例性的，响应报文模板中的其他参数字段，详见下文对订单接口的详细说明中，对响应的参数字段的介绍。步骤2063，后台系统获取订单请求报文所需要的至少一个订单信息。示例性的，后台系统获取订单请求报文中的参数内容，参数内容包括商家标识id、订单渠道、每页数量、页数、开始日期、结束日期中的至少一种；并根据参数内容获取至少一个订单信息，订单信息包括订单基本信息、订单消费者人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息中的至少一种。例如，订单获取请求中的参数内容是商家标识id“001”、订单渠道“第一渠道”、每页数量“10”、页数“5”、开始日期“2019-10-01”、结束日期“2019-11-01”。则后台系统获取001商家通过第一渠道从2019年10月1日到2019年11月1日的50个订单，并获取该50个订单的订单基本信息、订单消费者人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息中的至少一种订单信息。步骤2064，后台系统根据响应报文模板和订单信息生成订单响应报文。步骤2091，统一预订设备识别订单响应报文的模板类型字段。步骤2092，统一预订设备响应于模板类型字段是订单信息响应字段时，将订单响应报文中的订单信息存储至数据库中。示例性的，当订单响应报文的模板类型字段是订单信息响应字段“orderinforesponse”时，统一预订设备确定该报文为订单响应报文，按照订单响应报文的处理方式，提取报文中的订单信息，并将订单信息存储至数据库中。综上所述，本实施例提供的方法，按照响应报文模板和请求报文模板生成订单响应报文和订单请求报文，使统一预订设备和后台系统间的信息交互符合订单接口的统一规则，进而将后台系统的订单信息保存至数据库中。实现了不论系统商有多少个，也不论系统商是否发生了更换，系统商的后台系统都可以通过订单接口将订单信息发送至统一预订设备中存储，进而将符合订单接口格式的订单信息沉淀在数据库中，供景区工作人员的分析和使用，提高了景区自身的数据中心的数据使用率和抗风险性。图4示出了本申请的一个示例性实施例提供的订单信息的存储方法的流程图。本实施例以该方法应用于图1所示的统一预订设备140和后台系统160中来举例说明。该方法包括：步骤1，统一预订设备获取一个商家，构造请求参数。示例性的，统一预订设备分批获取各个商家在不同后台系统上存储的订单数据。示例性的，统一预订设备获取一个商家的标识，构建该商家的订单请求报文，向该商家对应的后台系统发送该订单请求报文。步骤2，统一预订设备按照单商家分批拉取订单数据。示例性的，统一预订设备选定一个商家后，分批获取该商家存储在后台系统的订单数据。例如，统一预订设备按照年份分批获取订单数据。例如，统一预订设备向后台系统发送三个订单请求报文，分别用于请求该商家今年、去年、前年的订单数据。或，统一预订设备向后台系统发送一个订单请求报文，请求后台系统分批返回该商家今年、去年、前年的订单数据。步骤3，后台系统处理请求构造返回数据。后台系统接收到订单请求报文后，处理订单请求报文，构建订单响应报文。向统一预订设备返回该商家的订单信息。步骤4，后台系统分批返回该商家的订单数据。步骤5，数据库获取每一批数据，直至该商家数据获取完成，再获取下一个商家的数据，分批拉取数据。统一预订设备接收到订单响应报文后，获取订单响应报文中的订单信息，将订单信息存储到数据库中。当一个商家的订单信息拉取结束后，继续拉取下一个商家的订单信息。综上所述，本实施例提供的方法，统一预订设备分批向后台系统拉取一个商家的订单信息，将商家的订单数据存储到数据库中，一个商家的订单信息拉取成功后，继续拉取下一个商家的订单信息。使各个商家的订单信息都存储到统一的数据库，当商家需要更换后台系统时，订单数据人存储在数据库中。实现了不论系统商有多少个，也不论系统商是否发生了更换，系统商的后台系统都可以通过订单接口将订单信息发送至统一预订设备中存储，进而将符合订单接口格式的订单信息沉淀在数据库中，供景区工作人员的分析和使用，提高了景区自身的数据中心的数据使用率和抗风险性。下面对订单接口(全量同步订单数据接口)进行示例性说明：1.接口说明：1.1使用场景：统一预订设备主动调用系统商的订单接口获取指定景区、指定时间段内的全量订单的信息，包含：订单基本信息、订单游玩人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息。1.2请求方法：post1.3请求地址(url)：系统商提供2.请求参数(请求报文模板中的参数内容)见表一：表一3.响应参数(响应报文模板中的参数内容/订单信息)见表二：表二4.code(错误码)说明见表三：表三错误码错误描述解决方案200返回成功101参数错误检查参数的合法性102系统异常调用方重试199其他根据describe中信息处理，或者联系运营人员5.代码示例：5.1订单请求报文示例：5.2订单响应报文示例：图5示出了本申请一个示例性实施例提供的订单信息的存储系统。该系统包括：统一预订设备601和数据库602，统一预订设601备是位于售检票系统和后台系统之间的设备。统一预订设备601，用于执行上述任一实施例提供的订单信息的存储方法，以将全量订单的订单信息存储在数据库中；数据库602，用于存储全量订单的订单信息。图6示出了本申请一个示例性实施例提供的订单信息的存储装置的框图。该装置是位于售检票系统和后台系统之间的装置，该装置包括：第一发送模块701，用于通过订单接口向后台系统发送订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口；第一接收模块703，用于接收所述后台系统发送的订单响应报文，所述订单响应报文包括所述订单信息；存储模块705，用于将所述订单响应报文中的所述订单信息存储至数据库中。在一个示例性的例子中，所述装置还包括：第一获取模块704，用于获取所述订单请求报文的请求报文模板，所述请求报文模板的模板类型字段为订单信息请求字段；所述第一获取模块704，还用于获取所述请求报文模板所需要的至少一个参数内容；第一生成模块702，用于根据所述请求报文模板和所述至少一个参数内容生成所述订单请求报文。在一个示例性的例子中，所述第一获取模块704，还用于获取所述请求报文模板所需要的商家标识id、订单渠道、每页数量、页数、开始日期、结束日期中的至少一个参数内容。在一个示例性的例子中，所述订单信息包括：订单基本信息、订单消费者人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息中的至少一种。在一个示例性的例子中，所述第一发送模块701，还用于通过订单接口采用post方式向后台系统发送订单请求报文。在一个示例性的例子中，所述后台系统包括第一后台系统和第二后台系统，所述第一后台系统对应第一统一资源定位符url，所述第二后台系统对应第二url；所述第一发送模块701，还响应于向第一后台系统发送所述订单请求报文，调用所述订单接口向第一url所指示的所述第一后台系统发送post类型的所述订单请求报文；所述第一发送模块701，还响应于向第二后台系统发送所述订单请求报文，调用所述订单接口向第二url所指示的所述第二后台系统发送post类型的所述订单请求报文。在一个示例性的例子中，所述装置还包括：第一识别模块706，用于识别所述订单响应报文的模板类型字段；所述存储模块705，还响应于所述模板类型字段是订单信息响应字段时，将所述订单响应报文中的所述订单信息存储至数据库中。图7示出了本申请一个示例性实施例提供的订单信息的存储装置的框图。该装置包括：第二接收模块708，用于通过订单接口接收统一预订设备发送的订单请求报文，所述订单请求报文用于获取指定商家在指定时间段内全量订单的订单信息，所述订单接口适用于所述统一预订设备与至少两个不同的后台系统之间的信息交互，所述订单接口是所述后台系统提供的接口，所述统一预订设备是位于售检票系统和后台系统之间的设备；第二生成模块709，用于根据所述订单请求报文生成订单响应报文，所述订单响应报文包括所述订单信息；第二发送模块707，用于向所述统一预订设备发送所述订单响应报文。在一个示例性的例子中，所述装置还包括：第二识别模块710，用于识别所述订单请求报文的模板类型字段；第二获取模块711，响应于所述模板类型字段为订单信息请求字段，获取所述订单请求报文对应的订单响应报文的响应报文模板，所述响应报文模板的模板类型字段为订单信息响应字段；所述第二获取模块711，还用于获取所述订单请求报文所需要的至少一个订单信息；第二生成模块709，用于根据所述响应报文模板和所述订单信息生成所述订单响应报文。在一个示例性的例子中，所述第二获取模块711，还用于获取所述订单请求报文中的参数内容，所述参数内容包括商家标识id、订单渠道、每页数量、页数、开始日期、结束日期中的至少一种；所述第二获取模块711，还用于根据所述参数内容获取至少一个订单信息，所述订单信息包括订单基本信息、订单消费者人信息、订单券码信息、核销流水信息、退款流水信息、改签流水信息中的至少一种。在一个示例性的例子中，所述订单请求报文是所述统一预订设备采用post方式调用所述订单接口向统一资源定位符url所指示的所述后台系统发送的。图8示出了本申请一个示例性实施例提供的计算机设备的结构示意图。该计算机设备可以是上述系统中的统一预订设备或统一路由设备。具体来讲：计算机设备800包括中央处理单元(cpu，centralprocessingunit)801、包括随机存取存储器(ram，randomaccessmemory)802和只读存储器(rom，readonlymemory)803的系统存储器804，以及连接系统存储器804和中央处理单元801的系统总线805。计算机设备800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(i/o系统，inputoutputsystem)806，和用于存储操作系统813、应用程序814和其他程序模块815的大容量存储设备807。基本输入/输出系统806包括有用于显示信息的显示器807和用于用户输入信息的诸如鼠标、键盘之类的输入设备809。其中显示器807和输入设备809都通过连接到系统总线805的输入输出控制器810连接到中央处理单元801。基本输入/输出系统806还可以包括输入输出控制器810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器810还提供输出到显示屏、打印机或其他类型的输出设备。大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。大容量存储设备807及其相关联的计算机可读介质为计算机设备800提供非易失性存储。也就是说，大容量存储设备807可以包括诸如硬盘或者紧凑型光盘只读存储器(cd-rom，compactdiscreadonlymemory)驱动器之类的计算机可读介质(未示出)。计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括ram、rom、可擦除可编程只读存储器(eprom，erasableprogrammablereadonlymemory)、带电可擦可编程只读存储器(eeprom,electricallyerasableprogrammablereadonlymemory)、闪存或其他固态存储其技术，cd-rom、数字通用光盘(dvd，digitalversatiledisc)或固态硬盘(ssd，solidstatedrives)、其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。其中，随机存取记忆体可以包括电阻式随机存取记忆体(reram，resistancerandomaccessmemory)和动态随机存取存储器(dram，dynamicrandomaccessmemory)。当然，本领域技术人员可知计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。根据本申请的各种实施例，计算机设备800还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即计算机设备800可以通过连接在系统总线805上的网络接口单元811连接到网络812，或者说，也可以使用网络接口单元811来连接到其他类型的网络或远程计算机系统(未示出)。上述存储器还包括一个或者一个以上的程序，一个或者一个以上程序存储于存储器中，被配置由cpu执行。在一个可选的实施例中，提供了一种计算机设备，该计算机设备包括处理器和存储器，存储器中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上所述的虚拟对象的控制方法。在一个可选的实施例中，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如上所述的虚拟对象的控制方法。可选地，该计算机可读存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取记忆体(ram，randomaccessmemory)、固态硬盘(ssd，solidstatedrives)或光盘等。其中，随机存取记忆体可以包括电阻式随机存取记忆体(reram，resistancerandomaccessmemory)和动态随机存取存储器(dram，dynamicrandomaccessmemory)。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。本申请还提供一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述各方法实施例提供的订单信息的存储方法。应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。当前第1页12