Digital Q.Integration — российская интеграционная платформа (ESB) нового поколения, предназначенная для быстрого объединения разнородных корпоративных приложений и внешних сервисов в едином пространстве. Платформа использует микросервисную архитектуру, поддерживает широкий спектр протоколов и стандартов, обеспечивает высокую производительность, надежность и централизованный контроль за потоками данных.
Обзор Digital Q.Integration
За формулировкой «коннектор к 1С» у разных интеграционных платформ скрываются принципиально разные подходы. В одном случае внутрь базы устанавливается расширение или полноценная подсистема, которая регистрирует изменения и управляет очередями. В другом шина вообще не вмешивается в конфигурацию и работает с 1С через стандартные интерфейсы.
Digital Q.Integration от «Диасофт» относится ко второму варианту. Ничего устанавливать в конфигурацию 1С не требуется: взаимодействие построено через стандартный OData-интерфейс. При этом вокруг OData в платформе сделан отдельный сервис-коннектор со своей очередью, обработкой ошибок, повторами и логикой работы со сложными объектами,вся интеграционная логика вынесена за пределы 1С.
|
Параметр |
Как реализовано |
|---|---|
|
Способ взаимодействия |
OData |
|
Установка на стороне 1С |
Не требуется, нужно опубликовать стандартный OData-интерфейс |
|
Инициатор обмена |
Digital Q.Integration |
|
Модель получения данных |
Pull: шина обращается к 1С по расписанию или по событию интеграционного процесса |
|
Формат |
JSON или XML, предпочтительно JSON |
|
Синхронность |
OData-запросы к 1С синхронные, сам сервис-коннектор может работать через асинхронную очередь |
|
CDC |
Polling с отбором по дате изменения или другому доступному признаку |
|
Гарантия доставки |
Очередь сообщений, настраиваемые retry, контроль ответа от 1С |
|
Мониторинг |
Общий мониторинг интеграционных сервисов Digital Q.Integration |
|
1С:Fresh |
Практического опыта на момент интервью не было |
|
Реальная нагрузка |
На внутреннем проекте - миллионы обращений за неделю, отдельные ответы 1С размером 20–50 МБ |
Основной принцип Digital Q.Integration — для каждой подключаемой системы создаётся отдельный сервис, инкапсулирующий особенности работы с ней. В случае 1С таким сервисом становится OData-коннектор.
На стороне 1С никакого кода Digital Q.Integration нет. Достаточно опубликовать стандартный OData-интерфейс и предоставить шине параметры подключения.
При этом внутри платформы есть два уровня работы с OData.
Первый — непосредственно компонент обращения к OData. Его можно встроить в интеграционный маршрут и выполнить обычный синхронный запрос к 1С.
Второй — полноценный коннектор, построенный вокруг этого компонента. Он добавляет асинхронную обработку входящих заданий, очереди, обработку ошибок, повторные попытки и прикладную логику работы с данными.
Инициатором всегда выступает Digital Q.Integration.
Шина может по расписанию обратиться к 1С и забрать новые данные. Другой вариант — запрос появляется как следствие события во внешней системе: в интеграционный процесс пришло сообщение, для его обработки понадобились данные 1С, после чего маршрут обращается к OData.
Запись работает аналогично: Digital Q.Integration формирует запрос и отправляет его в 1С.


Сам вызов 1С синхронный: коннектор отправляет OData-запрос и ждёт результат. Но задания внутрь сервиса-коннектора могут поступать асинхронно через брокер. Коннектор принимает их в очередь и обрабатывает с той производительностью, которую обеспечивает выделенный ему экземпляр или набор реплик.
Если же требуется настоящий синхронный запрос-ответ в рамках интеграционного маршрута, можно обратиться к OData-компоненту напрямую, минуя асинхронную обвязку коннектора.
Поскольку внутри 1С ничего не устанавливается, подписок на события и собственного регистра изменений у Digital Q.Integration нет. Чтобы понять, что в базе появились новые или изменённые данные, шина должна сама периодически обращаться к 1С. DataVersion, в текущем подходе Digital Q.Integration не сохраняется, пока не было такой необходимости.
В архитектуре Digital Q.Integration коннекторы различных систем взаимодействуют между собой через универсальные контракты. В результате на вход коннектора 1С может прийти не плоская структура из нескольких полей, а большой композиционный объект.
Например, внутри сделки могут находиться ссылки на документы, контрагента, его адреса и другие связанные сущности.
При записи такого объекта в 1С коннектор разбирает структуру, начиная с наиболее глубоко вложенных объектов. Для каждого элемента выполняется поиск по ключу. Если объект уже есть в 1С, получается его идентификатор; если нет — объект создаётся. После разрешения всех зависимостей записывается верхнеуровневая сущность.
Полноценный коннектор работает через брокер сообщений. Полученные задания остаются в очереди до завершения обработки, а для ошибок настраивается политика повторных попыток.
После отправки данных OData возвращает полноценный ответ с результатом операции. Если удалённая система недоступна или запрос завершился ошибкой, коннектор формирует соответствующий статус и описание ошибки, которое получает инициатор операции.


