Миграция с зарубежных ESB без остановки бизнеса: методология ЕМДЕВ - Entaxy

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

Возникают вполне конкретные риски:

• Отсутствие обновлений по безопасности — уязвимости остаются неустранёнными.

• Юридические и финансовые последствия — нарушение требований регулирующих органов.

• Нарастание технического долга — невозможность развивать интеграции под новые задачи бизнеса.

• Зависимость от посредников — обслуживание только через непрозрачные схемы и дорогостоящих подрядчиков.

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

Специфика SAP PI/PO и IBM Integration Bus: что именно мигрируют

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

SAP PI/PO (Process Integration / Process Orchestration) — интеграционная платформа SAP, обеспечивающая обмен данными между системами SAP и внешними прикладными решениями. Крупные компании строят на ней сотни маршрутов данных, используют собственные механизмы описания преобразований (XSLT, Java-маппинги), процессы на основе BPEL и широкий набор адаптеров. Миграция с SAP PI/PO означает перенос не только технической платформы, но и всей заложенной в неё бизнес-логики интеграций, реализованной в XML-сценариях и Java‑компонентах.

IBM Integration Bus (IIB) / IBM App Connect Enterprise — промышленная интеграционная шина, построенная вокруг концепции потоков сообщений (message flow). Каждый такой поток создаётся и сопровождается в специализированной графической среде IBM Integration Toolkit. Критическая особенность в том, что значительная часть логики реализована на языке ESQL и в формате IBM MessageSet, которые не имеют прямых аналогов в других платформах.

Ключевая сложность миграции с обеих платформ — отсутствие универсального конвертера. Нельзя просто «выгрузить» сценарии из SAP PI/PO или IBM IIB и «загрузить» их в новую систему. Каждую интеграцию приходится анализировать, перепроектировать и заново тестировать. Дополнительное усложнение вносит тот факт, что большинство интеграций работают в круглосуточном режиме, а любой простой приводит к значительным финансовым потерям.

ЕМДЕВ и платформа Энтакси: российская альтернатива

Компания ЕМДЕВ — российский разработчик и системный интегратор, который с 2010 года специализируется исключительно на интеграционных проектах. Платформа Энтакси (ранее известная как Энтакси ESB) создавалась как прямая замена зарубежным интеграционным решениям, таким как IBM Integration Bus, MuleSoft Anypoint Platform, Oracle Service Bus и webMethods Software AG.

По результатам независимого рейтинга российских ESB-платформ CNewsMarket 2025, Энтакси вошла в число лидеров, набрав 800 баллов при максимальном значении у лидера порядка 881 балла. В рамках рейтинга решения оценивались по почти ста параметрам, включая функциональность, возможности масштабирования, уровень безопасности и качество технической поддержки.

Техническая архитектура Энтакси

Энтакси построена на открытом стеке технологий. В качестве ядра исполнения используется контейнер модулей (OSGi-контейнер) Apache Karaf. Функции маршрутизации и работы с подключениями обеспечиваются за счёт фреймворка Apache Camel. В роли брокера сообщений применяется Apache ActiveMQ Artemis. Для хранения конфигурационной информации используется реляционная база данных PostgreSQL или отечественный вариант PostgresPro. Описание маршрутов выполняется на языке XML DSL, который предоставляет Apache Camel. Развёртывание платформы возможно на виртуальных машинах, в контейнерах Docker и в кластерах Kubernetes.

Такая архитектура обеспечивает полную технологическую независимость: ни один компонент стека не является закрытым продуктом зарубежного вендора и не подпадает под санкционные ограничения. Энтакси включена в реестр российского программного обеспечения Минцифры России под записью № 12268.

Ключевые функциональные возможности

Энтакси реализует все базовые сценарии, которые обычно покрываются SAP PI/PO и IBM IIB:

• Поддерживаются как синхронные, так и асинхронные взаимодействия с использованием SOAP, REST, очередей сообщений (JMS), Kafka, а также файловых адаптеров.

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

• Выполняются трансформация и сопоставление данных с использованием XSLT и визуального инструмента AtlasMap.

• Реализована гарантированная доставка сообщений и транзакционная модель обработки.

