CN105631630A - 旅客订单数据处理方法及装置 - Google Patents

Abstract

本发明实施例公开了一种旅客订单数据处理方法及装置，所述方法包括：配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；配置统一查询接口；基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。本发明实施例能够为各个不同系统提供最新、最全、最准确的旅客订单数据，不仅解决了当前三大系统间PNR数据缺失、不一致的问题，而且能够为用户查询不同渠道的航班数据，同时方便用户查询到旅行相关的其他信息。

Description

旅客订单数据处理方法及装置

技术领域

本发明涉及数据处理技术，尤其涉及一种旅客订单数据处理方法及装置。

背景技术

民航旅客订单数据(PNR，PassengerNameRecord)是民航信息系统最核心的数据，是民航业务操作的基础。随着上世纪90年代分销渠道的发展，民航信息系统被划分为三大系统，分别是航空公司航班控制系统(ICS，InventoryControlSystem)、机票分销商分销系统(CRS，ComputerReservationSystem)以及离港控制系统(DCS，DepartureControlSystem)。作为核心数据的PNR，为了满足民航领域不同业务主体的需要，分别存储在ICS、CRS以及DCS系统中。这种存储方式一直沿用至今。针对旅客订单的查询请求，三大系统通过访问各自系统的旅客订单进行处理，一方面，三大系统之间需要依靠数据同步更新旅客订单数据，但是数据同步并不能从根本上保证旅客订单的实时性和完备性，另一方面，不同系统的旅客订单数据可能存在差异，因而对旅客订单查询，各系统的订单数据可能会存在不一致、数据缺失等问题，例如在订票阶段，通过CRS系统预订的PNR，需要ICS系统进行航班确认，此时在CRS系统查询会出现航段状态不确定的情况；而在CRS系统订的PNR，ICS系统无法获得旅客联系方式等信息；并且在航班起飞48小时之前，离港DCS系统无法看到PNR的信息。这种数据缺失问题在订单确认、订单支付、值机、结算等阶段同样存在。为了保证不同系统所访问订单数据的一致性和完整性，国际上通行的做法是利用系统间高速的连接网络以及标准化的接口，采用CO-HOST方式实现系统间数据的实时访问。虽然这在一定程度上可以提升系统间PNR的一致性，但对网络的依赖程度高，并且研发和环境成本也很高。因此，迫切需要统一查询接口规范满足不同业务主体对订单数据的访问需求。

随着民航旅客量的迅速增长，旅客出行的模式近几年也发生了很大变化，已经不仅仅是购买机票那么简单，旅客希望在买到机票的同时，也能够将酒店、租车或景点门票等旅行过程涉及到的内容一并购买。因此，需要为旅客提供一个全景视图，通过该全景视图不仅可以查询不同渠道的航班数据，也可以了解到与旅行相关的非航和附加服务的相关信息。

因此，需要提出一种新方案，解决当前三大系统间PNR数据缺失、不一致的问题，并且不仅能够为用户查询不同渠道的航班数据，也能够方便用户查询到旅行相关的其他信息。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种旅客订单数据处理方法及装置。

为达到上述目的，本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种旅客订单数据处理方法，所述方法包括：

配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；

配置统一查询接口；

基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

其中，所述配置统一查询接口时配置的内容包括：

旅客姓名、类型，证件号码，常旅客、信用卡信息，客票状态，退改签信息，航程信息、座位信息，特殊服务、附件服务，客票状态、非航信息，以及值机状态和行李信息。

其中，采用可扩展标记语言XML完成所述统一查询接口的配置。

其中，所述统一查询接口包括一个根节点，所述根节点下有一个属性和至少6个子元素；其中，

所述根节点为表示旅客预订记录创建、更新、删除等响应接口的根元素；

所述一个属性表示版本号；

所述6个子元素为复合元素，分别表示：PNR信息组、运价信息组、航段保险单信息组、常旅客组、一个或多个座位请求、行程注释组。

其中，所述根节点下有42个按顺序出现的子元素；其中，

