用于预订旅行服务的Internet服务正在变得越来越复杂。
最新趋势之一是单一篮子。 购物篮的含义（单/多，读者可以根据自己的喜好添加定义）很简单-为旅行者创造机会，为航空服务和各种非航空服务（汽车租赁，住宿，交通等）预订（支付）预订。 ），将它们（如在线商店中的）扔进一个篮子中。
我将向您介绍这些技术的发展绊脚石
对于航空旅行（该行业的技术领先者），这一切始于大约10年前，当时美国航空试图在线销售各种服务。 出现了许多障碍：
- 从竞争对手的抵抗中-200根屋面毡，300份旅行社屋面毡（来自请愿人的故事）向美国参议院投诉（关于旅行社业务的死亡）；
- 但最重要的是，航空业的技术准备已经阻碍了美国航空的成立。
单个篮子的路径
2014年，国际航空运输协会（国际航空标准制定组织）宣布在通常的航空论坛会场Aviastar饭店（这是我第一次在公共场所听到）过渡到新的NDC标准。 它显示了一张图片-一个篮子，其中叠放了各种服务。 这就是电子商务客户群进入旅游行业的方式。
评论：NDC是世界航空组织的一项全球计划，其技术基础是从使用电报到xml协议进行数据交换的过渡。 XML当然可以简化集成。 但是主要目标是附加服务的市场，其潜在市场价值为每年1500亿美元，最重要的是-票务带来的利润很少，附加服务从5％（已经高于票房的获利能力）到50％。 根据一家美国旅行社的所有者的说法-在他们的业务中，机票就像超市里的牛奶，虽然不带钱，但是必须放在架子上，但是钱在另一个货架上。2017年，我们推出了第一个针对旅客的统一配送系统，只需一个篮子-您可以在篮子中放入机票：住宿，租车，中转，Aeroexpress，保险（以及每项基本服务的附加服务）。
2018年，为在喀山举行的航空论坛上的演讲做准备，描绘了如何方便地与我们合作：我将服务放在篮子里并一次性付款，以及S7的不便之处，因为每项服务都是单独购买。 我要经过S7网站的反复检查，已经有几个月没有去该网站了，这是一回事-您可以用一个篮子一次购买多个服务。 我不得不以Vnukovo网站为例。
2019年，每个人都开始按照相同的标准进行工作，到目前为止尚未完成许多项目，但仅我个人一个人就知道有4个项目在工作。 最大的是建立进口替代GDS的项目（我不会说，万能的NDA禁止其中两个）。
简而言之：通过一个篮子进行销售是一种趋势。 今天不学习如何使用篮子的任何人明天都必须寻找另一份工作。
在这里，我们谈到了有趣的事情-以及如何真正过渡到单个篮子。
评论：角色将是一家大型且受人尊敬的IT公司的员工。 这些是知识渊博的人。 本文中描述的所有荒谬之处都来自于通常的沉默。乍一看，一切都很好-GDS正在改用xml，更改预订结构，项目正在繁衍生息，一切都将以现代方式进行。 当然会有局外人，例如Leonardo PSS（乘客服务系统，该系统用于存储航空公司的所有资源：登机，航班，座位；还有很多好的PSS），该系统很新，只有5年的历史。 然而，它是基于前卢夫文电报以及关于NDC的复杂性的，这一点一点都不知道。 我们这个时代的创造甚至不知道如何以自动模式卸载时间表，它是手动运送的，并且常常忘记了按钮并且没有时间表，然后激活了手动呼叫过程。
但是这些都是靠进口替代品生活的局外人。 总的来说...并不是这里的一切都很好。 今年秋天，我碰巧问一个大型项目的首席技术专家，以建立俄罗斯的预订系统（现代的，甚至声称具有创新性），他们将使用哪种方法-GDS或市场。 然后我碰到了答案：所有东西都已经在行业中了，这里不需要发明任何东西。 我的第一个念头是：我/在错误的时间问不成功。 但是在经历了几次这样的冲突之后，并且在我对现代方法给出的结果进行了不成功的解释之后（这些冲突与不止一名员工的冲突），我意识到了该行业僵化的深度。
因此，我提出了一些案例，说明了为什么需要采用市场方法以及它们提供了什么（我有意地只将航空服务留在了篮子里，以便使这些例子更为生动，但是如果没有航空服务，这将在全球范围内推广）。 代理销售方案的示例用例。
示例一-往返运输
我们使用了最常见的搜索引擎之一-aviasales（抱歉，我尊重您，这不是您花园里的石头），然后在莫斯科和伊斯坦布尔四处寻找。 我们找到了很多建议，但没有一个能让我们满意。 我想立即作为一个旅客，自己组合航班。 但不要放弃。 怎么了 很简单
对于往返，GDS要求形成RT预订-（往返票）-往返票，即往返票。 这并不总是可能的。 最简单的示例是您是代理商站点，并且您有多个接收航班报价的资源。 还有莫斯科-伊斯坦堡就是您的一个来源。 和伊斯坦布尔－莫斯科，您来自另一个来源。 GDS说，好吧，你该怎么办...但是我们有一篮子市场，我们在那里形成需要的一套，然后制造出两种类型为OW的装甲-（单程票）-单程票，并向乘客发送2条收据路线。 一切都很方便，只需轻扫即可付款。
因此，在订单（往返航班）中，在我们的系统中，我们必须在订单中创建一个条目：Orders表。 作为主要标识符，我们不使用传统的PNR，而是使用order_n-订单号。 在服务表中有两个条目：服务，两个都有通过order_id链接到订单的链接。 在type_flight字段中，对于根据GDS规则形成的订单，我们在第一种情况下的PNR字段中设置航班类型rt的符号，而不是根据流规则，在第一种情况下使用一个标识符，在第二种情况下使用第二种标识符。 与指向电子机票和路线收据的链接相同。
这样简单的设计可以在不违反行业规则的情况下按需工作。
在这种情况下，需要一个单独的故事，以确保您肯定会预订双肩。 由于GDS中的请求已付款，因此更加狡猾。 但这完全取决于您使用的航空服务提案来源，因此让我们离开此主题。
示例二-虚拟联线
该技术使您可以合并各种航空公司的航班，即使它们与通用运价之间没有协议。 从形成对有中转服务的航班的提案（即 如果没有适合您的直航并且没有有趣的转机，请自己收集要约并获得适合您的选择。
在该方案中，存在伏击，即确保在飞行延迟的情况下安放乘客。 如果其中一种航班延误，谁将为乘客提供住宿，如果乘客抵达莫斯科-伦敦，伦敦-里亚德航班被延误，并且乘客没有时间乘坐里亚德-杰德航班，谁将弥补损失，航空公司不知道所有这些联系，以及乘客应该什么也不要。 但这已经是技术业务，并且我们在这里拥有IT资源。
对于具有类似系统的机场而言，虚拟航线特别有趣，您可以通过包含几乎全世界的航班来扩展航线网络。 但是，当然，我们最喜欢的代理商网站（或仅仅是代理商）。
让我们继续技术部分
规则-从数据库角度来看，每个航班路肩都是单独的服务，在服务表中是单独的条目。 从服务模型的角度来看，这些是可以独立处理的不同服务，主要影响自身。 他们拥有的航班类型恰好是传输到PSS的航班，主要是OW。 每个手臂都有一个PNR。 对于一个案例，当我们预订标准的多段航班时，即 根据联运协议，那么在每个路肩的表中都有记录，但是它们具有共同的service_id，即 这是一项单一的服务（如PNR），并且可以很好地进行记录，因此我们实现了标准化+您永远不知道接下来我们会为旅行者带来什么乐趣，您需要将航班原子化，以便于操作数据。 并且不要忘记在segment_number字段中输入飞行段的编号。 相应地-如果我们自己组合，那么我们将向每个部分发出一张票； 如果通过联运协议我们签发了一张票，那么可以根据唯一的service_id的数量来说。
但是这些只是数据库中的条目。 更有趣的是-行李，这实际上是另外一篇文章的原因。 但是，由于我们不是在这里进行设计，而是向您介绍IT技术大树之一分支中的当前趋势，因此足以说出这件事中最困难的事情是如何处理行李。
解说：那不是很大的戴高乐机场，那是一个很大的地方，我来得太晚了，要赞美……在某种意义上，一个胖胖的黑人妇女将我推上了跑道。无需赘述，您可以说：您需要与多个行李管理系统集成以确保自动处理行李。 但是在这里，我们显然再次超出了小文章的范围。 我们仅指示在当前系统中，在第一个飞行航段之后，有必要在机场收集行李，然后将其再次转移到下一个航段。 这增加了最短的连接时间（大致来说，您不需要一个小时来装行李，而是一个小时来接收行李+一个小时来移交行李），并且通常不友好使用。
第三个例子-包含非航空服务的购物篮阅读以下文章...