Об интеграциях простым языком

Развивая платформу по управлению деловыми поездками OBT Corteos, мы часто слышим такой вопрос от пользователей и партнеров: «А есть ли у вашей системы интеграция с ...?», и далее следует упоминание какой-то известной или не очень информационной системы компании: CRM, ERP, бухгалтерская или кадровая система и так далее. Можно ответить: «Интегрировать друг с другом можно практически любые информационные системы — вопрос времени и денег», а можно разъяснить, что само понятие «интеграция» очень многогранно и не так однозначно, как кажется.

Во-первых, редко когда интеграции бывают «коробочными», то есть, когда по умолчанию у какой-то OBT есть готовый интеграционный поток с множеством учетных систем клиента или агентства. Безусловно, есть примеры, когда коробочная интеграция имеется, но чаще всего она ограничивается каким-то одним продуктом, а не набором таковых. Более того, даже с одним продуктом зачастую есть необходимость делать индивидуальные интеграционные решения в силу специфики реализации конкретной системы под конкретного заказчика — кастомизированные и персонифицированные системы очень сильно отличаются друг от друга, хоть и созданы на одной и той же базе, например 1C или SAP.

Для выполнения успешной интеграции необходимы усилия с обеих сторон, при этом все зависит от того, чей протокол обмена данными используется — OBT или клиента. Больше трудозатрат возникает на стороне, интегрирующий чужой протокол. В нашем случае имплементирующей стороной выступает клиентская, так как все необходимые протоколы у нас уже созданы, и, соответственно, команда разработки на стороне клиента уже занимается интеграцией готовых протоколов в свои внутренние системы, а разработчик OBT выступает в роли консультанта и помогает довести интеграцию до рабочего состояния.

Давайте рассмотрим, какие есть виды интеграционных потоков и их направление (из внешней системы в OBT или в обратную сторону) и в чем концептуальное отличие одного от другого.

1. Аутентификация из внешней системы (SSO, Single Sign On). Технология, которая позволяет пользователю переходить из одной системы в другую без необходимости вводить логин и пароль повторно. Используется для организации перехода сотрудников из внутренней системы, корпоративного портала или с использованием системы управления учетными данными (например, SAP Logon Ticket, Microsoft Active Directory или Azure AD, Okta и т.д.).

Помимо перехода как такового, параллельно с SSO могут использоваться и веб-сервисы, обеспечивающие передачу данных из корпоративной системы в OBT — в случае, когда в организации заявка на командировку создается сначала на внутренних ресурсах, а непосредственный подбор услуг происходит уже в OBT. Например, можно передавать вводные данные о командировке: даты, направление, цель и так далее. Или данные сотрудника: ФИО, дату рождения, данные о проездных документах, структурные и корпоративные атрибуты (должность, подразделение, табельный номер, кост-центр и т.д.), — и даже создавать пользователей «на лету», ограничивать выбор сотрудника по датам, направлениям. Получается своего рода менеджер заявки на командировку, который управляется внешней системой — клиентским порталом.

2. API по заказам (API — программный интерфейс приложения, интерфейс прикладного программирования, от англ. application programming interface) — интеграционный поток, который позволяет в структурированном виде передавать информацию обо всех услугах, заказываемых и оформляемых в OBT во внешнюю систему или системы. Через такую интеграцию передается информация

• об услуге: рейс, направление, стоимость, класс бронирования, отель, звёздность, категория номера, наличие раннего заезда, класс вагона, поезд и т. д.;

• данные о пассажире: ФИО, дата рождения, документ, мильная карта, телефон, почта и т. д.;

• служебная информация: кост-центр, цель поездки, проект, раздел персонала, категория должности (грейд), департамент, принимающая организация и т. д.

• дополнительная информация: детали самого дешевого рейса (для вычисления упущенной выгоды), стоимость рядом расположенных отелей, цена тарифа без багажа на том же рейсе и т. д.

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

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

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

• персональные данные сотрудников: номер паспорта, фамилия, мильные карты, телефон, электронная почта и т. д.;

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

Указанный информационный поток позволяет настроить точечное обновление, происходящее в фоновом режиме, изменившегося параметра без необходимости «перевыгружать» большие объемы данных. Такой подвид API по статике называется CRUD API (аббревиатура от четырех основных функций, используемых при работе с базами данных: создание (англ. Create), чтение (Read), модификация (Update), удаление (Delete) — то есть его назначение в точечных воздействиях на данные.

В противовес CRUD API есть Orchestrated API, задача которого уже — работа с комбинированными сущностями и их связями в одном запросе. Иными словами, этот API позволяет обновить не только номер паспорта у конкретного сотрудника, но и фамилию, номер паспорта и телефон одновременно за одну операцию. Или загрузить целиком нового сотрудника со всеми параметрами.

4. Callbacks — колбэки или функция обратного вызова. Это механизм, который сообщает другой системе о наступлении какого-то события или срабатывании какого-то предопределенного триггера в собственной системе. Используется совместно с API и позволяет сообщать системе клиента, что необходимо запросить некую информацию, используя API.

Классический пример: в OBT произошло оформление заказа и нужно передать данные в учетную систему клиента, но запрос инициирует именно клиентская система — как она узнает, что уже пора запрашивать? Тут-то на помощь и приходят колбэки. При наступлении события смены статуса заказа, например, на «выполнен» происходит отправка колбэка в сторону клиентской системы, где есть так называемый приёмник, который, получив сообщение-колбэк уже дает команду на использование нужного метода API, например API по заказам, чтобы получить детали выполненного заказа и использовать их уже во внутренних процессах.

Схематично процессы, описанные выше, можно изобразить с помощью диаграммы:



Интеграционные взаимодействия не ограничиваются только указанными — есть и другие примеры, например, веб-сервис для внешнего согласования, который передает запрос на согласование в клиентскую систему, а затем принимает результат такого согласования обратно. Существуют сервисы, разработанные непосредственно под узкоспециализированные клиентские нужды в рамках интеграционного проекта. Также известны другие API, например, контентный, передающий из OBT во внешнюю систему тревел-контент, который уже в рамках клиентского решения (самописные клиентские OBT) предлагается пользователям для выбора.

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

Как и говорилось в начале нашего обзора — не существует универсальной пилюли для интеграций, это всегда усилия и кропотливая работа. Большинство корпоративных систем сложны, а процессы формализованы, но реализация интеграционных проектов в конечном счете заметно оптимизирует информационный и документационный обмен как внутри компании, так и в отношениях с тревел-партнером. А информационный обмен с OBT позволяет управлять собственными данными и получать всю необходимую информацию о поездках своих сотрудников без привязки к какому-то единому тревел-поставщику.

Роман Блинов,
директор департамента развития Corteos Platform