Состояние 1С-коннектора попадает в общий мониторинг Digital Q.Integration наряду с остальными интеграционными сервисами.
Если при выполнении запроса возникает ошибка соединения, удалённый хост не отвечает или 1С возвращает ошибку обработки, эта информация фиксируется и доступна в общем контуре мониторинга.
С точки зрения 1С техническое подключение выглядит просто: нужно опубликовать OData и настроить права доступа. Объединять конфигурации, устанавливать расширения или снимать типовую конфигурацию с поддержки не требуется.
С точки зрения компетенций команда видит как минимум две роли. Специалист по 1С должен корректно опубликовать и настроить OData. Дальше нужен специалист по Digital Q.Integration — сильный интеграционный аналитик или разработчик, понимающий, как строятся маршруты и контракты внутри платформы.
Готовых маппингов для ERP, УТ, ЗУП или БП сейчас нет. Причина довольно практичная: 1С-системы, с которыми команда работала, были существенно доработаны, поэтому универсальные шаблоны мало помогали.
Коннектор появился относительно недавно. На момент интервью основные реальные сценарии его использования были внутренними проектами «Диасофта»: интеграции 1С с CRM, «Фабрикой данных», аналитическими инструментами, обмен лидами, клиентами и контрагентами.
Коммерческих промышленных проектов у внешних заказчиков, которые участники встречи могли бы привести в качестве референса, пока не было. Зато внутренние проекты дали коннектору довольно серьёзную нагрузку.
В одном из проектов «Фабрика данных» динамически получала из 1С структуру данных, строила на её основании собственную модель, а затем начинала наполнять витрины. За период активной разработки продолжительностью около недели через коннектор прошло несколько миллионов запросов.
Причём отдельные ответы от 1С представляли собой структуры объёмом порядка 20–50 МБ.
Другой интересный проект — двусторонняя интеграция 1С и CRM с продуктовым каталогом. Там потребовалось не только читать и записывать объекты, но и выполнять действия над ними, использовать пагинацию, работать со множеством категорий и со сложными вложенными структурами. Значительная часть возможностей коннектора появилась именно в ходе этого проекта.
Архитектурно коннектор зависит прежде всего от наличия и возможностей стандартного OData-интерфейса конкретной версии 1С.
Практического опыта эксплуатации с 1С:Fresh на момент встречи у команды не было.
Digital Q.Integration выбрал максимально внешний подход к интеграции с 1С. В конфигурацию ничего не устанавливается, не нужны расширения и объединение с конфигурацией поставщика — достаточно стандартного OData.
Вокруг OData появился отдельный сервис с очередью, retry, мониторингом, универсальными контрактами и достаточно развитой логикой работы со сложными вложенными объектами. А для случаев, где вся эта обвязка не нужна, OData-компонент можно использовать непосредственно в интеграционном маршруте.
Главный компромисс такого подхода — отслеживание изменений. Собственной регистрации событий внутри 1С нет, DataVersion не используется, поэтому дельта строится через polling и доступные в прикладном решении признаки изменения.
В статье отражена моя субъективная точка зрения, у которой нет цели нанести ущерб деловой репутации создателям этого продукта.
Вступайте в сообщество в Телеграме «Шины не для машины», там обсуждаем насущные вопросы рынка ESB.
Похожие статьи
Обзор российских ESB-решений
17 подробных технических обзоров на отечественные платформы