Обзор шины данных DataHUB

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

С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками около двадцати разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина.

Ссылка на продукт: https://1dh.ru/

Документация: https://docs.1dh.ru/

О компании: DataHUB это авторский проект разработчика Кристины Барбиной. Случай для рынка нетипичный: почти все решения, которые я разбирал, делают либо крупные ИТ-компании, либо системные интеграторы, а здесь один архитектор, который сам пишет бэкенд, и небольшая команда вокруг, закрывающая дизайн, сайт и маркетинг. За плечами около двадцати лет разработки на платформе 1С.

История продукта началась с проекта интеграции крупного вуза: приёмная кампания, огромные потоки документов от абитуриентов, интеграция сайта с бэк-офисом на 1С и обмен с Минобрнауки, всё это в очень сжатые сроки и практически без права на ошибку. Транспорт там строили на RabbitMQ, и после этого проекта идея собственной шины уже не отпускала.

Отдельно отмечу тон встречи. Кристина честно признает, что продукт находится на стадии MVP, что клиентов пока два, что маркетинга нет и что тарифы вполне могут поменяться, как только появится обратная связь от рынка.

Позиционирование

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

Ядро позиционирования именно 1С. Разработчик формулирует это так: 1С в центре, всё остальное вокруг, включая BI, выгрузки, Битрикс и любые другие точки, куда нужно отправлять данные или откуда их получать. Конкурировать напрямую с DATAREON или «1С:Шиной» вендор не собирается, считая, что сегментация на рынке другая и у каждого продукта свой заказчик со своим бюджетом.

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

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

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

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

RabbitMQ выбран осознанно вместо Kafka. Аргумент: для задач интеграции корпоративных систем Rabbit закрывает все требования, при этом заметно проще в эксплуатации и менее требователен к ресурсам. Единственный сценарий, где Kafka реально выигрывает, это повторное проигрывание очереди сообщений после восстановления базы из бэкапа, но на практике такое восстановление в автоматичкском режиме все равно нигде не применяется.

Функциональные возможности

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

Маршрут связывает класс сообщения, систему-источник и систему-получателя. Один класс может иметь несколько маршрутов, то есть работает fan-out на несколько систем. Маршруты направленные, для двустороннего обмена нужны два маршрута. Отдельного языка или DSL для маршрутизации нет, всё настраивается интерактивно в личном кабинете и автоматически прописывается в RabbitMQ, консистентность настроек между интерфейсом и брокером поддерживается платформой. Новый получатель добавляется маршрутом, систему-источник при этом трогать не нужно.

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

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

Гарантия доставки и идемпотентность

Модель доставки at-least-once, сообщение дойдёт минимум один раз. Персистентные очереди переживают перезапуск шины и временную недоступность получателя. Разработчик формулирует гарантию жёстко: сообщение уйдёт от отправителя и дойдёт до потребителя при любых падениях инфраструктуры.

Обратная сторона at-least-once это необходимость идемпотентности на стороне приёмника. Шина передаёт стабильный идентификатор, дедупликацию выполняет клиентский модуль получателя. В 1С-адаптере это уже реализовано.

Автоматической переотправки сообщения со стороны отправителя нет. Руками переотправить повторно можно, но это скорее история этапа отладки, чем продуктивного контура.

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

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

Коннектор к 1С

Модуль для 1С поставляется в двух вариантах: подсистемой через объединение конфигурации (.cf) или расширением (.cfe). На практике почти все выбирают подсистему, и на то есть техническая причина: при объединении подписка вешается на все объекты сразу и коротким вызовом на миллисекунды определяет, нужно ли регистрировать объект к обмену. В расширении подписаться на всё подряд нельзя, там придётся руками отмечать галочками нужные объекты.

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

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

Чего в 1С-коннекторе нет, так это централизованной отправки кода обработчиков из шины в базы, придётся зайти в каждую базу и выполнить обновление конфигурации.

Транспорт между 1С и шиной

1С общается с шиной по HTTPS через long polling. Все вызовы со стороны 1С исходящие, публиковать наружу http-сервисы не нужно вообще. 1С держит соединение с долгоживущим тайм-аутом, раз в две минуты тайм-аут истекает и соединение переустанавливается. Как только в очереди появляется сообщение, модуль обмена на бэкенде сразу отправляет пакет в 1С.