所述42个子元素分别表示：错误和提示信息组、PNR信息组、运价信息组、手动运价项、旅行者具体信息组、航段信息组、服务信息组、地面信息组、航段杂项信息组、航段保险单信息组、联系电话组、出票组、手工票证组、电子邮箱组、常旅客组、包含具备资质者的信息、开账并发送数据组、客户身份信息确认组、客户基本信息描述组、发票凭证注释组、到期支付的文本信息组、一般注释组、隐藏注释组、其他注释组、行程注释组、其他服务信息组、检查预订队列组、表示一个或多个座位请求、最佳座位请求组、特殊服务请求组、高级旅客信息系统数据组、客票注释组、用户定义注释组、历史注释组、旅游代码元素组、结算行信息、结算信息、即将售票和票价计算处理的售票指令、PNR的历史部分、签注信息、出票承运人、通知组。

本发明实施例还提供了一种旅客订单数据处理装置，所述装置包括：

数据源配置模块，用于配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；

接口配置模块，用于配置统一查询接口；

处理模块，用于基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

其中，所述接口配置模块配置的内容包括：

旅客姓名、类型，证件号码，常旅客、信用卡信息，客票状态，退改签信息，航程信息、座位信息，特殊服务、附件服务，客票状态、非航信息，以及值机状态和行李信息。

其中，所述接口配置模块用于采用可扩展标记语言XML完成所述统一查询接口的配置。

其中，所述接口配置模块配置后的统一查询接口包括一个根节点，所述根节点下有一个属性和至少6个子元素；其中，

所述根节点为表示旅客预订记录创建、更新、删除等响应接口的根元素；

所述一个属性表示版本号；

所述6个子元素为复合元素，分别表示：PNR信息组、运价信息组、航段保险单信息组、常旅客组、一个或多个座位请求、行程注释组。

其中，所述根节点下有42个按顺序出现的子元素；其中，所述42个子元素分别表示：错误和提示信息组、PNR信息组、运价信息组、手动运价项、旅行者具体信息组、航段信息组、服务信息组、地面信息组、航段杂项信息组、航段保险单信息组、联系电话组、出票组、手工票证组、电子邮箱组、常旅客组、包含具备资质者的信息、开账并发送数据组、客户身份信息确认组、客户基本信息描述组、发票凭证注释组、到期支付的文本信息组、一般注释组、隐藏注释组、其他注释组、行程注释组、其他服务信息组、检查预订队列组、表示一个或多个座位请求、最佳座位请求组、特殊服务请求组、高级旅客信息系统数据组、客票注释组、用户定义注释组、历史注释组、旅游代码元素组、结算行信息、结算信息、即将售票和票价计算处理的售票指令、PNR的历史部分、签注信息、出票承运人、通知组。

本发明实施例的旅客订单数据处理方法及装置，将分散在航空公司、机票分销商以及机场系统对旅客订单的访问需求整理为统一查询接口规范，并且增加旅客旅行过程中涉及到的其他相关信息，为各个不同系统提供最新、最全、最准确的旅客订单数据，不仅解决了当前三大系统间PNR数据缺失、不一致的问题，而且能够为用户查询不同渠道的航班数据，同时方便用户查询到旅行相关的其他信息。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。具有不同字母后缀的相似附图标记可表示相似部件的不同示例。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为三大业务主体在旅客订单的生命周期内对旅客订单数据的访问需求示意图；

图2为三大业务主体在旅客订单的生命周期对旅客订单数据的访问需求列表；

图3为本发明实施例的旅客订单数据处理装置提供的全景视图界面示意图；

图4a-4d为本发明实施例统一查询接口的规范示意图；

图5为图4中PNRIdentification的组织结构示意图；

图6为图4中FareGroup的组织结构示意图；

图7为图4中Insurance的组织结构示意图；

图8为图4中FrequentTravelerGroup的组织结构示意图；

图9为图4中Seat的组织结构示意图；

图10为图4中ItineraryRemark的组织结构示意图。

具体实施方式

本发明实施例提供的旅客订单数据处理方法及装置、系统，是将分散在航空公司、机票分销商以及机场系统对旅客订单的访问需求，通过其各自访问逻辑整理为一套统一查询接口规范，并且增加旅客旅行过程中涉及到的其他相关信息(例如酒店、租车、附加服务等)，为用户提供最新、最全、最准确的旅客订单记录数据。

本发明实施例是以统一订单用户旅行数据(CTR，CustomerTravelRecord)为数据基础，将现有航空公司、机票分销商以及机场系统对订单在其生命周期内的访问需求整理合并为一个统一接口，使之成为统一的查询入口，供不同的业务应用和渠道所使用。

