旅客訂單數(shù)據(jù)處理方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及數(shù)據(jù)處理技術(shù)，尤其涉及一種旅客訂單數(shù)據(jù)處理方法及裝置。
【背景技術(shù)】
[0002]民航旅客訂單數(shù)據(jù)(PNR，PassengerName Record)是民航信息系統(tǒng)最核心的數(shù)據(jù)，是民航業(yè)務(wù)操作的基礎(chǔ)。隨著上世紀(jì)90年代分銷渠道的發(fā)展，民航信息系統(tǒng)被劃分為三大系統(tǒng)，分別是航空公司航班控制系統(tǒng)(ICS，Inventory Control System)、機票分銷商分銷系統(tǒng)(CRS,Computer Reservat1n System)以及離港控制系統(tǒng)(DCS，Departure ControlSystem)。作為核心數(shù)據(jù)的PNR，為了滿足民航領(lǐng)域不同業(yè)務(wù)主體的需要，分別存儲在ICS、CRS以及DCS系統(tǒng)中。這種存儲方式一直沿用至今。針對旅客訂單的查詢請求，三大系統(tǒng)通過訪問各自系統(tǒng)的旅客訂單進行處理，一方面，三大系統(tǒng)之間需要依靠數(shù)據(jù)同步更新旅客訂單數(shù)據(jù)，但是數(shù)據(jù)同步并不能從根本上保證旅客訂單的實時性和完備性，另一方面，不同系統(tǒng)的旅客訂單數(shù)據(jù)可能存在差異，因而對旅客訂單查詢，各系統(tǒng)的訂單數(shù)據(jù)可能會存在不一致、數(shù)據(jù)缺失等問題，例如在訂票階段，通過CRS系統(tǒng)預(yù)訂的PNR，需要ICS系統(tǒng)進行航班確認(rèn)，此時在CRS系統(tǒng)查詢會出現(xiàn)航段狀態(tài)不確定的情況;而在CRS系統(tǒng)訂的PNR，ICS系統(tǒng)無法獲得旅客聯(lián)系方式等信息；并且在航班起飛48小時之前，離港DCS系統(tǒng)無法看到PNR的信息。這種數(shù)據(jù)缺失問題在訂單確認(rèn)、訂單支付、值機、結(jié)算等階段同樣存在。為了保證不同系統(tǒng)所訪問訂單數(shù)據(jù)的一致性和完整性，國際上通行的做法是利用系統(tǒng)間高速的連接網(wǎng)絡(luò)以及標(biāo)準(zhǔn)化的接口，采用CO-HOST方式實現(xiàn)系統(tǒng)間數(shù)據(jù)的實時訪問。雖然這在一定程度上可以提升系統(tǒng)間PNR的一致性，但對網(wǎng)絡(luò)的依賴程度高，并且研發(fā)和環(huán)境成本也很高。因此，迫切需要統(tǒng)一查詢接口規(guī)范滿足不同業(yè)務(wù)主體對訂單數(shù)據(jù)的訪問需求。
[0003]隨著民航旅客量的迅速增長，旅客出行的模式近幾年也發(fā)生了很大變化，已經(jīng)不僅僅是購買機票那么簡單，旅客希望在買到機票的同時，也能夠?qū)⒕频?、租車或景點門票等旅行過程涉及到的內(nèi)容一并購買。因此，需要為旅客提供一個全景視圖，通過該全景視圖不僅可以查詢不同渠道的航班數(shù)據(jù)，也可以了解到與旅行相關(guān)的非航和附加服務(wù)的相關(guān)信息。
[0004]因此，需要提出一種新方案，解決當(dāng)前三大系統(tǒng)間PNR數(shù)據(jù)缺失、不一致的問題，并且不僅能夠為用戶查詢不同渠道的航班數(shù)據(jù)，也能夠方便用戶查詢到旅行相關(guān)的其他信息。

【發(fā)明內(nèi)容】