После приёма 1С отправляет подтверждение о том, что сообщение получено и записано в базу, только после этого оно удаляется из очереди. При этом параллельно уже уходит следующее сообщение, то есть конвейер не блокируется на подтверждениях.

Для облачной модели это правильная архитектура: заказчику не нужно выставлять 1С наружу.

Внешние системы

Для всего, что не 1С, есть единый REST API и описанная методология построения адаптера. В документации есть отдельный раздел с концепциями модуля интеграции: как модуль должен выглядеть, идеология интеграции, требования к нему. Транспортное API описано через OpenAPI.

Из готового: модуль s3-proxy для файлового хранилища и отдельный адаптер для мобильной платформы 1С на базе типового 1С-адаптера. Битрикс делали кастомным модулем, который повторяет ту же логику, что и в 1С: свои таблицы с данными, свои таблицы с пакетами, свой цикл обработки. Также был опыт выгрузок в BI и PimCore.

Готовых специализированных коннекторов к CRM, WMS, ERP или маркетплейсам сейчас нет. В планах у разработчика подход, который мне кажется здравым: не заставлять каждого заказчика реализовывать таблицы и алгоритмы у себя, а делать автономные «жирные» адаптеры, которые ставятся рядом с системой, общаются с ней на её языке и её моделью данных, а с шиной по API. По сути, коробочный модуль под каждую популярную систему.

Поддержка контрактов и валидация

Шина автоматически проверяет наличие зарегистрированного класса сообщения: если класса нет, отправитель сразу получает ошибку. Payload при этом не валидируется, ссылки между сущностями шина тоже не проверяет.

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

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

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

Типовая поставка это один сервер и Docker Compose. При росте нагрузки предусмотрены кластер RabbitMQ и вынос Exchange-сервиса в отдельный деплой. Монолит бэкенда потенциально разделяется на модули (админка с авторизацией, обмен, модуль работы с S3), часть этой работы уже сделана, но, по словам разработчика, до конца не упакована в продажу. Хелсчеки и метрики туда же: реализованы, но доводить их до продуктового состояния без реального заказчика вендор считает преждевременным.

Заявленный архитектурный диапазон от десятков сообщений в сутки до сотен сообщений в секунду, формальный SLA согласуется индивидуально.

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

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

Мониторинг и траблшутинг

Централизованного журнала доставки сообщений на стороне шины пока нет, он в разработке.

Что есть сейчас: health-check через endpoint'ы nginx, Spring Actuator и Docker healthcheck по контейнерам; метрики через Micrometer в Prometheus-совместимом формате; RabbitMQ Management API и статистика PostgreSQL. Всё это подключается к стеку заказчика, будь то Zabbix, Prometheus или Grafana, но готового стека мониторинга в поставке нет. Статусы обработки сообщений видны в клиентском модуле, например на отдельной странице в 1С.

То есть чтобы понять, что происходит с обменом целиком, придётся пробежаться по всем базам. Разработчик планирует прикрутить глобальный трекинг сообщений с точными статусами и нормальный дашборд, собираемый через Grafana, но пока это планы.

Контуры разработки, тестирования и продуктива

Платформа поддерживает три отдельных контура: разработку, приёмочное тестирование и продуктив. Никакого жёсткого ограничения именно на три контура нет, это скорее сложившаяся практика, стендов может быть сколько угодно.

Для каких компаний применимо

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

Примеры кейсов

Промышленный производитель аккумуляторных батарей. В рамках перехода с западной ERP на «1С:ERP» DataHUB стал единой шиной для BI, PIM, CRM и MDM.

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

Обе инсталляции on-premise. Названия и логотипы клиентов вендор пока не раскрывает.

Количество внедренных проектов

Два внедрения на текущий момент.

Требования к ПО

Со стороны 1С: платформа «1С:Предприятие» 8.3.25 или выше, управляемые формы, работа подтверждена на БСП 3.5. Поддерживаются клиент-серверный и файловый режимы. Модуль встраивается объединением конфигурации (.cf) или через расширение (.cfe).