本发明实施例提供了一种旅客订单数据处理方法，该方法可以包括：

首先，配置数据源：针对不同系统的PNR，形成相同格式的统一订单CTR，作为查询接口的数据源；

其次，配置统一查询接口；

最后，基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

相应的，本发明实施例还提供了一种旅客订单数据处理装置，所述装置包括：数据源配置模块，用于配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；接口配置模块，用于配置统一查询接口；处理模块，用于基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

下面对本发明实施例提供的旅客订单数据处理方法及装置做详细说明。

首先，对于在统一接口之前，先详细说明一下在一个旅客订单的生命周期(即订单预订、确认、支付、出票、退改签、值机以及结算阶段的过程)中不同业务主体的查询需求，参考图1和图2，纵向来看：在预定阶段，如果由航空公司生成订单，则ICS系统的PNR数据是完整的，此时CRS系统的查询存在航段状态不准问题；如果由机票分销商生成订单，则CRS系统的PNR数据是完整的，ICS系统的查询存在联系信息缺失问题；而DCS系统此时未初始化数据，故查询不到订单信息。横向来看：如果订单是由航空公司生成的，那么在预订、确认、支付、出票、退改签、值机和结算阶段，在ICS的PNR数据是完整的，而基于CRS、DCS的查询就会出现订单信息缺失和不完整问题。

本发明实施例中，首先将ICS、CRS、DCS的PNR通过整合逻辑形成统一订单CTR，作为查询接口的基本数据源，然后依据国际标准(OpenAxis)对航空领域的接口定义，结合航空公司、机票分销商以及机场的个性化查询需求，整理形成航空领域的统一查询接口规范，完成统一查询接口的配置，该规范包括但不限于9类查询：旅客姓名、类型，证件号码，常旅客、信用卡信息，客票状态，退改签信息，航程信息、座位信息，特殊服务、附件服务，客票状态、非航信息，以及值机状态和行李信息。最后基于规则引擎(RuleEngine)，接收并处理旅客订单生命周期内(预订、确认、支付、成交、改期、值机、结算)的查询请求。

如图3所示，为本发明实施例的旅客订单数据处理装置提供的全景视图界面示意图。这里需要说明的是，统一订单CTR的整合逻辑和RuleEngine的预先配置方式可以通过相关技术实现，不在此赘述。

本发明实施例中，所述统一查询接口的规范如图4所示，由结构化语言(如，可扩展标记语言(XML，ExtensibleMarkupLanguage)完成数据组织和数据交换。其中，虚线矩形框表示该元素或属性不是必选元素或者必选属性，实线矩形框表示该元素的最小出现次数是1次，矩形框左下角的箭头表示这个元素引用另一个元素定义，矩形框右边的加号表示框内的元素是一个复合元素，矩形框下面的“1..∞”表示最小出现次数是1次，最大出现次数不限，矩形框下面的“0..∞”表示最小出现次数是0次，最大出现次数不限，矩形框下面只出现1个具体数字表示这个元素最大出现次数和最小出现次数都是这个具体数字，矩形框中出现##any表示来自任意命名空间的元素都可以出现。这里，复合元素指包含其它元素或者属性的XML元素，简易元素指仅包含文本的XML元素，简易元素不能包含属性和任何其它元素。

根节点PNRViewRS(复合元素)是表示旅客预订记录创建、更新、删除等响应接口的根元素，它包含一个属性和42个按顺序出现的子元素。具体元素如图4所示，各元素名称及其具体含义如下：

--version属性：版本号，例如：1.0

--InfoGroup元素(复合元素)：错误和提示信息组

--PNRIdentification元素(复合元素):PNR信息组

--FareGroup元素(复合元素)：运价信息组

--ManualFareEntry元素(复合元素)：手动运价项

--Traveler元素(复合元素)：旅行者具体信息组

--AirGroup元素(复合元素)：航段信息组

--ServiceGroup元素(复合元素)：服务信息组

--LandGroup(复合元素)：地面信息组

--MiscellaneousGroup(复合元素)：航段杂项信息组

--Insurance(复合元素)：航段保险单信息组

--Telephone(复合元素)：联系电话组

--Ticketing(复合元素)：出票组

--ManualTicket(复合元素)：手工票证组

--EmailAddress(复合元素)：电子邮箱组

--FrequentTravelerGroup(复合元素)：常旅客组

--QualifierGroup(复合元素)：包含具备资质者的信息(例如企业身份标识、合同标识、常客计划标识、票务机构标识、商品推广标识等)

--BillingAndDeliveryData(复合元素)：开账并发送数据组

--CustomerIdentification(复合元素)：客户身份信息确认组

--CustomerProfile(复合元素)：客户基本信息描述组

--DocumentInvoiceRemark(复合元素)：发票凭证注释组

--DuePaidText元素(复合元素)：到期支付的文本信息组

--GeneralRemark(复合元素)：一般注释组

--HiddenRemark(复合元素)：隐藏注释组

--OtherRemark(复合元素)：其他注释组

--ItineraryRemarks(复合元素)：行程注释组

--OtherServiceInformation(复合元素)：其他服务信息组

--ReviewBookingQueue(复合元素)：检查预订队列组

--Seat(复合元素)：表示一个或多个座位请求(取决于分配儿童元素的数量)

--SeatOptimizerGroup(复合元素)：最佳座位请求组

--SpecialServiceRequest(复合元素)：特殊服务请求组

--APIS(复合元素)：高级旅客信息系统数据组

--TicketRemark(复合元素)：客票注释组

--UserRemark(复合元素)：用户定义注释组

--HistoricalRemark(复合元素)：历史注释组

--TourCode(复合元素)：旅游代码元素组

--AccountingLine(复合元素)：结算行信息

--AccountingInfo(复合元素)：结算信息

--TicketingInstructions(复合元素)：即将售票和票价计算处理的售票指令

--History(复合元素)：PNR的历史部分

--Endorsement(复合元素)：签注信息

--ValidatingCarrier(复合元素)：出票承运人

--PendingNotifications(复合元素)：通知组

以下对本发明实施例中六个重要的PNRViewRS子元素进行详尽阐述：

1)PNRIdentification

