Наводим порядок в интеграциях: как девелоперам решить свои задачи с помощью ESB

Такое разнообразие требует порядка в ИТ-ландшафте. К тому же могут возникать нетиповые задачи, которые сложно решить стандартным набором инструментов, например, надо устранить дубли при обмене данными из разных систем. Сергей Скирдин, технический директор ИТ-интегратора «Белый код», рассказал, чем может быть полезна шина данных (ESB) и что сегодня предлагает российский рынок. А также поделился критериями выбора продукта.

Во многих организациях интеграции реализованы по архитектуре «точка-точка» или на базе брокеров сообщений, таких как RabbitMQ или Apache Kafka. Это создает системные сложности.

ESB (Enterprise Service Bus, дословно переводится как «корпоративная сервисная шина») подходит как для новых интеграций, так и для миграции с архитектуры «точка-точка» и брокеров. Шина данных позволяет перейти от разрозненных, трудозатратных и нестабильных интеграций к централизованной, управляемой архитектуре взаимодействия между системами. Это особенно критично для:

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

Ключевые преимущества:

• Единая точка управления интеграциями — сценарии, логика, мониторинг.
• Мониторинг и диагностика — логирование, трассировки.
• Импортозамещение — большинство продуктов на отечественном рынке включены в реестр отечественного ПО.
• Коннекторы, в том числе к 1С — производительность и простота настройки.

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

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

Задача: настроить интеграцию между базами 1С и CRM-системой «Первая Форма», исключив при этом дубли.

В инфраструктуре организации 12 баз «1С:ЗУП» и CRM-система на веб-платформе. Между системами активный обмен: множеству справочников требуются обновления данных. Однако компания столкнулась с проблемой дублей при обмене данными между базами 1С и CRM. Дело в том, что базы 1С никак между собой не связаны, и те же физлица при приеме на работу заводятся в каждую базу со своим идентификатором. При стандартной синхронизации из 1С в CRM создавались повторяющиеся записи по одним и тем же объектам. Это приводило к искажению информации, усложняло учет и мешало работе. Необходимо было реализовать механизм, который исключил бы появление дублей при передаче данных.

В пилотном проекте, чтобы протестировать вариант решения задачи, настроили обмен между 3 базами 1С и CRM-системой. Это 12 различных объектов (справочники, регистры, документы). Для интеграции использовали DATAREON Platfrom. В Платформе есть сервис «Банк данных» для хранения пользовательских данных на MSSQL или PostgreSQL, и именно его мы задействовали, чтобы решить проблему дублей.

Для начала создали таблицу в банке данных, где хранится соответствие идентификаторов между системами.

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

При отправке объекта (например, физлица) DATAREON обращается к банку данных и проверяет с помощью таблицы соответствий Банка данных, существует ли уже идентификатор этого объекта в системе-приемнике. Если идентификатор найден, он подставляется в объект, и дубли не создаются. Если идентификатора нет, выполняется сверка по комбинации ключевых полей (ФИО, дата рождения и др.), после чего новый объект добавляется в банк данных. Благодаря этому устраняются дубли на уровне Платформы.

Так схема для обработки реквизитов физического лица выглядит в DATAREON Platform.

Технически решение реализовано через стандартный функционал DATAREON: типы данных, обработчики и схемы с блоком «алгоритм». В рамках схемы предусмотрена логика поиска и записи соответствий в банк данных. Для обмена использовалась база MS SQL.

Это один из примеров использования интеграционных платформ и ESB-решений для решения внутренних задач компании. Сегодня на отечественном рынке много подобных продуктов. Чтобы ИТ-директорам было проще разобраться, Сергей Скирдин, технический директор ИТ-интегратора «Белый код», провел исследование и разобрал основные решения и их возможности для бизнеса.

Работа над исследованием началась в 2024 году. Про многие решения информации было совсем немного, а большинство рейтингов и статей оказались предвзяты или написаны самими вендорами. Не хватало независимого обзора от технического специалиста, чтобы помочь архитекторам, ИТ-директорам и CIO принимать взвешенные и обоснованные решения.

Из Реестра отечественного ПО было отобрано 43 решения, затем компании-разработчики получили запросы с предложением поучаствовать в открытом обзоре.

Один из главных принципов исследования — участие для вендоров бесплатное. Все расходы по сбору, обработке и распространению информации взял на себя ИТ-интегратор «Белый код». Это обеспечивает независимость и позволяет объективно оценивать каждое решение без коммерческого влияния.

Удалось провести встречи с разработчиками 20+ платформ. Для 10 решений были созданы подробные обзоры, которые включают:

• технологический стек;
• функциональные возможности:

- язык, на котором реализуются внутренние функции преобразования и маршрутизации;

- коннекторы;

- поддержка контрактов (проверка корректности сообщений);

- масштабирование и отказоустойчивость;

- мониторинг и траблшутинг;

• для каких компаний применимо (отрасли, масштабы);
• примеры кейсов;
• количество внедренных проектов;
• требования к ПО;
• ценообразование;
• наличие пробной версии и условия получения;
• наличие версии для preprod- и test-окружений;
• наличие открытой документации;
• наличие обучения;
• партнерская сеть;
• наличие публичной дорожной карты развития продукта;
• информационное сопровождение (упоминание в СМИ, рейтингах, наличие комьюнити).

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

Обзор распространяется бесплатно и помогает понять рынок, а также сэкономить время.

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

1. Высокая стоимость переключения. Замена шины — это фактически перестройка всех интеграций. Поэтому важно выбрать решение, которое будет развиваться и поддерживаться долгие годы, желательно не только за счет вашей компании.
2. Влияние на скорость бизнеса. Правильно выбранная шина сокращает time-to-market по новым продуктам и снижает издержки поддержки.

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

Для начала формируем шорт-лист.

Положительные признаки

• Вендор работает на рынке давно, имеет устойчивую репутацию.
• Наличие публичной дорожной карты развития и регулярных релизов.
• Широкая партнерская сеть интеграторов, а не только внедрение силами вендора.
• Наличие обучающих программ, сертифицированных курсов и документации.
• Возврат в open source своих доработок снижает риск устаревания ядра.
• Примеры внедрений в различных отраслях.

Отрицательные признаки

• Внедрение силами вендора.
• Зависимость продукта от одного ключевого заказчика.
• Закрытое ценообразование («цена по запросу»).

Технологический стек

От того, что «под капотом» ESB, зависит, каких специалистов вам придется нанимать. Например, у вас преимущественно 1С или Java, для одного и второго варианта есть разный набор платформ.

Команда

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

Бюджет

Да, это важно. Нередко, если посчитать стоимость владения (разработка, поддержка, квалификация команды), разница между самым доступным вариантом и более дорогими не так велика. И лучше думать на перспективу.

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

Если вы сейчас выбираете интеграционную платформу, советуем:

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

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

Телеграм-канал DigitalDeveloper
Подпишитесь, чтобы читать новости, кейсы, исследования и обзоры IT-технологий на рынке недвижимости.