24小时客服热线:400 888 9966

您当前位置:旅程天下网 > 旅游攻略 > 机票知识 >

解决控制NDC交易数量问题,航空公司配置管理怎

旅程天下 发表于:2018-12-05 13:58

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

当航空公司实施NDC、并投产Offer管理模块后,就把自己置于Shopping流程的最前端,要直面Shopping请求了。实施NDC后航空公司的这个新角色,要求航空公司做好准备接收并处理各式各样的大量请求。

与此同时,对卖家和内容集成商而言,在没有控制机制的情况下,向所有能处理NDC消息的航空公司发送请求,会造成这些请求中的大部分为无效的情况,或者说航空公司没有产品能满足请求中的查询条件。如此,卖家和内容集成商的请求响应率就会非常低。

总结上述情况,航空公司将要面临的问题是可扩展能力(接收大量请求,但其中大部分为无效请求)以及处理能力和响应时间,卖家和内容集成商面临的问题是发送大量无效请求以及请求响应时间过长。

因此,航空公司需要具备这样的能力,即接收和处理对其有意义的NDC交易,并避免收到无效请求。同时,航空公司需要将这种“意愿”分发给他的分销合作伙伴。航空公司配置管理模块为航空公司提供了这种管理NDC请求数量的能力。

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

如果航空公司未将其NDC实施状态公开,那么他需要与选定的利益相关方(卖家、内容集成商或者联运合作伙伴等)就此问题达成双边协议。只有那些签订双边协议的干系人才可以向航空公司发送NDC请求并从该航空公司获得Offer,并且请求的范围是在双边协议中规定好的。该航空公司其他分销渠道的处理方式保持不变。上述过程需要航空公司和干系人双方协商完成,不属于NDC标准之范畴。

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

注:航空公司配置管理和目前使用的“航班计划数据”(译者注:应该是指基于航班计划构造航班路线的那些数据)不同——虽然AP中指定了了航空公司能接受包含哪些路线的Shopping请求,但这样做的目的只是为避免收到大量无效请求,而不是构造路线。

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集合。

例如:

  • 对于未知卖家或非合作伙伴航空公司而言,返回的信息可能非常有限:例如“不欢迎的请求”。
  • 对于那些具有全球影响力的卖家而言,返回的信息可能是“本航空公司NDC分销的全部覆盖范围都可用”。除非获得双方同意,AP的订阅者不得向任何其他利益相关方披露任何AP数据内容。

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内容。所使用的消息包括:

AirlineProfileRQ:请求一个或多个AP

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

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

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

上一篇:12月5日起国内航线燃油附加费将下调
下一篇:没有了