PNRIdentification(复合元素)是PNRViewRS的子元素，包含6个属性，17个子元素。具体属性和元素如图5所示，其中各元素及其含义如下：

--TicketIssued属性：标识已经出票，内容是：Y＝是，N＝否。

--QueueRetrieved属性：标识PNR是否已经从队列中检索出来。内容是：Y＝是，N＝否。

--FareDataExists属性：标识PNR是否包含运价数据。内容是：Y＝是，N＝否。

--GroupPNR属性：标识PNR是否为一个团队PNR(目前只有Amadeus支持)，内容是Y＝是，N＝否。

--PNRStatus属性：当前PNR的状态。A＝有效的，C＝取消的，P＝过期的，N＝新创建PNR(包括正在创建的和已经完成过封口的)

--PendingTicket属性：“Y”值显示有一个挂起的客票或电子杂费票证还没有完成和PNR(各自创建的参考节点，例如客票信息等元素)同步的交易。内容是Y＝客票/电子杂费凭证交易挂起，N＝没有挂起(缺省)

--RecordLocator元素(简易元素)：超级PNR的记录编号。例如：F1A3SK

--Sources元素(复合元素)：包含Source子元素。Source子元素由2个属性，1个子元素组成：Name属性表示分配给source元素的代码，例如EK；Title属性表示source子元素的拼写标题，例如Emirat；es

PNRIdentification元素(复合元素)：参考“3.1.2.3.1PNRIdentification结构”和其中的Source属性、SourceRef属性、RecordLocator元素、Sources元素、CreationDate元素、CreationTime元素、CreationAgent元素和Ownership元素

--CreationDate元素(简易元素)：PNR创建时确定的日期，符合ISO8601格式标准(年年年年-月月-日日)。例如2001-12-25

--CreationTime元素(简易元素)：PNR创建时确定的时间，符合ISO8601格式标准。例如；12:35

--CreationAgent元素(简易元素):机票分销商身份标识。例如：RI17

--ReceivedFrom元素(简易元素)：信息来源。例如：John

--Ownership元素(复合元素)：所有权。

--CurrentPseudoCityCode元素(简易元素)：当前虚拟城市代码。例如：LM21

--AgencyData元素(复合元素)：机票分销商数据组

--BookingOfficeID元素(简易元素)：预订营业处信息组。例如：KLTLOB

--AssociatedPNRGroup元素(复合元素)：分离或聚合PNR

--OtherVendorInformation元素(复合元素)：其他供应商信息组

