На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Чаще всего в интеграциях мы сталкиваемся с настройкой обмена для баз 1С. Предположим, у нас 8 конфигураций 1С, связанных между собой, и нужно навести порядок. В статье расскажу, как мы придумали снизить стоимость разработки, а также значительно сократить время на рутинные задачи.
Темой интеграций занимаюсь довольно давно, в этом году выпустил первый независимый авторский обзор российского рынка. Об этом много писал на Хабре, например, здесь.
О вебинаре
«Самая опасная муда — муда, которая скрыта и выглядит как необходимая работа».
«Дао TOYOTA»
Этот вебинар был посвящен интеграциям. В первую очередь — интеграциям с 1С, просто потому что их много, и именно в этой области оптимизация дает наиболее заметный эффект. Когда таких интеграций становится десятки и сотни, даже небольшая оптимизация процесса может дать ощутимую экономию времени и ресурсов.
В рамках вебинара мы разобрали, как оптимизировать процесс создания интеграций: автоматизировать типовые этапы, сократить объем ручной работы и сделать результат более предсказуемым при масштабировании.
В этой статье я собрал основные идеи и практические подходы, о которых шла речь. Если хотите посмотреть, как это работает вживую, запросите запись вебинара по ссылке.
Вводная часть
Крупные компании редко начинают с продуманного ИТ-ландшафта. Как правило, за их плечами длинная история развития: в какой-то момент была одна информационная система и одна база данных, затем появилась вторая, третья, пятая, десятая.
Со временем в процессе роста часто происходят слияния и поглощения, и в результате корпоративная ИТ-среда начинает напоминать конструктор, собранный из разных частей. Часть систем досталась от одной компании, часть — от другой, и всё это каким-то образом связано между собой.
На практике такая архитектура обычно выглядит как пучок интеграций: точка-точка, через брокеры, через разные промежуточные механизмы и самописные решения. Каждый обмен когда-то решал конкретную задачу, но в совокупности они образуют сложную и слабо управляемую сеть.
В таких условиях перед командой встает понятная задача — привести этот ландшафт в порядок, настроить интеграцию с шиной данных. А уже шина берёт на себя ответственность за маршрутизацию и передачу сообщений в другие системы.
Как видно на картинке «Как есть» связи между системами уже есть, и мы за основу для реквизитного состава берем список реквизитов, который уже участвует в обмене, и приступаем к интеграции,
Чтобы сделать интеграцию одного объекта, нужно пройти следующие шаги:
Каждый шаг занимает время, а еще время отнимают обратные пунктирные линии. Давайте разберемся, где можно сэкономить.
Создание типов данных в DATAREON
Создание типов в DATAREON не кажется какой-то сложной задачей. Есть визуальный редактор, который позволяет создавать поля, указывать типы.
Все это достаточно просто делается, до тех пор пока не приходит задача сделать такой тип:
На трех скринах поместился не сильно доработанный справочник Организаций ~200 реквизитов, и тут возникают вопросы:
❓Сколько нужно времени, чтобы завести такой справочник?
❓Сколько ошибок будет при ручном вводе?
❓Как не сойти с ума от такой тупой работы?
Мы решили не проверять. Мы спарсили текущие настройки обмена, из метаданных конфигурации получили информацию о типах данных, написали обработку, которая заливает типы данных в DATAREON.
Да, мы потратили кучу времени, на то, чтобы разобраться с текущим обменом, написать парсинг метаданных, сделать интеграцию с API DATAREON, зато процесс заливки данных занимает одну минуту.
За одну минуту мы залили 78 типов данных, 6 685 реквизитов, без единой ошибки, и не сошли с ума от тупой работы, и это тоже важно!
А также, мы получили опыт и инструменты для переиспользования на других проектах.
Переходим к обработчикам.
Обработчики получения данных
В основе обработчика получения данных, как правило лежит запрос, упаковка результата в структуру и отправка в DATAREON.
Чтобы не писать каждый раз обвязку вокруг запроса, мы доработали консоль запросов, добавили в инструменты генератор кода обработчика DATAREON на основании сконструированного запроса.
В результате, разработчику или аналитику достаточно иметь навыки работы с консолью запросов, чтобы сконструировать запрос. Обработка по кнопке выдаст полный текст обработчика, который можно скопировать, вставить в DATAREON, и он будет работать.
Звучит здорово, но все равно, это ручная работа по сборке запросов, не сильно интересная, занимает время. А ещё конфигурации сейчас большие и сложные, а dev окружения на которых ведется разработка не блещут аппаратными ресурсами, поэтому все это занимает кучу времени.
Есть решение. Ранее мы уже собрали реквизитный состав, и типы данных, настал момент для переиспользования проделанной работы. На основании реквизитного состава, с типами данных мы пишем обработку для того, чтобы сгенерировать обработчики получения.
Итог, одна минута и типы данных, вместе с обработчиками загружены в DATAREON.
Обработчики записи данных
Писать данные всегда сложнее, чем читать. Хотелось бы похвастаться, что у нас есть волшебный набор функций, который на входе принимает универсальную структуру и записывает её в DATAREON, но нет… пока нет.
При записи нужно выполнить последовательно ряд действий:
Выставление блокировки обработки сообщения.
Идентификация объекта.
Заполнение реквизитов примитивных типов.
Заполнение ссылочных реквизитов.
Запись объекта.
Проведение и/или запись сопутствующих объектов.
На задачах сопровождения, там, где нас приглашают для доработок существующей интеграции, часто видим, что весь код пишется в обработчике записи, что ведет к колоссальному дублированию кода. Разные разработчики, а зачастую и разные подрядчики, применяют различные подходы к реализации, что очень сильно усложняет читаемость, багфикс и доработки.
При этом DATAREON позволяет делать общие функции. Да, с некоторыми особенностями вызова и передачи параметров, но это всё равно гораздо лучше, чем дублировать код.
Почему функции игнорируются разработчиками? Возможно, кто-то вообще о них не знает, вполне допускаю, но основная причина, как мне кажется, — отсутствие возможности отладки.
Особенности отладки в обработчиков DATAREON
Код обработчиков можно отлаживать прямо в DATAREON, но функции — нет. По ним можно выловить через отладку в конфигураторе то, что подаётся на вход в функцию и что из неё возвращается, но построчная отладка функции невозможна. В отладчике код функции будет отображаться как <Неизвестный модуль>.
В таких условиях можно какие-то простые функции делать в 1С, потом копипастить в DARAREON, но при этом надо не забыть переделать вызов функций, учесть особенности передачи значений, возврата и т. д.
Когда разработчик встаёт перед задачей отладки сложного каскада функций, у него два варианта:
блуждать в потёмках, пытаться буквально наугад понять, что не так работает, изучая параметры, передаваемые в функцию или возвращаемые из функции;
потратить несколько часов на создание тестовой обработки, перенос туда всего каскада функций, адаптацию их под работу в 1С. Потом пройти отладчиком, быстро понять, в чём проблема, перенести исправления обратно в DATAREON, не забыв адаптировать вызовы функций и передачу параметров.
По моим наблюдениям, чаще разработчики выбирают первый путь, т. к. кажется, что «сейчас я быстренько разберусь, не надо тратить время на переезд в конфигуратор». Но по факту это «быстренько» может занять весь день, и в итоге всё равно придётся переезжать в конфигуратор и там разбираться с отладкой.
Для себя мы решили этот вопрос разработкой конвертера, облегчающего переезд в конфигуратор и обратно.
Как работает конвертация обработчиков DATAREON в 1С
Экспортируем конфигурацию в каталог.
Запускаем конвертер build_bsl.exe <путь к папке с конфигурацией>.
Получаем модули для каждой базы, интегрированной с DATAREON.
Модуль вставляем в специальную заготовку с интерфейсом для отладки обработчиков.
Никакой ручной доработки модуля не требуется — он полностью готов к работе. Более того, его не требуется адаптировать для работы в 1С, а это значит, что после исправления бага или доработки не нужно будет адаптировать его обратно под DATAREON.
Функционал toPlatform
Из импортированного модуля выбирается обработчик, есть возможность выбрать ссылку на объект либо набор для выгрузки регистра, по кнопке выполнить обработчик выполняется, json-ы c телом и свойствами сообщения отображаются на форме.
Функционал fromPlatform
На вкладке fromPlatform можно выбрать обработчик для отладки, указать систему источник, тело и свойства сообщения в виде josn.
Тело и свойства сообщения для отладки загрузки можно получить в центре мониторинга DATAREON, или взять из обработки отладки.
Что с обратной конвертацией?
Да, ее мы тоже сделали.
Зачастую при переводе какой-то работающей интеграции на DATAREON нужно взять готовый код функций 1С, добавить их вызов в обработчике — и готово. Чтобы не тратить время на перенос и адаптацию каскада функций в DATAREON, мы сделали обратную конвертацию.
Разработка нового функционала ведётся в модуле обработки 1С. Отлаженная обработка сохраняется в файлы, на модуль обработки натравливается конвертер build_bsl.exe, и на выходе появляется ZIP-файл с обработчиками и функциями. Этот файл можно импортировать в DATAREON через стандартную процедуру загрузки конфигурации.
Если ранее уже были созданы функции или обработчики, они будут обновлены. При этом все вызовы функций, операторы Возврат, передача параметров в функцию и обратно будут адаптированы под DATAREON. После импорта всё, что нужно, — привязать функции к системам, и можно работать.
Конвертер экономит нам десятки часов разработчиков и позволяет успешно конкурировать по стоимости как в проектных работах, так и в задачах сопровождения.
Использование ED
А можно делать интеграции еще быстрее? Да, можно. Для типовых объектов можно использовать правила Enterprise Data.
Что такое ED?
EnterpriseData (кратко — ED) — это основанный на XDTO формат обмена данными, созданный фирмой «1С» для удобной интеграции с программами «1С». Формат ED используется как основа для типового обмена во всех конфигурациях: конфигурации уже умеют конвертировать свои объекты в структуру формата и обратно.
Стоит также отметить, что ранее в конфигурациях 1С использовался и до сих пор поддерживается обмен по правилам конвертации. Ключевое отличие старого и нового обмена представлен на картинках:
Ключевое отличие в том, что выгрузка в формате ED выгружает данные без кода загрузки и, соответственно, без привязки к какому-то конкретному получателю. А это значит, что такой формат очень подходит для обменов по схеме «звезда» с использованием шины данных.
Благодаря универсальности формата новый объект можно один раз получить из источника, отправить в шину и загрузить во все системы-получатели, и для этого не нужно писать никакой код — он уже есть во всех конфигурациях.
Также отмечу, что мы не используем типовые механизмы планов обмена и регистры публичных идентификаторов объектов, потому что они ориентированы на обмен «точка — точка». Вместо этого мы сохраняем соответствия в банке данных DATAREON и при выгрузке объекта получателю заменяем GUID’ы ещё в шине данных.
Адаптер ED для шины DATAREON
Формат ED подходит для быстрого запуска обмена типовыми объектами. Это уже второй наш подход к использованию ED в DATAREON.
Первая версия адаптера ED вызывала методы конфигурации 1С для получения XML-пакета с данными, передавала через шину этот пакет — и на этом всё. Проблема первой версии была в том, что в пакет никак нельзя было внести изменения, а они нужны. Например, у вас доработанная конфигурация, и к двум сотням типовых реквизитов вам нужно добавить десяток своих. В первой версии для этого приходилось дорабатывать правила в самой конфигурации, что, в принципе, допустимо, но мы стараемся на проектах не делать ничего в конфигурациях и расширениях заказчика. Когда весь проектный код находится в конфигурации DATAREON, это упрощает управление изменениями и чётко разделяет зоны ответственности команд.
Кроме того, есть ситуации, когда конфигурация содержит объект, но не содержит правил обмена. Например, на одном из проектов нам нужно было транслировать данные регистра сведений «Кадровая история сотрудников» из ЗУП в БП. В БП нет правил загрузки для данного регистра, но они есть в «Комплексной автоматизации», и структуры объектов совпадают. В старом адаптере нам снова пришлось бы создавать расширение для исправления правил в конфигурации. Новый адаптер ED позволяет в коде DATAREON добавить дополнительные правила и таким образом решить задачу без создания дополнительных расширений.
Заключение
Когда интеграций становится много, на первый план выходит воспроизводимость и управляемость процесса их создания и последующей поддержки. Автоматизация типовых этапов и переиспользование наработок позволяют упростить развитие и сопровождение интеграционного ландшафта.
Если у вас стоят задачи по развитию или пересборке интеграций, вы можете обратиться к нам за консультацией или проработкой интеграционного проекта. Мы работаем с такими задачами регулярно и помогаем выстраивать интеграции как управляемый и масштабируемый процесс.
Посмотреть практический вебинар «Как оптимизировать бюджет на интеграции в 2026 году: практики и инструменты для DATAREON». Будет полезно для ИТ-директоров и архитекторов, которые хотят сократить стоимость интеграций на DATAREON и избавиться от рутинных трудозатрат.