При масштабировании ИТ-инфраструктуры, когда количество баз данных 1С переваливает за десяток, классические обмены типа «точка-точка» (напрямую между двумя базами) становятся трудноуправляемыми. Возникает потребность в переходе на более современную архитектуру — информационную шину данных (ESB — Enterprise Service Bus). Разберем подробно, как устроена эта технология, какие инструменты использовать и как изменить логику обменов, чтобы система работала стабильно и быстро.
Для начала проанализируем, что же такое шина в своей основе. В классической схеме выгрузки через ПланыОбмена база-источник формирует файл, который затем забирает база-приемник. Проанализируем ситуацию: если у вас 10 баз и каждая должна обмениваться с каждой, вам придется настроить и поддерживать десятки соединений. Шина данных меняет эту топологию на «звезду».
Шина — это в первую очередь транспорт. Рассмотрим простую аналогию: представьте, что база-источник кладет сообщение в почтовый ящик (очередь), а шина сама решает, кому из адресатов это сообщение доставить. При этом база-источник может «не знать» о существовании конкретных приемников. Она просто сообщает: «У меня изменился контрагент», а шина маршрутизирует эту информацию всем подписанным на это событие системам.
Преимущества такого подхода:
Один из главных вопросов при переходе на шину: в каком формате передавать данные? Если база-источник будет отдавать данные в своем внутреннем формате, то шине или приемнику придется каждый раз «подстраиваться» под него. Чтобы этого избежать, внедряется Каноническая модель данных (CDM).
Разберем по шагам, как это работает:
Конвертация данных 3.0. В отличие от версии 2.1, КД 3.0 базируется на технологии XDTO (XML Data Transfer Objects).В КД 3.0 вы описываете XDTO-пакет, который и является той самой канонической моделью. База-источник формирует объект по правилам КД3, упаковывает его в JSON или XML и отправляет в шину. Шине «все равно», что внутри пакета, она просто передает его по маршруту.
Часто пользователи хотят видеть изменения «здесь и сейчас». Рассмотрим, как реализовать событийную модель, чтобы при нажатии кнопки «Записать» в одной базе, объект тут же появлялся в другой. Выясним причину, почему нельзя просто отправить данные в шину прямо из кода модуля объекта.
Важный нюанс: Прямая отправка данных в транзакции записи — это плохая практика. Если шина будет долго отвечать или возникнет сетевая ошибка, транзакция 1С откатится, и пользователь не сможет сохранить документ. Правильный алгоритм выглядит так:
Подписки на события (например, ПриЗаписи или ОбработкаПроведения).Пример кода для регистрации изменений в упрощенном виде:
Процедура ПриЗаписиОбъектаДляШины(Источник, Отказ) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
ЗаписьОчереди = РегистрыСведений.ОчередьСообщенийШины.СоздатьМенеджерЗаписи();
ЗаписьОчереди.Объект = Источник.Ссылка;
ЗаписьОчереди.МоментВремени = ТекущаяДатаСеанса();
ЗаписьОчереди.Состояние = Перечисления.СостоянияСообщений.В_Очереди;
ЗаписьОчереди.Записать();
КонецПроцедуры
Проанализируем популярные программные продукты для реализации ESB в экосистеме 1С:
Это современный продукт от фирмы «1С», написанный на Java. Он предоставляет визуальный редактор, где вы рисуете схему движения данных: откуда пришло, как преобразовалось, куда ушло. 1С:Шина отлично интегрируется с платформой 8.3 через специальные механизмы сервисов интеграции. Это решение «из коробки» для тех, кто хочет оставаться в рамках стека 1С.
Это универсальные брокеры сообщений. Они очень быстрые и бесплатные (open-source), но требуют написания собственных адаптеров на стороне 1С. Вам придется самостоятельно реализовать HTTP-интерфейс или использовать внешние компоненты для взаимодействия с очередями. RabbitMQ лучше подходит для передачи отдельных бизнес-событий, а Kafka — для огромных потоков данных (например, логов или транзакций ритейла).
Специализированное коммерческое решение для 1С. Имеет мощные средства трансформации данных «на лету» внутри самой шины и готовые коннекторы даже для старых версий, таких как 1С 7.7.
Поскольку в версии 7.7 нет полноценных веб-сервисов и современных механизмов работы с JSON, интеграция со старыми базами обычно происходит через «агенты». Это небольшие приложения или внешние компоненты, которые читают файлы выгрузки или напрямую обращаются к таблицам базы данных (через SQL или ADO), формируют сообщение и передают его в шину. Таким образом, даже «семерка» может стать полноценным участником современного событийного обмена.
Рассмотрим подробнее критерии выбора. Переход на шину — это дорогостоящий и сложный процесс. Если у вас две базы и обмен идет раз в сутки, классическая Конвертация данных 2.1 через файлы вполне справится.
Задумайтесь о шине, если:
Внедрение шины — это не просто смена «папки с файлами» на «очередь сообщений». Это переход к сервис-ориентированной архитектуре (SOA), которая сделает вашу ИТ-систему гибкой и готовой к любым изменениям бизнеса.