Серверная часть разворачивается на Linux через Docker Compose.

Ценообразование

Лицензии

Доступны две модели: SaaS-подписка и бессрочная коробочная лицензия.

Ограничения тарифов идут по количеству интегрируемых систем и количеству сущностей: например, «Стандарт» это пять систем и двадцать сущностей.

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

Внедрение оплачивается отдельно, есть градация по типовым проектам.

Поддержка

Техническая поддержка составляет 12,5% от стоимости внедрения в год. В неё входят онбординг, устранение инцидентов, резерв бесплатных часов, связь по электронной почте, телефону и через Telegram-бот. Обновления идут по подписке в рамках техподдержки. Формальный SLA согласуется индивидуально.

Наличие пробной версии и условия получения

Отдельной бесплатной пробной версии нет. Вместо неё предлагается пилотный проект с фиксированной стоимостью 350 000 рублей: две базы 1С, до пяти сущностей, три месяца тарифа «Энтерпрайз». Стоимость пилота вычитается из полного внедрения.

Наличие версии для preprod- и test-окружений

Три контура поддерживаются, отдельно они не лицензируются.

Наличие открытой документации

Техническая документация открыта и опубликована на docs.1dh.ru. Внутри архитектура, концепции, развёртывание, описание модуля интеграции и модуля для 1С, идеология интеграции, требования к адаптерам, транспортное API и разделы диагностики.

Наличие обучения

Готовых учебных материалов пока нет, обучение партнёров запланировано.

Партнерская сеть

Партнёрская программа находится в разработке. Основным каналом продаж вендор видит франчайзи 1С и интеграторов. Условия сотрудничества публично не раскрываются.

Наличие публичной дорожной карты развития продукта

Публичной дорожной карты нет, продукт на этапе MVP. Ближайшее заявленное направление это централизованный трекинг сообщений.

Информационное сопровождение (упоминание в СМИ, рейтингах, наличие комьюнити)

Своего комьюнити нет, в отраслевых рейтингах продукт не представлен, упоминаний в СМИ нет. Основные публичные каналы сейчас это сайт и открытая техническая документация. В реестр отечественного ПО вендор подаётся, документы собираются.

Заключение

DataHUB это шина под 1С, сделанная человеком, который двадцать лет писал интеграции на 1С и хорошо понимает, где именно там больно.

Плюсы:

• аккуратная работа с 1С: подписки на объекты, регистр внешних идентификаторов, обработчики не вмешиваются в конфигурацию и не мешают разработке;
• транспорт по HTTPS через long polling, все вызовы из 1С исходящие, публиковать сервисы наружу не нужно, обмен работает на триггерах без расписаний;
• открытая и подробная техническая документация;
• в коробочной поставке передаётся исходный код с правом модификации;
• контуры разработки и тестирования не лицензируются отдельно;
• невысокие требования к инфраструктуре, установка через Docker Compose.

Минусы:

• всего два внедрения, продукт на стадии MVP, и фактически за ним стоит один разработчик, это главный риск для заказчика;
• нет централизованного журнала доставки и мониторинга, состояние обмена приходится смотреть по базам;
• нет визуального маппинга, схем данных и трансформаций внутри шины (для кого-то это плюс);
• из коннекторов только 1С, «1С:Мобильная платформа» и S3, под остальные системы адаптер придётся писать;
• продукта пока нет в реестре отечественного ПО;
• нет комьюнити, обучения, партнёрской сети и публичной дорожной карты.

Если коротко: технологически DataHUB выглядит интересно, а 1С-часть проработана сильнее, чем у ряда более крупных решений. Но продукт пока находится на очень ранней стадии развития: всего два внедрения, нет зрелой экосистемы, а ключевая разработка держится фактически на одном человеке.

Сейчас DataHUB особенно нужны ранние последователи — заказчики и партнёры, которые готовы работать с молодым продуктом, давать обратную связь и вместе с разработчиком проходить этап его становления.

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

В статье отражена моя субъективная точка зрения, у которой нет цели нанести ущерб деловой репутации создателям этого продукта.

Вступайте в сообщество в Телеграме «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.