--TicketNumber元素(复合元素)：弃用的客票票号。具体内容参考3.1.10.2

--TicketInfo元素(复合元素)：允许客票票号与航段和旅客在PNR中的关联，连同佣金一起。

--PaymentInfo元素(复合元素)：用于无票或固定航班且或服务中，每个资源使用一个元素节点，所有支付交易将被追溯在一个节点上

--EMDInfo元素(复合元素)：EMD出票信息，允许将EMD票号或航段关联到客票票号或航段

--GroupInfo元素(复合元素)：团队PNR的细节信息。这个信息被用于创建团队PNR和关联团队特殊服务组(SSRGRPS)元素，被存储的数据可以通过预订工具向用户提供团队的所有细节信息

2)FareGroup

FareGroup(复合元素)是PNRViewRS的子元素，包含14个属性，9个子元素。具体属性和元素如图6所示：

--Source属性：定义元素数据的来源，如1A、1V等

--SourceRef属性：与数据源关联的PNR记录编号

--FareNumber属性：PNR中票价的绝对数，如需要可作为参考。例如：删除特定的票价。

--FarePriced属性：显示票价是如何定价的，即自动(使用GDS自动定价)或人工。数值有：MANU＝人工定价，AUTO＝自动定价

--FareType属性：票价的类型。例如：PUBL。类型有：PUBL＝公布运价；NEGO＝协商/私有运价；PRIV＝私有统一运价；HIST＝历史运价信息；UNDF＝未定义，该运价类型未知

--NetFare属性：允许值＝“Y”，用于标识Cat35C型净价

--FareFormat属性：票价返回的类别。类型有：LCCB＝单向票价，LCCI＝旅程票价。例如：LCCB

--TravelerCount属性：整个行程的所有类型的乘客总数。例如：4

--TotalPrice属性：整个行程所有类型的所有乘客的总价格。是所有类型总价格之和。例如：320000

--TotalJourneyPrice属性：整个行程所有类型的所有乘客的总价格。是所有类型的总价格加上所选服务的总和。例如：320000

--HistoricPricingDate属性：指定用于给该票价组定价的的历史日期。ISO8601格式(YYYY-MM-DD)日期。例：2001-12-25

--ReissueOnly属性：表示制订票价来重新出部分机票，例如该价格不包括已飞行段，但只与未飞的飞行段有关，使其在重新出票过程中购票。数值有：Y/N

--AutoExchange元素：允许值＝“Y”，标识此票价作为从自动换开应用程序返回的解决方案。

--AvailabilityCheck属性：允许值＝“Y”，表示在购票时重新定价需要进行可用性检查，默认情况下不做可用性检查。

--SegmentElementNumber元素(复合元素)：与本条目关联的段号。例如：1。包含Source属性，Onpoint属性和OffPoint属性。

--CurrencyCode元素(复合元素)：货币代码。包括NumberOfDecimals属性，标识小数点的位置

--TravelerGroup元素(复合元素)：旅客组

--OptionalServices元素(复合元素)：单独购买的或由排位规则提供的免费服务，如顶级忠诚度的会员

--IncludedServices元素(复合元素)：包含在票价中的服务

--BaggageData元素(复合元素)：行李数据

--ValidatingCarrier元素(简易元素)：承运航空公司运营商代码。国际航空运输协会标准2字符的字母数字代码。例如：AF

--TaxExemptInfo元素(复合元素)：包含用于这种定价的免税参数，如PNRCreateRQ和FlightPriceRQ中提供的PricingInfo节点。这些参数被应用于后续的重新定价，附加服务定价以及高级座位定价等

--TravelStats元素(复合元素)：根据需要为BSP和ARC报告统计数据

3)Insurance

Insurance(复合元素)是PNRViewRS的子元素，包含2个属性，18个子元素。具体属性和元素如图7所示，其中：

--Source属性：定义元素数据的来源，如1A、1V等

--SourceRef属性：与数据源关联的PNR记录编号

--VendorCode元素：供应商代码。例如：AA

--VendorName元素：供应商名称。例如：AirMiles

--PurchaseDate元素：购买日期。ISO8601格式日期(yyyy-mm-dd)。例如：2001-12-25

--ActionCode元素：行动代码。例如：HK

--NumberInParty元素：旅客的人数。例如：1

--DepartureCity元素：出发城市代码或名称

