航空公司配置管理

NDC的航空公司配置管理模块为航空公司提供一种能力,使航空公司可以选择只接收有意愿接收的请求或者有能力响应的请求。虽然在NDC实施中该模块可选,但该模块对于航空公司而言是管理请求量的极佳途径。

解决控制NDC交易数量这个问题有两种方案可选:一种就是航空公司配置管理(AP),另一种则是通过双方协议以及协议执行。选择哪一种方案由航空公司自行决策。

航空公司配置管理将AP分发给分销干系人,相当于航空公司告知分销渠道自己愿意接收何种请求以及接收哪个等级的NDC消息,AP的内容包括但不限于:环境变量、服务、销售点(POS),航空市场或路线等。

NDC并不强制要求使用航空公司配置管理功能——航空公司通过“NDC capable”时认证并不要求维护配置管理规则(AP)——不过配置管理模块确实是个不错的管理日益增加的NDC请求的工具。同样,AP中的规定对卖家和内容集成商也非强制性的,NDC标准以及航空公司配置管理功能中没有定义任何机制来防止分销干系人向航空公司发送请求——该请求是航空公司配置管理规则(AP)中指明航空公司不接受的请求类型。

另一方面在联运场景中,Offer责任航空公司(ORA)、卖家和内容集成商都可使用航空公司配置管理功能。在联运场景中,当ORA无法通过自身的产品和服务满足卖家或内容集成商发来的完整需求时,可通过配置管理机制向POA(Offer参与航空公司)发送拆分后的Shopping请求。

NDC为AP定义了标准内容以及用于交互AP信息的XML Schemas。

AP的所有权与维护

航空公司拥有AP并负责维护AP。关于AP存储的位置:AP可以在航空公司内部系统中存储和维护,也可以托管由第三方在外部存储和维护。NDC标准对AP的存储位置并没有要求——这件事交给每个航空公司自行决定。

如果一家航空公司没有定义AP规则,除非该航空公司另行签订了双边协议,否则默认情况下,航空公司不接受来自请求者的NDC交易查询。

每家航空公司都有义务确保其AP规则保持最新状态,并且要保证AP已经同步分发给了所有参与NDC消息交互的各方。当然,AP中不应包含与航空公司和分销干系人之间商业协议的信息。关于如何定义AP的确切内容或者创建、使用、维护或删除AP的相关机制则不属于NDC标准的范畴。

航空公司负责维护自己AP的全部内容,对每个分销干系人而言,则只能访问与自身相关的那部分内容,即与航空公司达成协议并由航空公司批准的内容。每个卖家或内容集成商的AP信息都可能不同,而且航空公司也有权利为不同的请求者响应不同的Offer集合。

AP的使用

AP的使用是Shopping过程的重要组成部分。

为了满足给定客户的需求,内容集成商或者卖家首先需要确定哪些航空公司能够响应该请求。为了回答这个问题,内容集成商或卖家需要查询自己的“AP子集”。

航空公司分发AP数据有两种方式,即“拉”和“推”。

为提高效率,无论使用“拉”还是“推”方法,都推荐请求者在收到最新的AP数据后在其本地存储一个AP的副本,这样在发起Shopping请求之前,不需要连接航空公司获取AP数据。事实上,“拉”和“推”两种方式都用于更新此本地副本。

还应注意,在Shopping响应中仅返回该卖家或内容集成商被允许访问的Offer和信息。

在采用“拉”方法更新AP时,卖家、内容集成商或POA都需要向航空公司发送消息以请求最新的AP数据,如果该航空公司自行维护AP那么该消息直接发送给航空公司,否则如航空公司使用外包的AP主机,则请求发给外包主机。

虽然,可以在每次Shopping请求时发送AP更新请求,不过这种方式会给航空公司的系统造成很大负担,并使响应时间增加。所以,通常情况下采用定期发送AP更新请求的办法,发送的频率或者由卖家和内容集成商确定,或者由卖家、内容集成商与航空公司双方商定。

“推”方法是航空公司向卖家、内容集成商单方向的交互——航空公司(或外包主机)将相关的AP数据推送给特定的卖家、内容集成商或者POA。

每当航空公司更新AP数据之后就会触发AP数据的“推”操作。可采用定期推送——根据双方商定的时间点或者采用随时更新随时推送的办法。有些航空公司可能会对不同的分销合作伙伴采用不同的AP同步方式。

当分销合作伙伴决定将Shopping请求发送给哪些航空公司时,需要查询AP数据以得出备选航空公司,查询使用的匹配条件包括:

  • 请求的日期
  • 行程日期(出发地、目的地等等)

卖家获得的输出结果是符合上述条件的航空公司列表,这些航空公司就是能够响应该Shopping请求的航空公司。如果卖家(或内容集成商)存储了本地AP副本,则这个查询操作只发生在卖家的内部系统中。

AP使用流程的例子在3.1.4节“Shopping用例”中提供。

如果发生更新AP的请求,需要的参数包括:

  • 接收者的ID:用于识别AP的接收者。这个ID可以是航空公司分配给内容集成商的ID、卖家的ID或者航空公司订单管理数据字典中定义的航空公司识别码(译注:可以用航空公司两字码)。
  • 航空公司:请求更新AP的所有者航空公司。

 AP功能专用的Schemas

如前文所述,接收者获得AP数据有“拉”和“推”两种主要方式:

  • “拉”方法:AP的接收者向AP的发送者发起一个或多个AP的更新请求,对应的AP发送者则向AP接收者发送正确的AP内容。所使用的消息包括:

Airline Profile RQ:请求一个或多个AP

Airline Profile RS:对请求的响应,包含AP的地址链接或者AP内容

  •  “推”方法:AP发送者将AP本身或者地址链接推送给“活动的”或“已授权的”的AP接收者。所使用的消息包括:

Airline Profile Notif:提供一种机制,单方向的AP本身或指向AP的地址链接推送给之前已获得授权的AP接收者。

(来源:微信公众号 航旅IT圈)

 

搜索