Публикуем перевод третьей статьи из серии (первая часть, вторая), посвящённой информационным технологиям в авиаперевозках. Сегодня поговорим о режиме командной строки системы Amadeus, работа в которой опирается на язык, созданный для телетайпов. Этот язык до сих пор обеспечивает огромный процент бронирований билетов во всём мире — как тех, что выполняются различными агентствами, так и тех, что делаются посредством GDS.

Зайдите в любую кассу, где продают авиабилеты. Найдите опытного агента. Понаблюдайте за его руками.

Продавцы авиабилетов не пользуются веб-сайтами. Они не щёлкают по выпадающим меню. Они вручную набирают команды, которые, на первый взгляд, выглядят как последствия прогулки кошки по клавиатуре:

AN08FEBNAGDEL

В ответ на эту команду, за время, не превышающее полсекунды, в распоряжении агента окажутся данные обо всех местах на все полёты, выполняемые 8 февраля из Нагпура в Дели. Эти данные удобно отформатированы, структурированы, готовы для дальнейшей работы с ними. И всё это — без индикаторов загрузки, используемых на обычных веб-страницах, и без применения форм, взаимодействие с которыми осуществляется посредством мыши.

Именно так выглядит работа в режиме командной строки (cryptic mode, командный режим) Amadeus. Речь идёт об интерфейсе, разработанном в 1960-е годы. Тогда каждый символ стоил денег, а время отклика систем сопоставлялось со скоростью работы телетайпов. Многие опытные агенты по продаже авиабилетов до сих пор используют режим командной строки вместе с веб-версиями соответствующих продуктов, вроде Amadeus Selling Platform Connect. А иногда агенты обходятся и без веб-инструментов. Хорошо обученный оператор, нагруженный задачами по бронированию билетов, быстрее сделает своё дело, пользуясь командной строкой, а не графическим интерфейсом, позволяющим выполнить те же действия. Преимущество в скорости теряют лишь те, кто пользуется командной строкой лишь время от времени, или агенты, которые постоянно переключаются между терминалом и графическим интерфейсом.

Расскажу о том, как с помощью командного режима Amadeus было оформлено бронирование моих билетов для поездки на конференцию ContainerDays.

Режим командной строки 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. Здесь используются реальные данные о рейсах из моего электронного билета.

Запрос:

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.

Запрос:

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.

Запрос:

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

Запрос:

SS1Z1

Это — уже знакомая нам команда. Только строка 1 теперь — это AI2015, взятая с нового экрана наличия мест.

Запрос:

NM1SAHASRABUDDHE/AJITEM MR

Расшифровка:

NM → Name element, имя пассажира
1 → 1 1 пассажир
SAHASRABUDDHE → Фамилия (должна в точности совпадать с той, что указана в паспорте)
/AJITEM → Имя пассажира
MR → Форма обращения

Это, в соответствии с правилами IATA, первый обязательный элемент данных, входящих в состав PNR. Имя и фамилия пассажира должны полностью совпадать с паспортными данными, иначе пассажиру могут отказать в посадке. Соответствие данных проверяется с использованием системы управления отправками (DCS, Departure Control System) при регистрации пассажиров. О GDS поговорим в 4 части.

Запросы:

APM-9XXXXXXXXXX
APE-AJITEM@TECHNOGISE.COM

Расшифровка:

AP → Address/Phone element, адрес/телефон пассажира
M → Мобильный телефон
E → Электронная почта

Это — второй обязательный элемент данных PNR: контактные сведения пассажира.

Запрос:

TKOK

TK: оформление билета. OK: без ограничений по времени. Билет будет выпущен немедленно или по требованию. Альтернатива такому подходу — выпуск билета с ограничением по времени:

Запрос:

TKTL08FEB/1200

Такой билет должен быть оформлен до 12:00 8 февраля, иначе бронирование автоматически отменяется.

Именно этот механизм стоит за предложениями вида «Забронируйте билет в течение 2 часов, или предложенная вам цена может измениться», которые можно встретить на сайтах бронирования билетов. OTA (Online Travel Agency, онлайн-туристические агентство) задаёт время оформления билета при создании PNR. Если покупатель забросил своё бронирование и не оплатил его, срок действия соответствующего элемента TK истекает, сегменты аннулируются, места возвращаются в пул свободных мест.

Запрос:

RFMYBIZ ONLINE

Это — пятый обязательный элемент PNR. Он представляет собой запись журнала аудита, несущую сведения о том, кто именно авторизовал бронирование. IATA требует наличия этих данных в PNR. Без них невозможно завершить создание PNR. Это — источник сведений о том, кем забронировано место (Booked by), присутствующих в каждом письме с подтверждением бронирования.

Запросы:

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 → Дополнительная информация о пассажире (полные паспортные данные)

Запрос:

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 авиакомпании, а затем — в правительственную систему пограничного контроля. Информация о пассажире прибывает в пункт назначения раньше самолёта.

Запрос:

ER

Два символа. Фиксация транзакции.

Система Amadeus, получая команду ER, выполняет следующие действия:

1. Проверяет наличие в PNR пяти обязательных элементов.

2. Отправляет PSS Altea компании Air India последнее сообщение с подтверждением.

3. Генерирует PNR-код (DDTCIV).

4. Задаёт временную метку записи.

5. Возвращает полный PNR.

Если какой-либо обязательный элемент отсутствует — команда ER вернёт ошибку, а не предупреждение, и 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 загрузка соответствующих данных из системы выполняется при помощи таких же лаконичных команд:

RTDDTCIV         ← Вызов по PNR-коду
RT SAHASRABUDDHE ← Вызов по фамилии пассажира
RT AI416/08FEB   ← Вызов всех PNR на заданный рейс или на заданную дату

А вот — команды для отмены полётных сегментов:

XE2 ← Аннулировать элемент 2 (первый полётный сегмент)
XI  ← Аннулировать все сегменты маршрута

Изменения в бронировании — идёт ли речь о смене места, о добавлении багажа, о внесении новых данных в элемент оформления билета — выполняются с помощью собственных кратких команд. Полное руководство по работе с командной строкой Amadeus насчитывает сотни страниц. Хорошо подготовленный агент свободно владеет примерно пятью десятками наиболее распространённых команд.

В системе Sabre для выполнения тех же действий используются другие команды. Обе рассматриваемые здесь системы построены с учётом одних и тех же архитектурных ограничений 1960-х годов. А именно, речь идёт о стремлении к максимальной плотности информации в расчёте на один символ. Но эти системы создавались и развивались разными организациями в соответствии с собственными коммерческими интересами этих организаций. Именно поэтому командные языки Sabre и Amadeus пошли разными путями и до сих пор не встретились. Не существует некоего «комитета по стандартизации», который предписывал бы использование единого командного языка в сфере авиаперевозок. Переход с одного языка на другой сопровождается высокими издержками, что привязывает агентов по продаже билетов к тому языку, который они знают.

Команды Sabre применяются к той же предметной области, что и команды 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. Но когда всё работает в штатном режиме — в систему попадают записи, соответствующие заданной структуре данных. Это сужает круг мест, где могут возникнуть ошибки.