[0005]為解決現(xiàn)有存在的技術(shù)問題，本發(fā)明實施例提供一種旅客訂單數(shù)據(jù)處理方法及裝置。
[0006]為達(dá)到上述目的，本發(fā)明實施例的技術(shù)方案是這樣實現(xiàn)的:
[0007]本發(fā)明實施例提供了一種旅客訂單數(shù)據(jù)處理方法，所述方法包括:
[0008]配置數(shù)據(jù)源:針對不同系統(tǒng)的旅客訂單數(shù)據(jù)PNR，形成相同格式的統(tǒng)一訂單用戶旅行數(shù)據(jù)CTR，作為查詢接口的數(shù)據(jù)源；
[0009]配置統(tǒng)一查詢接口；
[0010]基于預(yù)先配置的規(guī)則引擎，接收并處理旅客訂單生命周期內(nèi)的查詢請求。
[0011 ]其中，所述配置統(tǒng)一查詢接口時配置的內(nèi)容包括:
[0012]旅客姓名、類型，證件號碼，常旅客、信用卡信息，客票狀態(tài)，退改簽信息，航程信息、座位信息，特殊服務(wù)、附件服務(wù)，客票狀態(tài)、非航信息，以及值機狀態(tài)和行李信息。
[0013]其中，采用可擴展標(biāo)記語言XML完成所述統(tǒng)一查詢接口的配置。
[0014]其中，所述統(tǒng)一查詢接口包括一個根節(jié)點，所述根節(jié)點下有一個屬性和至少6個子元素;其中，
[0015]所述根節(jié)點為表示旅客預(yù)訂記錄創(chuàng)建、更新、刪除等響應(yīng)接口的根元素；
[0016]所述一個屬性表不版本號；
[0017]所述6個子元素為復(fù)合元素，分別表示:PNR信息組、運價信息組、航段保險單信息組、常旅客組、一個或多個座位請求、行程注釋組。
[0018]其中，所述根節(jié)點下有42個按順序出現(xiàn)的子元素;其中，
[0019]所述42個子元素分別表示:錯誤和提示信息組、PNR信息組、運價信息組、手動運價項、旅行者具體信息組、航段信息組、服務(wù)信息組、地面信息組、航段雜項信息組、航段保險單信息組、聯(lián)系電話組、出票組、手工票證組、電子郵箱組、常旅客組、包含具備資質(zhì)者的信息、開賬并發(fā)送數(shù)據(jù)組、客戶身份信息確認(rèn)組、客戶基本信息描述組、發(fā)票憑證注釋組、到期支付的文本信息組、一般注釋組、隱藏注釋組、其他注釋組、行程注釋組、其他服務(wù)信息組、檢查預(yù)訂隊列組、表示一個或多個座位請求、最佳座位請求組、特殊服務(wù)請求組、高級旅客信息系統(tǒng)數(shù)據(jù)組、客票注釋組、用戶定義注釋組、歷史注釋組、旅游代碼元素組、結(jié)算行信息、結(jié)算信息、即將售票和票價計算處理的售票指令、PNR的歷史部分、簽注信息、出票承運人、通知組。
[0020]本發(fā)明實施例還提供了一種旅客訂單數(shù)據(jù)處理裝置，所述裝置包括:
[0021]數(shù)據(jù)源配置模塊，用于配置數(shù)據(jù)源:針對不同系統(tǒng)的旅客訂單數(shù)據(jù)PNR，形成相同格式的統(tǒng)一訂單用戶旅行數(shù)據(jù)CTR，作為查詢接口的數(shù)據(jù)源；
[0022]接口配置模塊，用于配置統(tǒng)一查詢接口；
[0023]處理模塊，用于基于預(yù)先配置的規(guī)則引擎，接收并處理旅客訂單生命周期內(nèi)的查詢請求。
[0024]其中，所述接口配置模塊配置的內(nèi)容包括:
[0025]旅客姓名、類型，證件號碼，常旅客、信用卡信息，客票狀態(tài)，退改簽信息，航程信息、座位信息，特殊服務(wù)、附件服務(wù)，客票狀態(tài)、非航信息，以及值機狀態(tài)和行李信息。
[0026]其中，所述接口配置模塊用于采用可擴展標(biāo)記語言XML完成所述統(tǒng)一查詢接口的配置。
[0027]其中，所述接口配置模塊配置后的統(tǒng)一查詢接口包括一個根節(jié)點，所述根節(jié)點下有一個屬性和至少6個子元素;其中，
[0028]所述根節(jié)點為表示旅客預(yù)訂記錄創(chuàng)建、更新、刪除等響應(yīng)接口的根元素；
[0029]所述一個屬性表示版本號；
[0030]所述6個子元素為復(fù)合元素，分別表示:PNR信息組、運價信息組、航段保險單信息組、常旅客組、一個或多個座位請求、行程注釋組。
[0031]其中，所述根節(jié)點下有42個按順序出現(xiàn)的子元素；其中，所述42個子元素分別表示:錯誤和提示信息組、PNR信息組、運價信息組、手動運價項、旅行者具體信息組、航段信息組、服務(wù)信息組、地面信息組、航段雜項信息組、航段保險單信息組、聯(lián)系電話組、出票組、手工票證組、電子郵箱組、常旅客組、包含具備資質(zhì)者的信息、開賬并發(fā)送數(shù)據(jù)組、客戶身份信息確認(rèn)組、客戶基本信息描述組、發(fā)票憑證注釋組、到期支付的文本信息組、一般注釋組、隱藏注釋組、其他注釋組、行程注釋組、其他服務(wù)信息組、檢查預(yù)訂隊列組、表示一個或多個座位請求、最佳座位請求組、特殊服務(wù)請求組、高級旅客信息系統(tǒng)數(shù)據(jù)組、客票注釋組、用戶定義注釋組、歷史注釋組、旅游代碼元素組、結(jié)算行信息、結(jié)算信息、即將售票和票價計算處理的售票指令、PNR的歷史部分、簽注信息、出票承運人、通知組。
[0032]本發(fā)明實施例的旅客訂單數(shù)據(jù)處理方法及裝置，將分散在航空公司、機票分銷商以及機場系統(tǒng)對旅客訂單的訪問需求整理為統(tǒng)一查詢接口規(guī)范，并且增加旅客旅行過程中涉及到的其他相關(guān)信息，為各個不同系統(tǒng)提供最新、最全、最準(zhǔn)確的旅客訂單數(shù)據(jù)，不僅解決了當(dāng)前三大系統(tǒng)間PNR數(shù)據(jù)缺失、不一致的問題，而且能夠為用戶查詢不同渠道的航班數(shù)據(jù)，同時方便用戶查詢到旅行相關(guān)的其他信息。
【附圖說明】
[0033]在附圖(其不一定是按比例繪制的)中，相似的附圖標(biāo)記可在不同的視圖中描述相似的部件。具有不同字母后綴的相似附圖標(biāo)記可表示相似部件的不同示例。附圖以示例而非限制的方式大體示出了本文中所討論的各個實施例。
[0034]圖1為三大業(yè)務(wù)主體在旅客訂單的生命周期內(nèi)對旅客訂單數(shù)據(jù)的訪問需求示意圖；
[0035]圖2為三大業(yè)務(wù)主體在旅客訂單的生命周期對旅客訂單數(shù)據(jù)的訪問需求列表；
[0036]圖3為本發(fā)明實施例的旅客訂單數(shù)據(jù)處理裝置提供的全景視圖界面示意圖；
[0037]圖4a_4d為本發(fā)明實施例統(tǒng)一查詢接口的規(guī)范示意圖；
[0038]圖5為圖4中PNRIdentif icat1n的組織結(jié)構(gòu)不意圖；
[0039]圖6為圖4中FareGroup的組織結(jié)構(gòu)示意圖；
[0040]圖7為圖4中Insurance的組織結(jié)構(gòu)示意圖；
[0041 ] 圖8為圖4中FrequentTravelerGroup的組織結(jié)構(gòu)不意圖；
[0042]圖9為圖4中Seat的組織結(jié)構(gòu)示意圖；
[0043]圖10為圖4中Itinerary Remark的組織結(jié)構(gòu)不意圖。
【具體實施方式】
[0044]本發(fā)明實施例提供的旅客訂單數(shù)據(jù)處理方法及裝置、系統(tǒng)，是將分散在航空公司、機票分銷商以及機場系統(tǒng)對旅客訂單的訪問需求，通過其各自訪問邏輯整理為一套統(tǒng)一查詢接口規(guī)范，并且增加旅客旅行過程中涉及到的其他相關(guān)信息(例如酒店、租車、附加服務(wù)等)，為用戶提供最新、最全、最準(zhǔn)確的旅客訂單記錄數(shù)據(jù)。
[°°45] 本發(fā)明實施例是以統(tǒng)一訂單用戶旅行數(shù)據(jù)(CTR，Customer Travel Record)為數(shù)據(jù)基礎(chǔ)，將現(xiàn)有航空公司、機票分銷商以及機場系統(tǒng)對訂單在其生命周期內(nèi)的訪問需求整理合并為一個統(tǒng)一接口，使之成為統(tǒng)一的查詢?nèi)肟冢┎煌臉I(yè)務(wù)應(yīng)用和渠道所使用。
[0046]本發(fā)明實施例提供了一種旅客訂單數(shù)據(jù)處理方法，該方法可以包括:
[0047]首先，配置數(shù)據(jù)源:針對不同系統(tǒng)的PNR，形成相同格式的統(tǒng)一訂單CTR，作為查詢接口的數(shù)據(jù)源；
[0048]其次，配置統(tǒng)一查詢接口；
[0049]最后，基于預(yù)先配置的規(guī)則引擎，接收并處理旅客