Любая интеграция с внешним поставщиком — это работа с чужой документацией, чужими форматами данных и чужой логикой процессов. Когда поставщик один, то все просто, задача понятна. Когда их несколько, каждый со своими особенностями, то архитектура проекта становится критически важной. В этом кейсе рассказываем, как за 2,5 месяца подключили агрегатор авиауслуг Nemo.Travel к корпоративному тревел-порталу. Разберем, что упростило интеграцию, где пришлось искать обходные пути и почему карта соответствий методов стала главным инструментом команды.
ZCTS (Zelenski Corporate Travel Solutions) — B2B-агентство делового туризма, работающее на российском рынке. Компания специализируется на организации командировок для корпоративных клиентов: помогает сокращать расходы на перелеты, отели и трансферы за счет оптимизации процессов и доступа к выгодным тарифам. Многолетний опыт сотрудников и собственные технологические разработки позволяют ZCTS экономить время заказчиков на организацию поездок, сохраняя при этом индивидуальный подход к каждому сотруднику клиента.
Тревел-портал ZCTS — внутренняя система для бронирования командировок (OBT). Через портал сотрудники компаний-клиентов ищут и оформляют перелеты, а система автоматически применяет корпоративные тревел-политики, проверяет соответствие правилам, контролирует бюджеты на уровне заявки и заказа. Как может быть устроена настройка тревел-политик в OBT мы показывали на примере другого проекта.
На момент старта работ портал уже был интегрирован с несколькими поставщиками авиауслуг напрямую — Mixvel, TravelPort и другими, поэтому ключевая задача была не «добавить поиск билетов», а аккуратно встроить нового провайдера в уже работающий контур бронирования, согласований и контроля отклонений. Если нужен общий ориентир по тому, какой функционал обычно входит в такие системы, у нас есть отдельный разбор: какие функции должны быть в OBT-системе.
Экран восстановления доступа: пользователь задает новый пароль в тревел-портале
Интегрировать прокси-поставщика авиауслуг Nemo.Travel за 2,5 месяца. Nemo — не конечный поставщик, а агрегатор, который объединяет множество GDS-систем в единый интерфейс. Подключение Nemo давало ZCTS доступ к дополнительным вендорам без необходимости интегрировать каждого по отдельности. Фактически один модуль открывал дверь к нескольким источникам авиаконтента. Это упрощало расширение географии и ассортимента перелетов для конечных пользователей портала.
Поиск авиабилетов: список вариантов перелета и фильтры по пересадкам и времени
В начале проекта команда получила от Nemo.Travel доступ к тестовому аккаунту, документацию на русском языке, список тест-кейсов для проверки методов и диаграмму процессов бронирования. Параллельно один из разработчиков изучил кодовую базу ZCTS. Архитектура порадовала: проект был декомпозирован на модули, каждый вендор жил в изолированном пространстве. Бизнес-логика находилась на уровень выше, а именно: работа с заказами, тревел-политики. Это позволяло сосредоточиться исключительно на интеграции прокси-поставщика, практически не затрагивая общие процессы.
Максим Соколовский
Руководитель проектного офиса
Сам проект ZCTS работает на Java 8 и Java EE — технологиях, которые сегодня считаются legacy. Архитектурно все было разложено грамотно, но в отдельных местах встречались «срезанные углы»: упрощения, сделанные ради скорости в прошлых итерациях. Приходилось учитывать эти особенности при написании нового модуля, чтобы не сломать существующую логику и при этом не множить технический долг.
Проанализировали существующие модули и выбрали оптимальный путь: взять за основу уже отлаженную архитектуру Mixvel и адаптировать ее под Nemo.Travel. Такой подход позволял сохранить единообразие кодовой базы и ускорить разработку. Первым шагом составили карту соответствий. В ней определили какое действие пользователя к какой конечной точке обращается и какой метод поставщика вызывает.
Работа разделилась на два параллельных потока. Пока один разработчик разворачивал окружение и готовил инфраструктуру, второй писал клиентский модуль для взаимодействия с API Nemo.Travel. После того как рабочее окружение было развернуто, появилась возможность протестировать все процессы из пользовательского интерфейса. Это дало понимание, к каким конечным точкам обращается фронтенд и к вызову каких методов поставщика это приводит.
Используя документацию и диаграмму процессов от Nemo.Travel, команда расширила карту соответствий и приступила к разработке основного модуля поставщика.
За время работы с тревел-системами мы интегрировали разных поставщиков авиаконтента (GDS): Sabre, Amadeus, S7, TravelPort. На этом фоне Nemo.Travel оказался удобнее прямых вендоров по нескольким причинам. При поиске можно сразу задать класс обслуживания, тип тарифа, количество пересадок — Nemo возвращает уже отфильтрованный список. В модулях других поставщиков фильтрация происходила постфактум, на стороне OBT.
Унифицированные структуры данных тоже сыграли свою роль. Перелет, пассажир, сегмент — эти сущности описаны одинаково для разных методов. Это сократило объем кода по сравнению с модулями, где каждый метод возвращал данные в своем формате. Документация на русском языке ускорила понимание логики работы API. Не приходилось тратить время на перевод и интерпретацию терминов.
Диаграмма процессов Nemo.Travel: от поиска до отмены брони
Несмотря на удобную структуру данных, первые дни ушли на то, чтобы разобраться, какое поле Nemo соответствует какому полю интерфейса ZCTS. Как только формат стал понятен, скорость разработки выросла.
Отдельная история — тестовые данные. Nemo использует тестовые аккаунты конечных поставщиков. Часть рейсов приходила от несуществующих авиакомпаний, часть — не позволяла выполнить определенные операции. Приходилось искать подходящие рейсы для каждого тест-кейса вручную.
Процесс аннуляции потребовал нестандартного решения. При аннуляции билета прокси-поставщик переводит услугу в статус «Забронирован», после чего требуется отдельный запрос на отмену. В ZCTS пользователь ожидает, что кнопка «Аннулировать» завершает процесс сразу. Команда решила скрыть эту разницу от пользователя: при нажатии на кнопку система отправляет запрос на аннуляцию, затем фоновая задача периодически проверяет статус. Как только Nemo завершает аннуляцию, автоматически уходит запрос на отмену.
Нормализовали поведение поставщика под ожидаемую модель портала. Пользователь делает одно действие, а система сама проходит нужную последовательность шагов у вендора и возвращает финальный результат.
Nemo.Travel предоставил документ с тест-кейсами: какие методы проверить, для каких сочетаний пассажиров. Это не формальность, так как по результатам тестирования компания запрашивает логи и дает месяц на подключение продакшн-аккаунта и выпуск интеграции в релиз.
Интеграция Nemo.Travel в ZCTS: экран поиска авиабилетов в интерфейсе корпоративного портала
Команда прошла все кейсы, собрала логи запросов и ответов по SOAP-методам. После подтверждения со стороны прокси-поставщика получила доступ к боевому окружению. На продакшене всплыли новые артефакты: поведение отличалось от тестового.Это как раз тот класс проблем, который не видно по документации: интеграция считается сделанной только когда одинаково стабильно работает в боевом контуре. Техподдержка Nemo реагировала быстро, вопросы решались по почте в течение дня.
Финальный этап — обучение. Nemo провел видеоконференцию для команды разработки и представителей ZCTS по администрированию личного кабинета.
За 2,5 месяца команда из двух разработчиков интегрировала полный цикл работы с авиауслугами: поиск, бронирование, оформление, аннуляцию, возврат. ZCTS получил доступ к дополнительным GDS-системам через единую точку входа. Модульная архитектура проекта позволила встроить нового поставщика без изменений в бизнес-логике.
Интеграция открыла перспективу дальнейшего развития: теперь ZCTS рассматривает подключение других поставщиков, используя наработанный подход и карту соответствий как шаблон для будущих модулей.
Карта соответствий методов помогла быстро сориентироваться в документации и сохранить единообразие кодовой базы. Параллельная работа над инфраструктурой и клиентским модулем сократила общий срок разработки. Тесное взаимодействие с техподдержкой вендора позволило оперативно решать вопросы, которые не были описаны в документации. В итоге команда из двух разработчиков уложилась в 2,5 месяца.
Отдельно стоит отметить роль архитектуры самого проекта ZCTS. Модульная структура, где каждый поставщик живет в изолированном пространстве, а бизнес-логика вынесена на уровень выше — это то, что делает подобные интеграции предсказуемыми. Новый модуль встраивается в систему без изменений в существующем коде, а накопленный опыт становится шаблоном для будущих подключений.
Если вашему бизнесу нужна интеграция с поставщиками авиауслуг, GDS-системами или другими тревел-сервисами, мы можем подключиться на любом этапе или взять задачу под ключ: оценить документацию и процессы, спроектировать модуль поставщика, пройти тест-кейсы, довести интеграцию до продакшена.
Команда Work Solutions имеет опыт работы с корпоративными тревел-порталами и понимает специфику отрасли: сложные процессы бронирования, сертификацию у вендоров, требования к отказоустойчивости.
Напишите — обсудим вашу текущую архитектуру и подскажем самый безопасный путь подключения, без переписывания ядра и сюрпризов на релизе.
