Интеграция 1С через ESB: RedMule

О компании и продукте

Интеграционная платформа RedMule — продукт системного интегратора «ГенАйТи». Компания занимается автоматизацией предприятий, встраивает бизнес-сервисы, а также разрабатывает программное обеспечение на заказ.

Ссылка на полный обзор продукта

Обзор RedMule

Подход к интеграции с 1С

Фраза «у нас есть коннектор к 1С» в маркетинговых материалах интеграционных платформ не значит почти ничего. За ней может стоять объединяемая конфигурация, расширение, проприетарное AMQP-приложение или сотня строк на HTTP-сервисах. Мы разбираемся, как коннекторы устроены на самом деле и что это означает для архитектора, который выбирает шину.

RedMule, продукт системного интегратора «ГенАйТи», реализует «толстый» подход: в базу 1С приезжает полноценная конфигурация поставщика со своими справочниками, техническими очередями, регламентными заданиями и программным интерфейсом. По сути это небольшая интеграционная подсистема внутри 1С, которая берёт на себя регистрацию изменений, сериализацию, повторы, статусы доставки и запись входящих объектов. Разговор вёл Андрей Герасимов, бизнес-аналитик «ГенАйТи».

Коротко

Архитектура коннектора

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

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

Кто инициирует обмен: пять сценариев

Инициатором может быть любая сторона.

Отправка данных из 1С, два сценария

1. Push по подписке. Сработала подписка на событие, изменение зарегистрировалось, коннектор сам устанавливает HTTP-соединение с RedMule и отправляет сообщение. Инициатор 1С. Это основной рабочий режим.
2. Ответ на GET-запрос. Внешняя система хочет забрать что-то из 1С прямо сейчас. Запрос через шину приходит на HTTP-сервис коннектора, тот формирует ответ. Инициатор внешняя система. Штатно объект запрашивается по паре «тип объекта плюс GUID», и 1С отдаёт ровно ту же структуру, какая ушла бы при изменении объекта.

Приёмка данных в 1С, три сценария

1. Пассивный приёмник. В коннекторе опубликован HTTP-сервис с REST API, он принимает POST-запрос и пишет пришедший объект или набор записей в базу. Инициатор шина. Это поведение по умолчанию.
2. 1С забирает сама. Коннектор инициирует GET-запрос через RedMule во внешнюю систему, получает данные и записывает их у себя. Инициатор 1С. Вызывается либо из кода через функцию программного интерфейса (тип объекта, отборы, дополнительные параметры), либо по расписанию регламентным заданием. Типовой пример: подтянуть элемент справочника из другой базы 1С.
3. Активный приёмник. Тот случай, когда публиковать HTTP-сервис на стороне 1С нельзя по требованиям безопасности. RedMule не пытается доставить сообщение, а откладывает его в буфер на своей стороне и хранит там; коннектор регламентным заданием периодически забирает накопленное массивом.

Публикация базы на веб-сервере нужна только для сценариев 2 и 3. Если публиковать нельзя, остаются 1, 4 и 5, и этого достаточно для полноценного двустороннего обмена, просто приёмка становится не мгновенной, а с периодом опроса.

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

Структура объекта

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

У данного решения есть и плюсы:

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

И минусы:

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

Минусы решаются механизмом «наблюдателей».

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

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

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

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

Правила обмена на стороне платформы

За конвертацию и маршрутизацию отвечают правила обмена. Нотация, сделана по образу «Конвертации данных 2.0» и дополнена атрибутами, которые нужны шине. Для 1С-команды это плюс: нотация узнаваемая, порог входа ниже.

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

Синхронность, очереди и гарантия доставки

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

Внутри коннектора работают четыре технические очереди: хранилище всех сообщений (глубина по умолчанию 30 дней), очередь отложенной отправки, очередь повторов и запроса статуса и очередь установки статуса объекта.

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

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

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

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

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

Мониторинг и эксплуатация

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

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

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

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

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

Внедрение и настройка

Внедрение начинается с объединения конфигураций: поставка коннектора добавляется к основной конфигурации 1С. Если база будет принимать данные, дополнительно нужно опубликовать HTTP-сервис на веб-сервере.

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

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

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

Готовых шаблонов маппинга под типовые конфигурации нет.

Опыт применения коннектора

Платформа поддерживается с версии 8.3.9. Для 7.7, 8.2 и версий до 8.3.8 существует отдельная поставка с ограниченным функционалом под конкретные задачи. Опыта интеграции с облачной 1С и 1С:Fresh пока нет.

За коннектором более сотни интеграционных проектов, и практически в каждом из них есть 1С и этот коннектор.

Цифры по производительности с реального проекта: на входящих зафиксирован максимум 15 000 сообщений в час (4,2 в секунду) при теоретическом пределе на синтетике около 30 в секунду, на исходящих около 28 000 в час (7,8 в секунду) при пределе около 100 в секунду. Речь о простых объектах на несколько реквизитов, разумеется скорость будет снижаться с ростом сложности объектов.

Типовые кейсы: справочники из УТ в Розницу и обратно, заказы, отчёты о розничных продажах. Самый сложный из реализованных сценариев: база 1 отправляет в базу 2 команду с параметрами отбора, база 2 возвращает список GUID найденных объектов, после чего база 1 по каждому GUID запрашивает сам объект целиком.

Выводы

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

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

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

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