• Поддерживаются интеграции с системами 1С через встроенный коннектор, а также взаимодействие с SAP, службами OData и форматами электронного обмена данными (EDI).

• Имеется централизованный механизм обработки ошибок с логированием и функционалом аудита.

• Встроены инструменты для организации конвейера непрерывной поставки (CI/CD) и переноса конфигураций между средами разработки, тестирования и промышленной эксплуатации.

• Для наблюдаемости и контроля в реальном времени используется веб‑консоль и интеграция с системой визуализации метрик Grafana.

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

Методология миграции ЕМДЕВ: переход без остановки бизнеса

ЕМДЕВ выработала поэтапную методологию миграции, в основе которой лежит принцип параллельной работы двух интеграционных систем. Действующая шина продолжает обрабатывать рабочий трафик, в то время как новая платформа постепенно берёт на себя всё больше функций. Такой подход позволяет избежать единого «момента истины», когда переключение может привести к остановке критичных бизнес-процессов.

Этап 1. Предпроектное исследование и аудит

На первом, наиболее ответственном этапе проводится детальный аудит текущего состояния интеграций:

• Выполняется инвентаризация интеграций, формируется полный перечень активных маршрутов, адаптеров, форматов данных и используемых протоколов.

• Проводится приоритизация по уровню критичности: выделяются интеграции категории A, при остановке которых работа компании существенно нарушается, интеграции категории B, при отказе которых происходит деградация сервисов, и интеграции категории C, которые при необходимости можно временно отключить.

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

• Формируются технические задания на миграцию для каждой группы интеграций.

• Проектируется целевая архитектура: определяются схемы развёртывания, последовательности вызовов, правила трансформации данных и основные интеграционные паттерны.

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

Этап 2. Развёртывание целевой платформы

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

• Компактная схема «всё в одном», когда брокер сообщений, база данных и пользовательский интерфейс размещаются в одном контейнере — такой вариант часто используется для пилотных проектов и тестовых стендов.

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

• Развёртывание в средах Kubernetes или на платформах, построенных на его основе (например, Deckhouse) для организации облачно-нативной архитектуры.

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

Развёртывание автоматизируется с использованием сценариев управления конфигурацией, что обеспечивает воспроизводимость и документируемость всех операций. Именно таким образом был развернут контур для Светогорского целлюлозно‑бумажного комбината (Sylvamo).

Этап 3. Пилотная миграция: интеграции категории A

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

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

Для каждой интеграции в рамках этого этапа выполняется последовательность действий:

1. Разработка маршрута в Энтакси с использованием XML‑описания и, при необходимости, визуального редактора.

2. Функциональное тестирование на изолированном стенде.

3. Интеграционное тестирование совместно с системами‑источниками и системами‑потребителями данных.

4. Нагрузочное тестирование и подтверждение соблюдения целевых соглашений об уровне обслуживания (SLA).

5. Переключение рабочего трафика на новую реализацию и наблюдение за её работой в течение установленного «карантинного» периода.

Этап 4. Поточная миграция: интеграции категорий B и C

После успешного завершения пилотного этапа начинается поточная миграция остальных интеграций. ЕМДЕВ использует подход модульной декомпозиции, при котором интеграции группируются по бизнес‑доменам — например, финансы, логистика, управление персоналом, взаимодействие с контрагентами. Далее домены переносятся поочерёдно.

Для ускорения работ применяется библиотека готовых коннекторов Энтакси, которая включает более трёхсот типовых компонентов. В её состав входят коннекторы для 1С, SAP, веб‑служб (REST и SOAP), файловых систем, системы обмена сообщениями Kafka и совместимых с S3 хранилищ объектов.

Многие преобразования данных реализуются с использованием заранее подготовленных шаблонов XSLT и механизма AtlasMap, который позволяет задавать сопоставление полей в визуальном режиме. Это существенно снижает объём ручного программирования и ускоряет миграцию.

Этап 5. Опытно-промышленная эксплуатация

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

• Все интеграции функционируют через Энтакси в реальном промышленном режиме.

• Старая шина сохраняется в режиме горячего резерва и при необходимости может принять на себя часть или весь трафик.

• Осуществляется непрерывный мониторинг, в том числе с использованием визуализации в Grafana и встроенных средств аудита Энтакси.

