С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20 разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина.
Ссылка на продукт: https://www.inpolus.ru/platform/
О компании: ООО «Инполюс» работает с 2009 года. До этого команда занималась внедрением интеграционных шин и BPM-систем и проектами на их основе в другой компании, оттуда ушла и организовала собственную. Практически вся история «Инполюса» — это интеграционные проекты, изначально на зарубежных платформах: Oracle SOA Suite, TIBCO, IBM Message Broker и другие. В опыте есть и доработка уже развернутых шин, и проекты целиком: перевод унаследованных самописных решений на Pascal и Java на промышленные платформы.
Собственную разработку в компании начали не с шины. Первым продуктом стал инструмент для того, что за рубежом называли SOA Governance: единое место, где описано, какие на предприятии есть сервисы и сценарии, с автоматизацией запусков по расписанию. Исполняемой средой при этом оставались зарубежные платформы. Когда с ними все стало понятно, появилась и собственная шина.
Состав платформы
Сейчас платформа состоит из четырех компонентов:
- Inpolus ESB — собственно шина, среда разработки и исполнения интеграционных процессов.
- Inpolus Registry — реестр сервисов, единая среда описания и управления жизненным циклом сервисов.
- Inpolus Scheduler — менеджер сценариев, единая среда управления запусками по расписанию и событиям.
- Inpolus Data — объектное хранилище для больших сообщений.
Позиционируются и продаются три первых продукта, все они зарегистрированы в реестре отечественного ПО — регистрация проходила на рубеже 2022 и 2023 годов. Inpolus Data отдельно не продается, идет как составная часть шины. Пятый компонент, Inpolus ETL, пока в разработке, поэтому в обзор не попал.
Технологический стек
Под капотом шины — Apache Synapse и Axis2. С 2022 года вендор фактически форкнул проект и развивает его самостоятельно: переписано уже очень много, обратно в сообщество доработки не передаются. Пути разошлись и идеологически: Synapse и WSO2 ушли в сторону API-менеджмента и превратились в некий портал, «Инполюс» остался на позициях классической ESB.
Java — 11-я. До релиза 1.11, вышедшего в начале года, была 8-я. Конкретных сроков перехода на более новую версию вендор пока не называет.
Среда разработки сделана на базе Eclipse. Ведется работа по переносу на IntelliJ IDEA: шаблоны и заготовки готовы, проект можно собирать, деплоить и раздеплоивать, сейчас идет работа над визуальным редактором сценариев.
Серверная часть — Java-приложение. Оно поставляется либо в виде архива, который достаточно распаковать и запустить, либо как готовый Docker-контейнер, который можно развернуть в Docker, Kubernetes или на любой другой платформе с поддержкой контейнеров.
Дополнительно вендор предлагает готовый набор интегрированных open-source-компонентов: Prometheus и Grafana — для мониторинга с преднастроенными метриками и дашбордами, Graylog — для централизованного сбора и анализа журналов, OpenTelemetry и Jaeger — для трассировки, GitLab — для автоматической сборки и развертывания с подстановкой чувствительных параметров из Vault. В состав решения также входят Consul, через который синхронизируются описания между реестром и менеджером сценариев, и Redis.
Есть сертификаты совместимости с Astra Linux Special Edition, РЕД ОС и «Альт», а также сертификат «1С:Совместимо».
Функциональные возможности
В шине два связанных между собой движка.
Data Service позволяет выстроить работу с базой данных в виде SOAP или REST-сервиса, вообще не подключая интеграционную логику. Описываем источники (в одном Data Service их может быть несколько), пишем запросы, генерируем input/output-маппинг по метаданным — есть кнопка Generate. Стоит заметить: вендор честно предупреждает, что на сложных запросах и нестандартных СУБД могут быть ошибки, которые потребуют ручной корректировки.
Интеграционный движок — это уже классические визуальные сценарии. Точкой входа может быть выставленный наружу SOAP/REST API, файловый каталог, FTP/SFTP, JMS, Kafka; в версии 2.0 добавились gRPC, MCP, коннекторы к ИИ-моделям (OpenAI API, Gigachat API, Ollama's API), интеграция с внешним Vault (Hashicorp/Deckhouse Stronghold, StarVault), адаптер 1С. Дальше на полотне формируется последовательность обработки сообщения.
Набор обработчиков стандартный и довольно полный: маршрутизация, switch, фильтры, валидация по XSD и JSON-схемам, протоколирование, работа со свойствами и заголовками, вызов внешних сервисов, вызов Java-классов и внешних команд системы, EJB, скриптовые языки, трансформации (XQuery, XSLT, FastXSLT, JSON-трансформеры), кэширование, компоненты прямой работы с БД, троттлинг, транзакционность с явными start/suspend/commit/rollback, распараллеливание (iterate и for-each) с последующей сборкой результата агрегатором, аутентификация через OAuth и NTLM.
Повторяющиеся куски логики можно вынести в именованные последовательности и вызывать из разных мест. В любой точке доступно переключение в исходный код — внутри все хранится в XML, так что поправить что-то копипастом никто не мешает.
Отдельно отмечу промежуточные хранилища сообщений, куда можно сохранять файл, JMS-очередь, что-то еще. Разработчику не нужно думать над сериализацией объекта или над структурой таблицы под сложный объект, хранилище само решает эти вопросы. Далее к хранилищу привязываются процессоры, которые эти сообщения разбирают.
Коннекторы
Базовый набор протоколов в коробке: TCP, HTTP/HTTPS, FTP/SFTP, MQTT, REST/SOAP, JMS, Kafka, RabbitMQ, ActiveMQ, JDBC к основным СУБД, gRPC, MCP. Форматы обмена — XML, JSON, текстовые файлы, бинарные данные.
Дополнительно идут коннекторы, расширяющие функциональность: Kafka (базово шина умеет читать из топика, коннектор добавляет инициализацию пула, публикацию и чтение прямо в середине процесса, а не только на старте), расширенная работа с файлами (листинг директории, чтение атрибутов), Consul, Redis, CSV, коннекторы к Inpolus Data и Inpolus Scheduler, а также вспомогательный с хэшированием и генерацией UUID — набор функций, которые вендору понадобились на проектах. Коннекторы поставляются в дистрибутиве шины и описаны в документации.
Свои коннекторы можно писать через Java SDK, причем это может делать не только вендор, но и интегратор или сам заказчик.
Загружаются коннекторы один раз в админку экземпляра, после чего приложения при развертывании видят их и используют.
SAP
В коробке есть встроенный адаптер, для работы нужно доложить библиотеки SAP JCO. Работает по BAPI/RFC и IDoc, ABAP-прокси пока не поддерживается. Работоспособность подтверждена пилотом с Объединенной металлургической компанией, причем заказчик самостоятельно разворачивал и настраивал адаптер.
1С
Начиная с версии 2.0 имеется адаптер 1С, который позволяет настраивать интеграцию прямо в интерфейсе 1С. Для простых сценариев обмена его достаточно, для более сложной логики есть возможность после приема из 1С или до передачи в 1С дополнить интеграционную логику любыми действиями средствами визуальной разработки шины.
Пару лет назад вендор прошел сертификацию «1С:Совместимо»: сделали несколько тестовых сценариев обмена — чтение и запись файлов, вызов SOAP- и REST-сервисов в обе стороны, работа с объектами Enterprise Data по загруженным XSD-схемам с валидацией входящих сообщений. Адаптер 1С на текущий момент не прошел сертификацию на совместимость.
Реестр сервисов Inpolus Registry
Ключевая идея: в едином месте вести метаданные по всем интеграционным сервисам предприятия, чтобы не искать ответы по коду, ТЗ и головам. На карточке сервиса - уникальный идентификатор, наименование, версия, статус жизненного цикла (аналитика, разработка, тестирование, эксплуатация), требования к разработке или ссылки на внешнюю документацию, ответственные и их контакты, теги.
Там же описываются источники данных: из какой системы что достаем, JSON, XML, SQL-запрос. Описание объектов можно сгенерировать автоматически по метаданным запроса, XSD-схемы для входных и выходных объектов формируются автоматически. Аналогично описываются приемники, соответствие полей источника и приемника, если они называются по-разному, и дополнительные соединения — на случай, когда после записи в целевую систему нужно дернуть еще какой-нибудь обработчик.
Статус жизненного цикла сейчас меняется руками. API для автоматизации есть, но, как показывает практика, им не пользуются.
Менеджер сценариев Inpolus Scheduler
Еще один полезный сервис, в зарубежной классификации — Enterprise Scheduler. Что умеет: расписания по cron-выражению или простому интервалу, событийные запуски (внешний REST-вызов в сервис менеджера или сообщение в топике Kafka), приоритизация заданий по критичности, параметризация вызова, параллельное исполнение с настройкой степени параллелизма, таймауты, политики обработки ошибок с максимальным количеством повторов, настраиваемый срок жизни истории по каждому сценарию отдельно.
По каждому заданию доступен журнал: что происходило с источником, что с приемником, временные параметры, переход в детальный протокол исполнения по заданиям и подзаданиям. Оттуда же переход в Graylog и Jaeger.
Универсальный сценарий: интеграция без разработки
В шине есть разработанный вендором универсальный сценарий, по факту обычный визуальный сценарий, который умеет сам читать описание из реестра и выполнять то, что там написано. Плюс к нему универсальный коннектор.
Работает это следующим образом: аналитик описывает в реестре источник, приемники, у каждой системы может быть свой формат объекта и свой маппинг. Описание автоматически прилетает в менеджер сценариев, там задается расписание, например раз в полчаса. Дальше менеджер запускает универсальный сценарий, тот по имени достает описание из реестра, ходит в базу, формирует объект и кладет его в топик Kafka, откуда подписчики (по одному на каждого получателя) параллельно разбирают сообщение и пишут каждый в свою систему.
Программировать при этом не нужно вообще ничего — ни кода, ни хранимых процедур. Более того, вспомогательные объекты создаются автоматически: когда в реестре описывается система типа «база данных» с параметрами подключения, в шине автоматически создается соответствующий источник данных; когда описываются получатели — автоматически создаются точки входа Kafka со слушателями. Руками не делается ничего.
На практике универсальный сценарий закрывает 85–90 % интеграционных потоков. Оставшиеся 10–15 % приходятся на более сложные случаи: многоэтапную обработку данных в нескольких системах, шифрование, нестандартную маршрутизацию, сложную логику трансформации и тому подобное.
Разработка, сборка и деплой
В среде разработки есть отладка: точки прерывания, запуск в режиме отладки, просмотр содержимого основного сообщения и контекстных переменных на каждом шаге.
Готовый проект выгружается в композитное приложение, по сути ZIP-архив с XML внутри. Галочками отмечается, какие объекты проекта нужно включить в выгрузку.
Проект — обычный Maven-проект, все хранится в Git. Есть Maven-плагин, который делает сборку, получает архив и автоматически его деплоит. Для GitLab есть шаблоны CI-скриптов.
Приложения версионируются: можно загрузить несколько версий и переключаться между ними одним нажатием. Если новая версия что-то сломала — вернулись на предыдущую.
В админке экземпляра можно провалиться внутрь развернутого приложения и посмотреть его содержимое, в том числе последовательности в визуальном виде и исходный код. Можно даже поправить код в случае критического инцидента, но потом все равно лучше пройти штатный цикл: исправление, коммит, сборка, тест, установка.
Администрирование
Админка сейчас встроена в каждый экземпляр шины и поднимается вместе с ним. Единый центр управления находится в разработке.
Что есть в админке: пользователи и роли с правами на конкретные объекты, локальное хранилище пользователей (файл или база данных) с возможностью подключить внешнее, работа с Java keystore и сертификатами, настройки журналирования с применением онлайн без перезапуска, источники данных с настройкой пулинга.
Серверные источники данных — удобная штука: вместо описания подключения в среде разработки заводим именованный источник на сервере, а в сценарии ссылаемся на имя.
Есть логи аудита: кто заходил, кто что задеплоил, ошибки входа. Лог можно передавать в Graylog. Просмотр протоколов напрямую в админке убрали, чтобы анализ больших логов не сказывался на производиельности.
Масштабирование и отказоустойчивость
Кластер строится так: поднимается несколько экземпляров с единой базой данных и общим файловым хранилищем — на практике NFS или GlusterFS. Когда в одном экземпляре загружается приложение или создается источник данных, через общую файловую систему это автоматически появляется на всех остальных нодах. Админка при этом за балансировщиком.
Если это не кластер, а просто несколько отдельных экземпляров, никакой магии не будет: созданное в одном месте останется в одном месте, даже если вы ходите через балансировщик.
Менеджер сценариев масштабируется горизонтально за счет запуска нескольких экземпляров с автоматическим распределением выполняемых заданий.
Мониторинг и траблшутинг
Мониторинг — Prometheus и Grafana, есть набор шаблонных дашбордов, с которых можно стартовать, при необходимости доработать.
Дашборды двух уровней. Инфраструктурный показывает все элементы контура в едином виде — кластер шины, кластер Kafka, Redis, Consul, Elasticsearch под Jaeger, Graylog — с возможностью провалиться в детали вплоть до Java-показателей конкретного экземпляра. Прикладной по менеджеру сценариев показывает, сколько сценариев выполнялось, скорость выполнения, текущие проблемы, ошибки, поднявшиеся алерты и статистику с детализацией по каждому сценарию.
Есть также шаблонные настройки/механизмы алертов из Prometheus на электронную почту, Telegram, в версии 2.0 добавлена интеграция с МАКС.
Протоколирование — Graylog, куда пишут все компоненты платформы. Поиск по времени, тексту и вспомогательным полям.
Трассировка — OpenTelemetry и Jaeger. По каждому запуску видно каждый шаг исполнения: какой обработчик отработал, с каким названием, сколько времени занял. Разумеется, на проде трассировку нужно включать очень аккуратно, она серьезно нагружает систему.
Производительность
Сценарий — внешний клиент шлет REST-запросы, шина принимает, трансформирует в формат бэкенда, вызывает его, получает ответ и возвращает обратно; бэкенд быстрый, единицы миллисекунд, его работой можно пренебречь. Тестировалась на одном экземпляре шины, heap 2 ГБ, 2 ядра примерно по 2 ГГц. Такая конфигурация держала около 600 запросов в секунду.
На реальном проекте через платформу проходит более 4 миллионов сообщений размером от 500 байт до 10 мегабайт в сутки.
Для каких компаний применимо
Вендор активно работает с крупным энтерпрайзом: металлургия, финансовый сектор, логистика, транспорт. Продукт и позиционирование заточены туда же. Малый и средний бизнес — не целевая аудитория.
Примеры кейсов
- Магнитогорский металлургический комбинат. Самое крупное внедрение платформы: около 1500 сценариев, порядка 4 миллионов сообщений в сутки.
- «Астрос Лоджистикс». Компания из сферы логистики, внедрение выполняли партнеры вендора.
Количество внедренных проектов
Публично подтвержденных внедрений два.
Требования к ПО
Серверная часть — Java-приложение на Java 11, работает на любой ОС с поддержкой Java. Развертывание — архивом, в Docker или в Kubernetes. Есть сертификаты совместимости с Astra Linux Special Edition, РЕД ОС и «Альт».
Ценообразование
Лицензии
Лицензируются процессорные ядра. Никаких других ограничений нет: ни по количеству сообщений, ни по количеству разработчиков, ни по количеству процессов и сценариев.
Два варианта лицензии: бессрочная с включенной поддержкой на год либо подписка на год. По окончании года бессрочную лицензию можно продолжать использовать, но обновления и устранение инцидентов потребуют продления поддержки; подписку нужно продлевать или прекращать использование.
Стоимость вендор не раскрывает — все под NDA, включая порядок цифр.
Поставка только on-prem. Облачного варианта или размещения на мощностях вендора нет.
Поддержка
По бессрочной лицензии первый год поддержки включен, дальше 25% от стоимости лицензии в год.
Наличие триал-версии, условия получения
Триал предоставляется на три месяца, при заинтересованности можно продлить. Выдаются дистрибутивы, триальная лицензия и контакт технического специалиста, который отвечает на вопросы.
Наличие версии для preprod- и test-окружений
Отдельного типа лицензии для непродуктивных сред вендор не выделяет, лицензирование во всех контурах идет по ядрам.
Наличие открытой документации
Документация открытая, на сайте по всем трем продуктам.
Плюс встроенная помощь в среде разработки и готовые примеры проектов: при первом входе можно развернуть шаблонный проект, который сам создаст в проекте пояснения, что нужно доделать и как его запустить.
Наличие обучения
Обучение бесплатное. Изначально делалось для партнеров, сейчас доступно и заказчикам, если они хотят обучить своих специалистов.
Формат: 2–3 дня онлайн в зависимости от группы и от уровня подготовки участников. Есть готовый учебный сценарий, структура базы, описанный процесс, разработанный интеграционный проект и документ, который пошагово проходится по разработке. Вендор показывает, участники параллельно делают то же самое у себя.
По итогам обучения проходит сертификация в форме тестирования.
Партнерская сеть
У компании есть партнеры, которые уже внедряли продукт. В целом, разработчики открыты для сотрудничества и планируют сосредоточиться на улучшении продукта.
Наличие публичной дорожной карты развития продукта
Подробная дорожная карта есть на сайте компании. Релизный цикл — раз в полгода.
Над продуктами платформы работает порядка 20 разработчиков.
Информационное сопровождение (упоминание в СМИ, рейтингах, наличие комьюнити)
В сети можно найти несколько материалов и упоминаний, посвященных Inpolus ESB. В основном это статьи, связанные с самым крупным кейсом, — внедрением для ММК.
Заключение
Плюсы:
- Набор из хорошо интегрированных сервисов: реестр сервисов, планировщик, объектное хранилище.
- Универсальный сценарий и универсальный коннектор. Возможность закрыть 85–90 % типовых интеграций декларативным описанием в реестре, без единой строчки кода, это хорошо.
- Зрелая команда: больше 15 лет интеграционных проектов на зарубежных платформах и опыт миграции с них. Как утверждает вендор, кейс по внедрению на Магнитогорском металлургическом комбинате — самый крупный проект по миграции как инфраструктуры, так и прикладных интеграционных сценариев с зарубежной интеграционной платформы. Метрики проекта: 1500 интеграционных сценариев, порядка 6 млн сообщений в день по состоянию на август 2026 года, больше 100 подключенных смежных систем.
- SAP-адаптер в коробке (IDoc, BAPI/RFC).
- Адаптер 1С появился с версии 2.0.
- Открытая документация, опубликованная дорожная карта, бесплатное обучение с сертификацией.
- Нормальный процесс разработки: Maven-проект, Git, плагин сборки, шаблоны для GitLab, версионирование приложений с откатом на предыдущую версию.
Минусы:
- Публичных внедрений всего два.
- Стоимость целиком под NDA, вплоть до порядка цифр. Сравнить с другими решениями невозможно.
- Java 11 и Eclipse в качестве базы среды разработки — не то, что хочется видеть сегодня. Перенос на IntelliJ IDEA идет, но не закончен.
- Единая админка в разработке, ETL в разработке. Часть заявленной целостности платформы пока в планах.
Если у вас крупный ландшафт, разрозненные шедулеры и хроническая проблема с тем, что никто не знает, какие интеграции вообще существуют, продукт достоин внимания.
И, как обычно, общая рекомендация: прежде чем делать выводы, сделайте пилот на триал лицензиях, пощупайте своими руками, как это работает.
В статье отражена моя субъективная точка зрения, у которой нет цели нанести ущерб деловой репутации создателям этого продукта.
Вступайте в сообщество в Телеграме «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.
