Публикуем перевод третьей статьи из серии (первая часть, вторая), посвящённой информационным технологиям в авиаперевозках. Сегодня поговорим о режиме командной строки системы Amadeus, работа в которой опирается на язык, созданный для телетайпов. Этот язык до сих пор обеспечивает огромный процент бронирований билетов во всём мире — как тех, что выполняются различными агентствами, так и тех, что делаются посредством GDS.
Зайдите в любую кассу, где продают авиабилеты. Найдите опытного агента. Понаблюдайте за его руками.
Продавцы авиабилетов не пользуются веб-сайтами. Они не щёлкают по выпадающим меню. Они вручную набирают команды, которые, на первый взгляд, выглядят как последствия прогулки кошки по клавиатуре:
AN08FEBNAGDEL
В ответ на эту команду, за время, не превышающее полсекунды, в распоряжении агента окажутся данные обо всех местах на все полёты, выполняемые 8 февраля из Нагпура в Дели. Эти данные удобно отформатированы, структурированы, готовы для дальнейшей работы с ними. И всё это — без индикаторов загрузки, используемых на обычных веб-страницах, и без применения форм, взаимодействие с которыми осуществляется посредством мыши.
Именно так выглядит работа в режиме командной строки (cryptic mode, командный режим) Amadeus. Речь идёт об интерфейсе, разработанном в 1960-е годы. Тогда каждый символ стоил денег, а время отклика систем сопоставлялось со скоростью работы телетайпов. Многие опытные агенты по продаже авиабилетов до сих пор используют режим командной строки вместе с веб-версиями соответствующих продуктов, вроде Amadeus Selling Platform Connect. А иногда агенты обходятся и без веб-инструментов. Хорошо обученный оператор, нагруженный задачами по бронированию билетов, быстрее сделает своё дело, пользуясь командной строкой, а не графическим интерфейсом, позволяющим выполнить те же действия. Преимущество в скорости теряют лишь те, кто пользуется командной строкой лишь время от времени, или агенты, которые постоянно переключаются между терминалом и графическим интерфейсом.
Расскажу о том, как с помощью командного режима Amadeus было оформлено бронирование моих билетов для поездки на конференцию ContainerDays.
Почему командный режим Amadeus всё ещё существует?
Режим командной строки Amadeus появился в условиях жёстких ограничений: в 1960-х при использовании телетайпных терминалов оплачивался каждый передаваемый символ. Каждое нажатие на клавишу стоило денег. Команда, выраженная в 50 символах, стоила в 5 раз больше, чем 10-символьная команда. Поэтому длина команд ужималась до абсолютного минимума.
В результате появился предметно-ориентированный язык, синтаксис которого был сформирован исключительно под действием экономических факторов. Так, команда Availability Next превратилась в AN. Команда Sell Segment — в SS. Команда Name — в NM, а команда End and Retrieve — в ER. Ни одной ненужной гласной. Ни одного целого слова.
Эру телетайпов пережили не экономические ограничения, а интерфейс, созданный под их влиянием. Некоторые свойства этого интерфейса оказались ценны сами по себе, независимо от стоимости передачи информации:
Высокая производительность труда экспертов. Хорошо обученный агент Amadeus, пользуясь командной строкой, способен сформировать сложный PNR-документ быстрее, чем при работе с графическим интерфейсом, где применяются страницы и выпадающие списки, где используется перемещение между полями. Такой PNR, например, может включать в себя сведения о перелётах между несколькими городами для нескольких пассажиров. Каждая операция выполняется однострочной командой. После того, как человек доведёт до автоматизма работу с командной строкой, когнитивная нагрузка, которая на него ложится, окажется ниже той, что возникает при взаимодействии с графическим интерфейсом.
Низкий уровень неоднозначности в пределах системы. В Amadeus команды однозначно связаны с соответствующими операциями. Мы вводим команду XE2 и второй элемент аннулируется. А по команде ER PNR сохраняется и загружается из системы. В системе нет скрытых состояний, напоминающих те, что имеются во всяческих «мастерах настройки», когда смысл того или иного действия зависит от того, с какого экрана оператор попал в текущее место. В системе Sabre тем же операциям соответствуют другие команды (мы поговорим об этом ниже). Смысл этого всего — в ясности конкретного диалекта языка, а не в создании универсального языка, который подходил бы для всех систем управления бронированиями авиабилетов.
Отсутствие задержек при выводе данных. При работе с веб-интерфейсом каждый эпизод взаимодействия с системой может привести к выполнению сетевого запроса, к запуску рендеринга документа на сервере, к обновлению DOM. А в командном режиме то, что выводится на экран, отражает ответ GDS, который прибывает в систему оператора в виде единой структурированной строки. Терминал, получив данные, немедленно их выводит.
Режим командной строки, если говорить на языке современного программного обеспечения — это REPL для мест в самолётах — для товара, который продают авиакомпании. И появился этот режим за 20 лет до рождения идеи REPL.
Оформление моего бронирования: построчный разбор
Ниже приведена реконструкция того, как моё бронирование NAG→DEL→LHR (DDTCIV) могло бы быть оформлено агентом Amadeus. Здесь используются реальные данные о рейсах из моего электронного билета.
Шаг 1: проверка наличия мест
Запрос:
AN08FEBNAGDEL
Расшифровка:
AN → Availability Next, команда для проверки доступности мест на рейсах 08FEB → 8 февраля NAG → Нагпур (код IATA) DEL → Дели (код IATA)
Ответ:
** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000 1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0 2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0 3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0
Расшифровка:
AI 416 Перевозчик: Air India, Рейс 416 Z9 C9 D9 Y9 B9 Каждая буква обозначает класс обслуживания (комбинация сведений о каюте/классе бронирования) Z = Бизнес-класс (повышенной категории) C, D = Опубликованный тариф бизнес-класса Y, B = Эконом-класс, полный тариф Цифра = количество доступных мест в данном классе (9 = 9 или больше) NAG DEL 0840 1030 Пункт отправления, пункт назначения, время вылета, время прилёта 32A Тип воздушного судна: семейство Airbus A320 (узкофюзеляжный самолёт для внутренних рейсов) 0 Количество промежуточных посадок: прямой рейс
Третья строка из вышеприведённого ответа содержит сведения о перевозчике IndiGo. Данные о доступности мест представленные в виде кода 6E, видны в Amadeus несмотря на то, что в IndiGo используется система Navitaire — слой дистрибуции GDS. IndiGo передаёт сведения о доступных местах в Amadeus, в результате агенты могут бронировать эти места, не покидая интерфейса GDS. Сведения о бронировании, если оно сделано через Amadeus, возвращаются в Navitaire. С точки зрения клиента всё это — одна система. С точки зрения агента всё это доступно через один терминал. А на, самом деле, за ответом, который мы разобрали, стоят три различные платформы PSS.
Шаг 2: продажа первого полётного сегмента
Запрос:
SS1Z1
Расшифровка:
SS → Sell Segment, продажа сегмента 1 → 1 пассажир Z → Класс Z (код бронирования для бизнес-класса на данном тарифе) 1 → Строка 1 с экрана наличия мест (AI416)
Ответ:
2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 32A
HK1: Holding Confirmed, бронирование подтверждено для 1 пассажира. Теперь место в системе Amadeus заблокировано и это подтверждено в PSS Altea компании Air India. Именно в этот момент происходит подтверждение приёма-передачи информации между системами Amadeus и Altea. GDS отправляет системе авиакомпании сообщение о продаже сегмента, а она подтверждает наличие мест и возвращает код статуса сегмента HK.
Шаг 3: проверка наличия мест на стыковочный рейс (DEL→LHR)
Запрос:
AN08FEBDELLHR/AAI416
Суффикс /A ограничивает поиск стыковочными рейсами, совместимыми с рейсом AI416. Эта команда сообщает Amadeus о том, что показать нужно только рейсы, которые могут быть корректно состыкованы с первым полётным сегментом. Здесь учитывается минимальное время стыковки (MCT, Minimum Connection Time) в терминале T3 аэропорта Дели. Обычно для пересадки с одного международного рейса на другой международный рейс MCT составляет 90 минут.
Ответ:
** AMADEUS AVAILABILITY - AN ** DEL LHR SU 08FEB 1030 1 AI 2015 Z9 C9 D9 Y9 B9 DEL LHR 1515 2030 789 0 2 AI 117 Z9 C9 D9 Y9 B9 DEL LHR 2105 0415+1 789 0
Расшифровка:
789 Тип воздушного судна: Boeing 787-9 Dreamliner (широкофюзеляжный дальнемагистральный самолёт) 1515 2030 Отправление 15:15, прибытие 20:30: в тот же день 4h 45m пересадка в аэропорту DEL: это удобно, так как превышает MCT
Шаг 4: продажа второго полётного сегмента
Запрос:
SS1Z1
Это — уже знакомая нам команда. Только строка 1 теперь — это AI2015, взятая с нового экрана наличия мест.
Шаг 5: имя пассажира
Запрос:
NM1SAHASRABUDDHE/AJITEM MR
Расшифровка:
NM → Name element, имя пассажира 1 → 1 1 пассажир SAHASRABUDDHE → Фамилия (должна в точности совпадать с той, что указана в паспорте) /AJITEM → Имя пассажира MR → Форма обращения
Это, в соответствии с правилами IATA, первый обязательный элемент данных, входящих в состав PNR. Имя и фамилия пассажира должны полностью совпадать с паспортными данными, иначе пассажиру могут отказать в посадке. Соответствие данных проверяется с использованием системы управления отправками (DCS, Departure Control System) при регистрации пассажиров. О GDS поговорим в 4 части.
Шаг 6: контактные сведения
Запросы:
APM-9XXXXXXXXXX APE-AJITEM@TECHNOGISE.COM
Расшифровка:
AP → Address/Phone element, адрес/телефон пассажира M → Мобильный телефон E → Электронная почта
Это — второй обязательный элемент данных PNR: контактные сведения пассажира.
Шаг 7: элемент выпуска билета
Запрос:
TKOK
TK: оформление билета. OK: без ограничений по времени. Билет будет выпущен немедленно или по требованию. Альтернатива такому подходу — выпуск билета с ограничением по времени:
Запрос:
TKTL08FEB/1200
Такой билет должен быть оформлен до 12:00 8 февраля, иначе бронирование автоматически отменяется.
Именно этот механизм стоит за предложениями вида «Забронируйте билет в течение 2 часов, или предложенная вам цена может измениться», которые можно встретить на сайтах бронирования билетов. OTA (Online Travel Agency, онлайн-туристические агентство) задаёт время оформления билета при создании PNR. Если покупатель забросил своё бронирование и не оплатил его, срок действия соответствующего элемента TK истекает, сегменты аннулируются, места возвращаются в пул свободных мест.
Шаг 8: информация о том, кто авторизовал бронирование
Запрос:
RFMYBIZ ONLINE
Это — пятый обязательный элемент PNR. Он представляет собой запись журнала аудита, несущую сведения о том, кто именно авторизовал бронирование. IATA требует наличия этих данных в PNR. Без них невозможно завершить создание PNR. Это — источник сведений о том, кем забронировано место (Booked by), присутствующих в каждом письме с подтверждением бронирования.
Шаг 9: запросы на специальное обслуживание
Запросы:
SR HNML AI HK1/SEG2 SR UPGP AI HK1/SEG2
Расшифровка:
SR → Special Service Request, запрос на специальное обслуживание HNML → Индуистское питание (без говядины, без свинины, вегетарианские опции) AI → Направлено в: Air India HK1 → Статус: бронирование подтверждено для 1 пассажира /SEG2 → В сегменте 2 (DEL→LHR: дальнемагистральный перелёт, на котором подают питание) UPGP → Сбор за повышение класса обслуживания PlusGrade (апгрейд, запрошенный через программу торгов, подтверждён)
Коды SSR стандартизированы IATA в глобальном масштабе. Система любой авиакомпании поймёт сокращение HNML. Все GDS передают эти данные в одном и том же формате. Авиакомпания должна ответить на подобный запрос. Она его может либо подтвердить (HK), либо отклонить (UN). Ответ будет записан в PNR.
Вот подборка SSR-кодов, с которыми вы можете встретиться:
WCHR → Инвалидное кресло: пассажир может дойти до места, кресло требуется на пути от терминала к самолёту WCHC → Инвалидное кресло: пассажир не может самостоятельно передвигаться VGML → Строгое вегетарианское питание (без яиц и молока) VJML → Джайнистское вегетарианское питание (без корнеплодов) KSML → Кошерное питание MOML → Мусульманское питание (халяль) DBML → Питание для диабетиков BLND → Слепой пассажир DEAF → Глухой пассажир UMNR → Ребёнок без сопровождения DOCS → Данные паспорта или проездного документа DOCA → Адрес местонахождения в пункте назначения (необходимо для рейсов в США) APIS → Дополнительная информация о пассажире (полные паспортные данные)
Шаг 10: сведения о паспорте
Запрос:
SR DOCS AI HK1/P/IND/PXXXXXXXX/IND/DDMMMYY/M/DDMMMYY/SAHASRABUDDHE/AJITEM
Расшифровка:
P → Тип документа: Паспорт IND → Страна, выдавшая документ: Индия PXXXXXXXX → Номер паспорта IND → Гражданство DDMMMYY → Дата рождения M → Пол DDMMMYY → Дата истечения срока действия паспорта
Эти данные применяются для заполнения APIS (Advance Passenger Information System, система предварительной информации о пассажире). Для рейсов, направляющихся в Соединённое Королевство, данные APIS необходимо передать в Министерство внутренних дел этого государства до отправления рейса. Соответствующие данные перемещаются из GDS в PSS авиакомпании, а затем — в правительственную систему пограничного контроля. Информация о пассажире прибывает в пункт назначения раньше самолёта.
Шаг 11: завершение работы и загрузка PNR
Запрос:
ER
Два символа. Фиксация транзакции.
Система Amadeus, получая команду ER, выполняет следующие действия:
Проверяет наличие в PNR пяти обязательных элементов.
Отправляет PSS Altea компании Air India последнее сообщение с подтверждением.
Генерирует PNR-код (DDTCIV).
Задаёт временную метку записи.
Возвращает полный PNR.
Если какой-либо обязательный элемент отсутствует — команда ER вернёт ошибку, а не предупреждение, и PNR сохранён не будет. Система требует соблюдения контракта данных до того, как запись о соответствующем бронировании будет в ней сохранена.
Полная реконструкция PNR
--- RLR --- RP/NAGAI2101/NAGAI2101 AI/SU 05DEC25/0000Z DDTCIV 1.SAHASRABUDDHE/AJITEM MR 2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 32A /01A 3 AI 2015 Z 08FEB 7 DELLHR HK1 1515 2030 E 0 789 /04K 4 APM-9XXXXXXXXXX 5 APE-AJITEM@TECHNOGISE.COM 6 TKOK 7 RF-MYBIZ ONLINE 8 SR HNML AI HK1/SEG3 9 SR UPGP AI HK1/SEG2 10 SR UPGP AI HK1/SEG3
Одиннадцать строк. Два полётных сегмента. Один пассажир. Наличие пяти обязательных элементов. Все актуальные сведения о бронировании, представленные в формате, созданном в расчёте на передачу по телетайпным сетям 1960-х годов со скоростью 110 бод.
Вызов PNR
После оформления бронирования и формирования PNR загрузка соответствующих данных из системы выполняется при помощи таких же лаконичных команд:
RTDDTCIV ← Вызов по PNR-коду RT SAHASRABUDDHE ← Вызов по фамилии пассажира RT AI416/08FEB ← Вызов всех PNR на заданный рейс или на заданную дату
А вот — команды для отмены полётных сегментов:
XE2 ← Аннулировать элемент 2 (первый полётный сегмент) XI ← Аннулировать все сегменты маршрута
Изменения в бронировании — идёт ли речь о смене места, о добавлении багажа, о внесении новых данных в элемент оформления билета — выполняются с помощью собственных кратких команд. Полное руководство по работе с командной строкой Amadeus насчитывает сотни страниц. Хорошо подготовленный агент свободно владеет примерно пятью десятками наиболее распространённых команд.
Sabre: ещё один широко используемый командный язык
В системе Sabre для выполнения тех же действий используются другие команды. Обе рассматриваемые здесь системы построены с учётом одних и тех же архитектурных ограничений 1960-х годов. А именно, речь идёт о стремлении к максимальной плотности информации в расчёте на один символ. Но эти системы создавались и развивались разными организациями в соответствии с собственными коммерческими интересами этих организаций. Именно поэтому командные языки Sabre и Amadeus пошли разными путями и до сих пор не встретились. Не существует некоего «комитета по стандартизации», который предписывал бы использование единого командного языка в сфере авиаперевозок. Переход с одного языка на другой сопровождается высокими издержками, что привязывает агентов по продаже билетов к тому языку, который они знают.
Действие |
Amadeus |
Sabre |
Доступность мест |
|
|
Продажа места |
|
|
Имя пассажира |
|
|
Оформление билета |
|
|
Кто авторизовал бронирование |
|
|
Завершение работы и загрузка PNR |
|
|
Вызов PNR |
|
|
Аннулирование элемента |
|
|
Команды Sabre применяются к той же предметной области, что и команды Amadeus. Но набор этих команд в разных системах различается. Опытные агенты, каждый из которых знает один из этих языков, могут похожими словами рассказать о том, что собираются делать, но потом, чтобы решить одну и ту же задачу, они прибегнут к разным наборам команд.
О Rust-симуляторе командного языка Amadeus
Я, когда работал над 1 и 2 частями этой серии материалов, планировал создать интерактивный симулятор командного языка Amadeus. Он представляет собой модуль, написанный на Rust + WASM, позволяющий вводить соответствующие команды и получать ответы, очень похожие на ответы GDS. Структура парсера, используемого в симуляторе, основана на грамматике рассмотренных команд.
Каждой команде однозначно соответствует её вариант, присутствующий в перечислении Rust:
enum Command { Availability(AvailabilityQuery), // AN08FEBNAGDEL SellSegment(SellQuery), // SS1Z1 AddName(PassengerName), // NM1... AddPhone(ContactDetail), // APM-... AddTicketing(TicketingElement), // TKOK / TKTL... ReceivedFrom(String), // RF... SpecialServiceRequest(SsrEntry), // SR HNML... EndAndRetrieve, // ER RetrievePnr(String), // RTDDTCIV CancelElement(u8), // XE2 Unknown(String), }
Грамматика языка достаточно строга и последовательна, поэтому простой лексический анализатор, распознающий префиксы, способен справиться с 90% команд. Тут нет неоднозначных правил вывода синтаксических конструкций, нет правил приоритета операторов, в большинстве позиций команды нечувствительны к пробелам. Такая чистота синтаксиса языка является прямым следствием изначального ограничения: неоднозначность обходилась слишком дорого в условиях, когда платить приходилось за каждый символ.
Итоги
Интерфейсы информационных систем в сфере авиаперевозок разделены на те, что предназначены для экспертов и те, что рассчитаны на обычных пользователей. Сделано это на границе системы, а не на уровне приложения. Создано два разных интерфейса, которые рассчитаны на совершенно различную аудиторию. А именно, агенты по продаже билетов используют командный режим, а обычные клиенты авиакомпаний — веб-интерфейсы. Оба эти вида интерфейсов обращаются к одним и тем же базовым системам. Этот подход жизнеспособен из-за того, что целевые аудитории разных интерфейсов чётко разграничены и их состав остаётся неизменным. Но это не распространяется на случаи, когда один и тот же человек в разных ситуациях использует как инструменты, предназначенные для экспертов, так и те, что рассчитаны на на обычных пользователей.
Особенности командных языков, которые мы рассмотрели — это отличительная черта, рассчитанная на их целевую аудиторию, а не некое универсальное достоинство этих языков. Внешние факторы, под воздействием которых появились конструкции вроде AN08FEBNAGDEL, имеют экономическую природу. В результате команды несут в себе только необходимую информацию и ничего больше. Эта особенность языка хороша в условиях, когда его синтаксис стабилен, когда язык качественно документирован, когда пользователи вкладывают силы и время в его изучение. Если же любое из этих условий не выполняется — применение такого языка становится обузой.
Жёсткие требования к соблюдению контракта данных во время записи влияют на то, где именно могут возникать ошибки. Команда ER не даст записать PNR, если в нём отсутствуют пять обязательных элементов. В результате PNR, сформированный по стандартному сценарию и сохранённый в системе, содержит в себе имя и контактные сведения пассажира, а так же — сведения об оформлении билета. Но в работающие системы, всё равно, попадают записи, сформированные не так, как это делается в большинстве случаев. Они возникают, например, в результате исправлений данных. Это могут быть записи, повреждённые в результате сбоев систем авиакомпаний, или записи, подвергшиеся ручному восстановлению. Подобное может происходить в любых GDS. Но когда всё работает в штатном режиме — в систему попадают записи, соответствующие заданной структуре данных. Это сужает круг мест, где могут возникнуть ошибки.
О, а приходите к нам работать? ? ?
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.