--DepartureDate元素：出发日期。ISO8601格式日期(yyyy-mm-dd)。例如：2001-12-25

--DestinationCity元素：目的城市代码或城市名称

--ReturnDate元素：返回的日期。ISO8601格式日期(yyyy-mm-dd)。例如：2001-12-25

--PlanType元素：保险费计划类型。例如：TPKG

--TravelerName元素：旅客姓名

--Coverage元素：保险覆盖范围类型。例如：TCI950

--PaymentType元素：保险支付类型

--BookingSource元素：机票分销商预订源编号。例如：99199

--CurrencyCode元素：货币代码

--Segment元素：行程段编号。例如：00001

--Premium元素：保险费信息

--ConfirmationNumber元素：确认号。例如：1234567890

4)FrequentTravelerGroup

FrequentTravelerGroup(复合元素)是PNRViewRS的子元素，包含2个属性，10个子元素。具体属性和元素如图8所示，其中：

--Source属性：定义元素数据的来源，如1A、1V等

--SourceRef属性：与数据源关联的PNR记录编号

--ElementNumber元素：PNR元素号。例如：1

--TravelerElementNumber元素：与本条目关联的旅客元素编号。例如：1

--FFCompanyCode元素：经常乘坐的航空公司代码。例如：AF

--FFCompanyName元素：经常乘坐的航空公司的名称。例如：AirFrance(法航)

--FFNumber元素：常旅客号。例如：0956301007

--FFFlyingCompany元素：经常乘坐的航空公司。例如：DL

--FFLoyaltyLever元素：常旅客的忠诚级别。例如：Blue

--SubscriberName元素：姓名信息

--FreqGuestNumber元素：常旅客信用卡和状态信息

--OtherMemberships元素：优惠卡。例如：AAA,AARP

5)seat

Seat(复合元素)是PNRViewRS的子元素，包含2个属性和8个子元素。具体元素如图9所示，其含义如下：

--Source属性：定义元素数据的来源，如1A、1V等

--SourceRef属性：与数据源关联的PNR记录编号

--ElementNumber元素：PNR元素编号

--SegmentElementNumber元素(复合元素)：与本条目关联的航段元素编号，例如，F1。有三个属性：Source，ONPoint，OFFPoint

--ServiceElementNumber元素：与本条目关联的服务Element编号

--DepartureCode元素(可选)：出发机场或城市代码，如PEK

--ArrivalCode元素(可选)：到达机场或城市代码，如CAN

--SSRCode元素：IATA标准特殊服务代码，如VGML

--SeatStatus元素：座位状态，可能出现的值包括：

R或NN-座位请求

C或HK-座位确认

D或NO-座位拒绝

P或PN-座位挂起

--Assignment元素(复合元素)：座位分配组

6)ItineraryRemark

ItineraryRemark(复合元素)是PNRViewRS的子元素，包含2个属性和4个子元素。具体元素如图10所示，其含义如下：

--Source属性：定义元素数据的来源，如1A、1V等

--SourceRef属性：与数据源关联的PNR记录编号

--AirRemark元素(复合元素)：航空类备注组

--CarRemark元素(复合元素)：租车类备注组

--HotelRemark元素(复合元素)：酒店类备注组

--FreeFlowRemark元素(复合元素)：自由备注组

本发明实施例的旅客订单数据处理方法及装置，提供了旅客统一订单全景视图，能够为民航业务领域提供了一套统一查询接口规范。首先，通过整合统一接口，实现了各大航空信息系统间对于订单数据查询、更新一体化的要求，彻底消除了各大系统间订单数据不一致的情况；其次，该查询接口的创建是基于旅客订单生命周期各阶段的查询需求，因此能够兼容民航行业现有的所有查询业务，航空公司、机票分销商以及机场不会因为该查询接口规范的出现而改变原有业务流程；第三，该查询接口规范支持酒店、租车、附加服务等非航内容。可以根据旅客行程的不同，选择旅客需要的产品进行预订和存储。最后，该接口规范是符合通用的逻辑设计，不依赖于任何应用环境和数据库产品。

此外，对于查询接口规范，还可以将查询要素组织成为json格式，这样做的优点是json数据格式简单、易于解析，缺点是通用性差，而且json目前在WebService阶段还处于初级阶段，不能充分为基于Web的查询提供支持。而XML在可扩展性、Web传输以及通用性方面更胜一筹，因此，优选XML格式。

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

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

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

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

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种旅客订单数据处理方法，其特征在于，所述方法包括：

