В современной системной архитектуре часто возникает задача объединения множества разрозненных баз данных в единое информационное пространство. Использование схемы «каждая с каждой» ведет к экспоненциальному росту связей и сложности поддержки. Оптимальным решением становится архитектура типа Hub-and-Spoke (звезда), где в центре находится промежуточный узел — так называемый «черный ящик», который управляет потоками данных. Рассмотрим подробнее, как спроектировать такую систему на базе 1С с использованием HTTP-запросов, и проанализируем, стоит ли изобретать свой «велосипед» или лучше воспользоваться готовыми инструментами.
При проектировании системы обмена через центральный узел мы должны выделить несколько ключевых уровней ответственности. Разберем по шагам предложенную концепцию:
ПланыОбмена. В узлах плана регистрации фиксируются изменения конкретных объектов (справочников, документов). Это позволяет системе «знать», какие данные еще не были отправлены.Один из самых важных вопросов — как центральный узел определяет, в какие базы-приемники нужно направить полученный пакет. Проанализируем два основных подхода:
Модель подписок (Publish/Subscribe): В этой схеме каждая база-приемник «подписывается» на определенные типы данных. В центральном узле хранится таблица настроек, где указано: «Если пришел объект типа Справочник.Номенклатура, его нужно отправить в Базу_А и Базу_Б». При поступлении данных система просто копирует сообщение для всех подписчиков.
Маршрутизация на основе контента (Content-Based Routing): Здесь решение принимается исходя из данных внутри пакета. Например, пакет содержит ИНН организации. Шлюз анализирует этот ИНН и понимает, что данная организация ведется только в базе филиала «Юг», и направляет данные именно туда. Для реализации этого механизма в «черном ящике» создаются правила маршрутизации, хранящиеся в регистрах.
Работа через HTTP подразумевает, что канал связи может быть нестабилен. Выясним причину возможных сбоев и способы их нивелирования:
Идемпотентность: Мы должны исключить дублирование данных при повторных отправках. Для этого каждому сообщению присваивается уникальный GUID. Приемник, получив пакет, проверяет, не обрабатывал ли он ранее сообщение с таким идентификатором. Если да — он просто возвращает успешный статус, не создавая новый объект.
Подтверждение (Ack/Nack): Процесс доставки должен быть подтвержден. Рассмотрим пример логики регламентного задания в центральном узле:
Процедура ОтправитьПакетыПолучателям()
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Пакет, УзелПолучатель ИЗ РегистрСведений.ОчередьИсходящих ГДЕ Статус = &СтатусОжидания";
Запрос.УстановитьПараметр("СтатусОжидания", Перечисления.СтатусыПакетов.ВТрафике);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
Результат = ВыполнитьHTTPЗапрос(Выборка.УзелПолучатель, Выборка.Пакет);
Если Результат.КодСостояния = 200 Тогда
УстановитьСтатусДоставки(Выборка.Пакет, Перечисления.СтатусыПакетов.Доставлено);
Иначе
ЗарегистрироватьОшибку(Выборка.Пакет, Результат.ТекстОшибки);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Вместо разработки собственных форматов обмена и макетов, мы крайне рекомендуем рассмотреть стандарт EnterpriseData, предложенный фирмой 1С. Это унифицированный XML-формат, основанный на XDTO-пакетах.
Преимущества EnterpriseData:
МенеджерОбменаЧерезУниверсальныйФормат.Конвертации данных 3.0.Если ваша система разрастается до десятков баз с огромным объемом транзакций, «черный ящик» на базе 1С может стать узким местом из-за блокировок таблиц при записи в регистры сведений. В таких случаях целесообразно вынести очередь сообщений за пределы 1С.
RabbitMQ или специализированные сервисные шины (ESB) обеспечивают:
Если вы все же решили создавать подсистему самостоятельно, обратите внимание на следующие моменты:
Логирование и мониторинг: Обязательно создайте интерфейс администратора обмена. Вы должны видеть в реальном времени количество пакетов в очереди, ошибки доставки и время обработки каждого сообщения. Без этого поиск причин, почему «у нас не пришла накладная», превратится в кошмар.
Сжатие данных: При передаче больших справочников или тяжелых документов используйте GZip для сжатия тела HTTP-запроса. Это существенно сократит нагрузку на сеть и ускорит передачу.
Безопасность: Никогда не оставляйте HTTP-сервисы открытыми. Используйте Basic Auth (авторизацию по логину/паролю) или авторизацию по токенам в заголовках запроса. Также крайне желательно использовать протокол HTTPS для шифрования трафика между узлами.
Версионирование: В структуре вашего пакета данных всегда должно быть поле ВерсияФормата. Это позволит вам обновлять одну базу (и ее правила выгрузки), не ломая обмен со всеми остальными базами, которые еще работают на старом формате.
Таким образом, создание собственного универсального механизма обмена — задача амбициозная и интересная. Однако, прежде чем приступать к написанию кода, проанализируйте стандартные возможности Конвертации данных 3.0 и формата EnterpriseData. Зачастую использование этих инструментов в сочетании с простым HTTP-шлюзом дает гораздо более стабильный и дешевый в поддержке результат, чем полностью самописная система.