Корпоративная интеграция приложений

Пока систем две, их соединяют напрямую: сайт отправляет заказы в CRM, и этого хватает. Когда к ним добавляются учётная программа, склад, служба доставки и телефония, прямых связок становится всё больше. Для пяти систем, где каждая общается с каждой, это уже до десяти отдельных интеграций, и каждая ломается по-своему. Корпоративная интеграция (EAI, Enterprise Application Integration) предлагает думать о связях как об отдельной архитектуре.

Термин вошёл в обиход в конце 1990-х, когда крупные компании столкнулись с десятками несовместимых программ. Типовые приёмы описаны в книге Грегора Хопа и Бобби Вульфа «Enterprise Integration Patterns» (2003). Если интеграция программных систем — общее понятие о соединении любых программ, то EAI — про то, как организовать много таких соединений внутри одной компании.

Топологии: точка-точка, хаб, шина

• Точка-точка — каждая пара систем связана напрямую. Просто на старте, но сеть связок быстро запутывается.
• Хаб — все системы обмениваются через центральный узел, который переводит форматы. Связей ровно столько, сколько систем.
• Шина (ESB) — распределённый вариант хаба: сообщения идут через общую шину с маршрутизацией и очередями, системы подключаются к ней адаптерами.

Роль промежуточного слоя играет middleware: брокер сообщений, интеграционная платформа или собственный сервис.

Пример: заказ проходит через четыре системы

Покупатель оформляет заказ на сайте. Событие «новый заказ» попадает в интеграционный слой. Оттуда создаётся сделка в CRM, документ в 1С и задание на сборку для склада. Когда склад отгрузил заказ, обратное событие меняет статус в CRM и на сайте, а покупатель получает письмо. Ни одна система не знает о других напрямую — каждая общается только с общим слоем в согласованном формате.

Где обычно ломается

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