Интеграция портала туроператора с ГИС «Электронная путевка»

С чем пришли

Что сделали

• Разобрали требования

  До разработки прошли состав данных путевки и туриста, требования к среде и к порядку подключения: что система принимает, в каком виде и что для этого нужно на стороне оператора.

• Собрали отдельный сервис

  Интеграция вынесена из портала в собственный сервис на современном стеке: он принимает путевки во внутреннюю очередь, отправляет их в государственную систему и отдает порталу ее справочники.

• Связали с порталом

  Заказы копятся в собственной очереди портала и уходят в сервис по расписанию — оформление при этом не ждет внешнюю систему.

• Перестроили данные о туристах

  Состав сведений задан системой, и портал доучивался их собирать — не сломав тысячи уже оформленных заказов.

• Подготовили контур

  Настроили защищенное соединение, сервер-шлюз и разграничение доступов — без этого информационную систему не аттестуют, а без аттестации не подключат.

Технические решения

• Сервис рядом, а не внутри

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

• Очередь на стороне портала

  Портал не обращается к сервису в момент оформления. При создании и изменении заказа запись падает в собственную таблицу очереди со статусом «к отправке», а отдельный процесс раз в полчаса забирает накопленное и передает дальше. Покупатель не ждет внешнюю систему, а сбой в ней не мешает оформить заказ.

• Справочники внутрь

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

• Защищенный контур

  Соединение идет через защищенные туннели и отдельный сервер-шлюз, который мы помогли настроить и поставить под наблюдение. Разграничение прав менеджеров и администраторов пришлось делать на работающем портале, где роли за десять лет успели перемешаться.

• Свой тип данных под чужой формат

  Самая объемная часть работы пришлась не на обмен, а на данные. Услуги проживания система требует структурой, которой на платформе просто нет, — пришлось завести собственный составной тип свойства: с редактированием в административной части, множественными значениями и хранением в общем виде. Уже оформленные заказы переведены в новый формат скриптом.

После выпуска сервис прошел рефакторинг и с тех пор ведется вместе с порталом: состав путевки уточнялся не раз, добавлялись типы питания и документов, менялись правила отправки. Портал, ради которого все и затевалось, остался на своем ядре — интеграция ни разу не потребовала его трогать.