• Фиксируются ключевые показатели: доля успешно обработанных сообщений, среднее и максимальное время обработки, количество и типы ошибок.

Этап 6. Передача документации и сопровождение

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

Энтакси vs SAP PI/PO и IBM IIB

SAP PI/PO и IBM Integration Bus после 2022 года стали недоступны для полноценного использования и обновления в России: официальная поддержка и поставки были прекращены. Энтакси, напротив, разрабатывается российским поставщиком, не ограничена в применении на территории страны и входит в реестр отечественного программного обеспечения.

SAP PI/PO и IBM IIB не включены в реестр Минцифры России. Энтакси, напротив, официально зарегистрирована под записью № 12268, что упрощает её использование в государственных и регулируемых сегментах. Лицензионная модель SAP и IBM традиционно отличается высокой стоимостью, часто привязана к подписке или вычислительным ресурсам (например, числу процессорных ядер). Энтакси предлагает как срочные, так и бессрочные лицензии, что даёт больше гибкости при планировании бюджета.

С точки зрения разработки SAP PI/PO предполагает участие как аналитиков, так и разработчиков. IBM Integration Bus ориентирован в первую очередь на разработчиков. Энтакси делает акцент на подходе с низким порогом программирования, когда значительную часть работы может выполнять аналитик, используя визуальные инструменты и шаблоны.

Языки описания маршрутов также различаются. В SAP PI/PO широко применяются BPEL и Java. В IBM IIB основная логика пишется на ESQL и Java. В Энтакси маршруты описываются на основе XML DSL фреймворка Apache Camel, который хорошо документирован и поддерживается сообществом.

В части коннекторов SAP PI/PO ориентирован прежде всего на экосистему SAP. IBM IIB предоставляет широкий спектр подключаемых модулей для различных систем. Энтакси также предлагает большой набор коннекторов, включающий более трёхсот компонентов, в том числе специализированные модули для 1С и SAP. Встроенная поддержка 1С является одним из ключевых преимуществ Энтакси: в SAP и IBM подобная интеграция обычно требует создания кастомных решений.

По отказоустойчивости SAP PI/PO использует собственный кластерный механизм, IBM IIB — кластерные конфигурации на базе технологий IBM. Энтакси помимо стандартного кластерного развёртывания поддерживает связку нескольких независимых шин через механизм Bridge, что позволяет строить сложные распределённые решения и поэтапно мигрировать нагрузку.

С точки зрения вариантов развёртывания SAP PI/PO и IBM IIB традиционно поставляются для локальной установки в инфраструктуре заказчика. Энтакси также поддерживает локальное развёртывание, при этом дополнительно оптимизирована для работы в виртуализированных средах и контейнерах, включая Docker и Kubernetes.

Типичные риски миграции и подход ЕМДЕВ к их снижению

Проекты миграции интеграционных решений связаны с целым рядом рисков. Среди наиболее распространённых:

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

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

• Недостаточная производительность новой платформы, из‑за чего может происходить деградация сервисов. В методологии ЕМДЕВ предусмотрен предварительный расчёт требуемых ресурсов по итогам аудита и обязательные нагрузочные тесты до переключения боевого трафика.

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

• Несовместимость протоколов и форматов данных, при которой некоторые интеграции могут оказаться неработоспособными. Здесь помогает широкая библиотека коннекторов и готовые шаблоны преобразования, включая решения для интеграции с 1С.

Когда начинать миграцию и к чему приводит затягивание

Миграцию с зарубежных интеграционных платформ нельзя рассматривать как задачу «на потом». Каждый месяц эксплуатации неподдерживаемой шины увеличивает совокупный риск. Со временем накапливается технический долг, снижающий скорость цифровой трансформации. Число специалистов, владеющих устаревающими технологиями SAP PI/PO и IBM IIB, сокращается, и компании становится всё сложнее поддерживать существующие интеграции.

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

Организации, которые начали миграцию в 2023–2024 годах, уже работают на независимой платформе, которую можно развивать и наращивать под новые задачи. Те, кто откладывает переход, зачастую всё сильнее зависят от непрозрачных схем поддержки, платят больше за сопровождение и сталкиваются с растущим отставанием в развитии ИТ‑ландшафта.

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