配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；

配置统一查询接口；

基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

2.根据权利要求1所述的方法，其特征在于，所述配置统一查询接口时配置的内容包括：

旅客姓名、类型，证件号码，常旅客、信用卡信息，客票状态，退改签信息，航程信息、座位信息，特殊服务、附件服务，客票状态、非航信息，以及值机状态和行李信息。

3.根据权利要求1或2所述的方法，其特征在于：采用可扩展标记语言XML完成所述统一查询接口的配置。

4.根据权利要求3所述的方法，其特征在于，所述统一查询接口包括一个根节点，所述根节点下有一个属性和至少6个子元素；其中，

所述根节点为表示旅客预订记录创建、更新、删除等响应接口的根元素；

所述一个属性表示版本号；

所述6个子元素为复合元素，分别表示：PNR信息组、运价信息组、航段保险单信息组、常旅客组、一个或多个座位请求、行程注释组。

5.根据权利要求4所述的方法，其特征在于，所述根节点下有42个按顺序出现的子元素；其中，

所述42个子元素分别表示：错误和提示信息组、PNR信息组、运价信息组、手动运价项、旅行者具体信息组、航段信息组、服务信息组、地面信息组、航段杂项信息组、航段保险单信息组、联系电话组、出票组、手工票证组、电子邮箱组、常旅客组、包含具备资质者的信息、开账并发送数据组、客户身份信息确认组、客户基本信息描述组、发票凭证注释组、到期支付的文本信息组、一般注释组、隐藏注释组、其他注释组、行程注释组、其他服务信息组、检查预订队列组、表示一个或多个座位请求、最佳座位请求组、特殊服务请求组、高级旅客信息系统数据组、客票注释组、用户定义注释组、历史注释组、旅游代码元素组、结算行信息、结算信息、即将售票和票价计算处理的售票指令、PNR的历史部分、签注信息、出票承运人、通知组。

6.一种旅客订单数据处理装置，其特征在于，所述装置包括：

数据源配置模块，用于配置数据源：针对不同系统的旅客订单数据PNR，形成相同格式的统一订单用户旅行数据CTR，作为查询接口的数据源；

接口配置模块，用于配置统一查询接口；

处理模块，用于基于预先配置的规则引擎，接收并处理旅客订单生命周期内的查询请求。

7.根据权利要求6所述的装置，其特征在于，所述接口配置模块配置的内容包括：

旅客姓名、类型，证件号码，常旅客、信用卡信息，客票状态，退改签信息，航程信息、座位信息，特殊服务、附件服务，客票状态、非航信息，以及值机状态和行李信息。

8.根据权利要求6或7所述的装置，其特征在于：所述接口配置模块用于采用可扩展标记语言XML完成所述统一查询接口的配置。

9.根据权利要求8所述的装置，其特征在于，所述接口配置模块配置后的统一查询接口包括一个根节点，所述根节点下有一个属性和至少6个子元素；其中，

所述根节点为表示旅客预订记录创建、更新、删除等响应接口的根元素；

所述一个属性表示版本号；

所述6个子元素为复合元素，分别表示：PNR信息组、运价信息组、航段保险单信息组、常旅客组、一个或多个座位请求、行程注释组。

10.根据权利要求9所述的装置，其特征在于，所述根节点下有42个按顺序出现的子元素；其中，

所述42个子元素分别表示：错误和提示信息组、PNR信息组、运价信息组、手动运价项、旅行者具体信息组、航段信息组、服务信息组、地面信息组、航段杂项信息组、航段保险单信息组、联系电话组、出票组、手工票证组、电子邮箱组、常旅客组、包含具备资质者的信息、开账并发送数据组、客户身份信息确认组、客户基本信息描述组、发票凭证注释组、到期支付的文本信息组、一般注释组、隐藏注释组、其他注释组、行程注释组、其他服务信息组、检查预订队列组、表示一个或多个座位请求、最佳座位请求组、特殊服务请求组、高级旅客信息系统数据组、客票注释组、用户定义注释组、历史注释组、旅游代码元素组、结算行信息、结算信息、即将售票和票价计算处理的售票指令、PNR的历史部分、签注信息、出票承运人、通知组。