Обмен с розничной сетью через 1С:Шину вместо РИБ: опыт сети из 70+ магазинов

Сейчас многие 1С-разработчики смотрят в сторону MCP, ИИ и новых инструментов автоматизации. Я же решил поделиться историей из соседней, но вполне прикладной практики: как мы перевели розничную сеть из 70+ магазинов с классического РИБ на 1С:Шину. В статье покажу, почему РИБ в какой-то момент перестал нас устраивать, как мы пришли к событийной модели, зачем подключили платформенную историю данных и почему сразу развели регулярный обмен и доставку обновлений по разным контурам. Материал для тех, кто поддерживает розницу, работает со слабой связью на точках и устал отдавать ночи на массовые обновления.

Небольшое вступление

Сейчас лента у всех примерно одинаковая: кто-то собирает агентов, кто-то прикручивает ИИ к постановке задач, кто-то делает очередной MCP-сервер. На этом фоне мне захотелось поговорить о другой стороне нашей работы: о вещах, которые звучат не так модно, зато каждый день держат бизнес в рабочем состоянии. А если в контуре больше семидесяти магазинов, часть из них сидит на связи по принципу «хоть бы вообще не отвалилось», а очередное обновление законодательства нужно выкатывать вчера, тема обменов очень быстро перестает быть второстепенной.

Именно в такой точке мы и оказались. Формально всё работало. На практике же любая ночь обновления превращалась в проверку на прочность: дойдут ли пакеты, не встанет ли обмен, не зависнет ли очередной узел и успеем ли мы вообще к утру закончить обновление всей сети.

Почему РИБ перестал тянуть сеть

Сеть была действующая: 70+ магазинов в разных регионах, центральный офис в одном городе, магазины в других, в том числе в Туле и Москве. Все точки были завязаны на центральную базу, а качество интернета по магазинам гуляло от «терпимо» до совсем печального, когда связь держалась буквально на сим-карте и добром слове.

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

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

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

У розницы здесь своя специфика: обновлять магазины днем нельзя, график работы не прощает таких экспериментов. Значит, всё переносится на ночь. А если у тебя РИБ, большой контур и много доработок с расширениями, то одна такая ночь легко превращается в длинную смену с постоянной проверкой журнала регистрации и вопросом: «Что там на очередной точке?»

Проблемы копились вполне конкретные:

• полный цикл обмена по всей сети занимал заметное время, даже при параллельной обработке только пяти узлов;
• обновлять нужно было сразу все узлы, иначе обмен начинал жить своей отдельной жизнью, а магазины переставали вовремя видеть остатки, цены и текущие данные;
• на тестовом стенде обмен мог пройти идеально, а на боевых базах ночью все вставало колом;
• часть магазинов сидела на настолько слабом интернете, что скачивание одной конфигурации весом больше гигабайта могло занимать четыре часа и больше;
• любое обновление типовой из-за ККТ, маркировки, Честного знака, а теперь еще и ТС ПИоТ, автоматически означало новый ночной заход.

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

Поэтому задача была не просто «уйти с РИБ ради модной архитектуры». Нужно было убрать саму зависимость от ночных массовых раскаток, снизить цену ошибки и получить контур, в котором обмен не ломает команду вместе с бизнесом. Так мы и пришли к переходу на 1С:Шину.

Как мы перестроили обмен

Вместо жесткой привязки к РИБ мы начали строить обмен через 1С:Шину. В нашей организации именно 1С:Шина была выбрана как транспорт для доставки сообщений. Но для нас это было не про «заменить одну технологию на другую». Это была попытка поменять сам подход к обмену.

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

К этой мысли меня сильно подтолкнула статья Дмитрия «Версионирование объектов VS История данных». Плюс очень помогла его конфигурация Papi. Некоторые идеи оттуда я взял как ориентир, чтобы не изобретать заново то, что уже было хорошо продумано, и заметно ускорить разработку. За это Дмитрию отдельное спасибо.

Логика получилась простой и очень практичной:

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

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

Здесь есть еще одно важное отличие от РИБ. В классической схеме изменения копятся в плане обмена и уходят по расписанию, условно раз в двадцать минут. За это время данных может накопиться много, а сама транзакция выгрузки заметно растет. В варианте через шину у нас в транзакции, по сути, всегда один объект или одно конкретное изменение. Она получается максимально короткой, а это напрямую сказывается и на скорости обмена, и на его общей отзывчивости, и на отказоустойчивости. Если приходят некорректные данные или происходит ошибка обработки, сбой касается одного конкретного объекта, а не тянет за собой весь накопившийся пакет сразу.

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

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

Для обмена между магазинами и центром вместо штатной сериализации платформы мы используем библиотеку SerLib1C: она хорошо подошла под задачу «передавать изменения, а не весь объект», когда правила конвертации не обязательны, а нужен компактный и понятный обменный пакет между одинаковыми конфигурациями. Артёму Кузнецову за эту библиотеку отдельное спасибо: она сильно упростила работу и сэкономила нам много времени.

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

EnterpriseData мы используем там, где конфигурации уже не идентичны. Например, при обмене через 1С:Шину между ERP и Бухгалтерией, где обмен «один в один» уже не подходит и без правил конвертации не обойтись.

Еще одна важная разница с РИБ проявилась на массовых рассылках. Если раньше новая номенклатура фактически выгружалась на каждый узел отдельно, то теперь из центра сообщение формируется один раз, а дальше его уже раздает сама шина всем получателям. Если конкретный получатель не указан, сообщение становится широковещательным. За счет этого сам обмен заметно разгружается.

В результате схема стала такой:

• изменение фиксируется в базе;
• подписки на ПередЗаписью включают постановку версии в очередь обработки (ВключитьОбработкуПослеЗаписиВерсии);
• подписка на ОбработкаПослеЗаписиВерсийИсторииДанных подхватывает запись версий и запускает фоновое задание (ЗапуститьФоновуюОбработкуВерсий);
• в фоне выполняется свертка изменений, формируется JSON и подбираются настройки отправки;
• сообщение уходит через 1С:Шину как широковещательное или адресное;
• на приемной стороне отрабатывает обработка входящих сообщений;
• тяжелые этапы выполняются в фоне, а журнал регистрации дает нормальную точку диагностики.

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

При этом для меня здесь важен еще один момент. Конкретно у нас в продакшене в качестве транспорта выбрана именно 1С:Шина, но само расширение и его архитектурный подход не упираются намертво только в нее. Если в организации в качестве транспорта используется другая шина сообщений, тот же подход можно адаптировать и под RabbitMQ, и под Kafka, и под другие брокеры. Суть решения здесь не только в конкретной реализации транспорта, а в событийной модели, истории данных, подготовке изменений и понятной цепочке обработки.

Для кого это может быть полезно

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

Что в итоге получилось

Если коротко, то после переделки у нас получился не просто «новый обмен», а нормальный событийный контур:

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

Конкретно у нас транспортом выбрана 1С:Шина, но сам подход не привязан жестко только к ней. Если в организации используется другой брокер сообщений, ту же архитектурную идею можно адаптировать и под RabbitMQ, и под Kafka, и под другой транспорт.

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

Как это работает на практике

В живой базе это выглядит так:

1. Пользователь создает объект или меняет существующий.
2. Если объект новый, он уходит целиком; если изменился только один реквизит, в сообщение попадает только это изменение.
3. Подписки на ПередЗаписью ставят версию в очередь на обработку после записи.
4. Событие ОбработкаПослеЗаписиВерсийИсторииДанных запускает фоновое задание: свёртка изменений, JSON, параметры отправки.
5. Сообщение уходит через сервисы интеграции 1С:Шины как широковещательное или адресное.
6. На приемной стороне сообщение читается, разбирается и загружается в нужный узел.

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

Как это выглядит в самой 1С:Шине

Ниже скрин общей схемы обмена между магазинами в 1С:Шине.

Здесь для меня особенно важен блок «Маршрут по содержимому». Он нужен для того, чтобы сообщение не просто проходило через центр как через обязательную промежуточную точку, а могло по содержимому сразу попасть нужному получателю.

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

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

Как собрать такой механизм у себя и добавить свой объект

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

Базовая настройка

1. Настроить участников обмена в справочнике УчастникиОбмена.
2. Создать элемент для базы-отправителя и установить у него флаг Отправитель.
3. Для центральной базы при таком флаге код участника формируется по принятому у вас шаблону, например NODE_CENTRAL.
4. Для магазинов участники связываются с элементом справочника Магазины; код формируется автоматически на основе магазина и организации, например по шаблону shop_XXX_000.
5. Убедиться, что сервис интеграции и канал 1С:Шины активны.
6. Открыть форму настройки хранения истории и включить в ней нужные объекты для обмена.

Как добавить новый объект в обмен

Для обмена «один в один» без правил конвертации подключение нового объекта выглядит так:

1. Включить для объекта платформенную историю данных.
2. Добавить тип объекта в подходящую подписку на ПередЗаписью:
   для документов — ПередЗаписью_Документы;
   для справочников — ПередЗаписью_ОбъектыБезДокументов;
   для регистров сведений — ПередЗаписью_Регистры.
   На этом шаге вызывается ИсторияДанныхДляШины.ВключитьОбработкуПослеЗаписиВерсии, чтобы после записи версия попала в очередь обработки.
3. Добавить тот же тип объекта в подписку ОбработкаПослеЗаписиВерсийИсторииДанных.
   Именно она запускает ФоновыеЗаданияШины.ЗапуститьФоновуюОбработкуВерсий: дальше свёртка изменений, JSON и отправка в шину выполняются уже в фоне, без блокировки основного сеанса.
4. При необходимости настроить параметры в форме НастройкаИсторииХранения. Она пишет данные в регистр НастройкиХраненияИсторииОбмена.

Если нужен обмен не «один в один», а через правила конвертации, это уже отдельный сценарий с EnterpriseData.

Что проверить после добавления объекта:

1. История данных для него включена.
2. Тип объекта добавлен в нужную подписку на ПередЗаписью.
3. Тот же тип есть в подписке ОбработкаПослеЗаписиВерсийИсторииДанных.
4. В форме НастройкаИсторииХранения объект настроен как нужно.
5. Тестовая запись действительно отправляет сообщение в шину.

Ручная отправка, если привыкли к «зарегистрировал на плане обмена»

Отдельно в нашей реализации была обработка СообщенияСервисовИнтеграции (в интерфейсе удобнее искать по синониму вроде «Сообщения сервисов интеграции»). На вкладке «Отправить» можно вручную собрать список объектов, указать получателей или включить отправку всем, и выполнить выгрузку в JSON с отправкой в канал — по смыслу это ближе к привычному «выгрузи то, что я отобрал», без ожидания очередной версии в истории.

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

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

Как определяется получатель

По коду логика простая:

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

Именно за счет этого новая номенклатура из центра может быть сформирована один раз и дальше разойтись по сети уже силами шины, без повторной выгрузки одного и того же пакета на каждый узел, как это было в РИБ.

Как проверить, что все работает

Минимальная проверка выглядит так:

1. Убедиться, что у базы настроен участник-отправитель.
2. Включить нужный объект в историю данных и подписки.
3. Изменить или создать тестовый объект.
4. Проверить журнал регистрации:
   1сШина:Выгрузка для отправки;
   1сШина:Загрузка для приема;
   1сШина:НастройкиХраненияИстории при проблемах с настройками;
   служебные ошибки по истории данных.
5. При необходимости открыть обработку СообщенияСервисовИнтеграции:
   вкладки «Сервисы интеграции» — состояние канала, отбор и просмотр сообщений, тело, очистка;
   вкладка «Отправить» — ручная выгрузка выбранных объектов в шину.

Техническая информация

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

Ограничения: в автоматическом событийном контуре не участвуют регистры накопления — под платформенную историю они у нас не заведены. Если объект не включён в историю и не стоит в подписках, фоновая отправка по изменениям к нему не пойдёт; разовую доставку «как вручную с плана обмена» для идентичных баз можно сделать через обработку СообщенияСервисовИнтеграции, вкладка «Отправить».

Что дало это решение на практике

Если убрать красивые слова, то преимущество было очень простое: мы начали возвращать себе управляемость.

• Обновления перестали быть только ночным кошмаром.
• Магазины больше не нужно обновлять строго все разом только потому, что иначе встанет весь контур.
• Сопровождать решение стало проще, потому что у обмена появились понятные точки входа и диагностики.
• Объем передаваемых данных уменьшился за счет событийной модели и передачи только изменившихся реквизитов.
• После перехода мы получили фактически мгновенный обмен как из центра во все узлы, так и с узлов обратно в центр.
• Обмен работает асинхронно, без прежних задержек, связанных с тяжелым циклом РИБ по всем узлам.
• Центральная база практически сразу получает актуальную информацию об остатках в магазинах и об их продажах.
• Магазины так же быстро получают из центра новые цены, новые позиции номенклатуры и остальные изменения.
• Ошибки стало проще искать: есть журнал, есть сообщения сервисов интеграции, есть понятная цепочка обработки.
• Массовая рассылка новых данных перестала превращаться в повторную выгрузку одного и того же объекта по всем узлам: центр формирует сообщение один раз, дальше работает сама шина.
• Плавное обновление магазинов стало реалистичнее, потому что сериализация спокойнее переживает расхождение релизов, чем классический сценарий «обнови всех разом, иначе обмен встанет».
• Систему стало реальнее передавать новому разработчику без сакральной фразы «главное пережить первую ночь обновления».

Сам кейс

Сеть из 70+ магазинов, центральный офис и точки в разных регионах, часть из которых живет на очень слабом интернете. Исторически обмен был построен на РИБ: отдельный узел на магазин, расписание, параллельный запуск до пяти узлов, обновления и расширения тоже ехали тем же путем.

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

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

Если совсем коротко описать разницу в формате «было / стало», то раньше обновление означало массовую раскатку сразу на всю сеть. Теперь можно без риска для всей сети и даже для тестовых стендов обновить один магазин, спокойно обкатать на нем новый функционал и только потом двигаться дальше. Для розницы это уже не просто техническое улучшение, а нормальный способ вернуть себе право на аккуратное внедрение, а не на прыжок сразу через весь контур.

Отдельно под эту задачу у нас появился еще один механизм: доставка и обновление магазинов на базе OneScript и библиотеки Melezh. Его изначально делали как отдельный, передаваемый инструмент, который потом можно спокойно отдать в сопровождение другому 1С-разработчику. Если тема окажется интересной, по нему можно сделать отдельную статью с исходниками и пошаговой инструкцией по запуску.

Как мы отдельно решили доставку обновлений

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

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

И здесь хочу отдельно сказать большое спасибо Антону Титовцу за такую библиотеку. Для подобных задач это действительно сильный и очень полезный инструмент, который заметно упрощает жизнь и позволяет быстрее прийти к рабочему результату.

По сути после перехода у нас получилось два независимых канала:

• первый канал через 1С:Шину закрывает постоянный обмен данными;
• второй канал на базе OneScript и Melezh закрывает доставку самих обновлений, расширений, конфигурации и вообще выполнение любой нужной логики или скрипта на узле в централизованном режиме.

Для меня это был важный момент. Одно дело, когда решение работает, пока его держит в голове человек, который все это строил. И совсем другое, когда у тебя есть понятный механизм, который можно передать следующему 1С-разработчику без обряда посвящения, ночной смены и фразы «ну ты там сам по ходу разберешься».

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

• 1С:Шина и событийный обмен отвечают за передачу данных;
• отдельный механизм на OneScript отвечает за доставку обновлений, расширений и централизованный запуск нужных сценариев на магазинах.

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

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

Если будет интерес, по этому механизму можно отдельно показать:

• структуру сценариев на OneScript;
• как организована доставка на магазины;
• как устроен запуск.

Что важно разработчику

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

1. Объект ставится в обработку на ПередЗаписью

Процедура ПередЗаписью_Документы(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт

    Если Не СлужебныеФункцииШины.НужноОбрабатыватьПодписку(Источник, Отказ) Тогда
        Возврат;
    КонецЕсли;

    ИсторияДанныхДляШины.ВключитьОбработкуПослеЗаписиВерсии(Источник);

КонецПроцедуры

Здесь логика намеренно простая: на ПередЗаписью объект ещё не отправляется. Мы только говорим платформе, что после записи его версию нужно забрать в обработку.

2. После записи версии запускается фон

Процедура ОбработкаПослеЗаписиВерсийИсторииДанных(Источник, ИнформацияОЗаписиВерсий) Экспорт

    ОбъектМетаданных = Метаданные.НайтиПоТипу(ТипЗнч(Источник));
    ЭтоРегистр = ОбщегоНазначения.ЭтоРегистр(ОбъектМетаданных);

    ФоновыеЗаданияШины.ЗапуститьФоновуюОбработкуВерсий(
        ОбъектМетаданных,
        ИнформацияОЗаписиВерсий,
        ЭтоРегистр,
        Источник);

КонецПроцедуры

Ключевой момент здесь в том, что тяжёлая часть не висит на основном сеансе пользователя. После записи версия просто передаётся в фоновую обработку.

3. В фоне выполняется свёртка изменений, JSON и отправка

Процедура ОбработатьОдинОбъектИзОчереди(ДанныеОбъекта, ЭтоРегистр, МассивМетаданных, ИмяОбъектаМетаданных)

    Ключ = ДанныеОбъекта.Значение.Данные;
    ИзмененныеЭлементы = ДанныеОбъекта.Значение.ИзмененныеЭлементы;
    ВидИзменения = ДанныеОбъекта.Значение.ВидИзменения;

    Если ТребуетсяПропуститьОбработку(Ключ, ЭтоРегистр, ВидИзменения, ИзмененныеЭлементы) Тогда
        Возврат;
    КонецЕсли;

    СтрокаJson = ПреобразованиеДанныхСервер.Записать_Json(ДанныеОбъекта);
    ПараметрыНастроек = СервисыИнтеграцииВызовСервера.ПолучитьНастройкиСообщения(Ключ, ИзмененныеЭлементы);

    СервисыИнтеграцииВызовСервера.ОтправитьСообщение(
        ПараметрыНастроек.СервисыИнтеграции.Сервис,
        ПараметрыНастроек.СервисыИнтеграции.Канал,
        СтрокаJson,
        ПараметрыНастроек);

КонецПроцедуры

Это и есть основной рабочий цикл: взять версию, свернуть изменения, собрать JSON, определить параметры отправки и отдать сообщение в шину.

4. Получатель определяется по содержимому объекта

Функция ПолучитьНастройкиСообщения(Знач Источник = Неопределено, Знач ИзмененныеЭлементы = Неопределено) Экспорт

    ДанныеОтправителя = Справочники.УчастникиОбмена.ПолучитьКодОтправителя();
    ПараметрыНастроек = Новый Структура;
    ПараметрыНастроек.Вставить("КодОтправителя", ДанныеОтправителя.КодОтправителя);

    Широковещательное = Истина;

    Если Источник <> Неопределено Тогда
        ОбъектМетаданных = Источник.Метаданные();

        Если ОбщегоНазначения.ЭтоДокумент(ОбъектМетаданных) И ДанныеОтправителя.МастерБаза Тогда
            КодыПолучателей = ПолучитьКодыПолучателейИзДокумента(Источник, ИзмененныеЭлементы);
            Если ЗначениеЗаполнено(КодыПолучателей) Тогда
                Широковещательное = Ложь;
                ПараметрыНастроек.Вставить("КодПолучателя", КодыПолучателей);
            КонецЕсли;
        КонецЕсли;
    КонецЕсли;

    Если Широковещательное Тогда
        ПараметрыНастроек.Вставить("КодПолучателя", "");
    КонецЕсли;

КонецФункции

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

5. На приёме сообщение читается и сразу разбирается

Процедура ОбработкаВходящихСообщений(Сообщение, Отказ) Экспорт

    ВходящееСообщение = ПолучитьСтрокуИзБуфераДвоичныхДанных(Тело);
    СтруктураВозврата = ПреобразованиеДанныхСервер.Прочитать_Json(ВходящееСообщение);

    Если СтруктураВозврата.Отработал Тогда
        ЖурналРегистрации.ДобавитьСообщениеДляЖурналаРегистрации(
            "1сШина:Загрузка",
            УровеньЖурналаРегистрации.Информация,
            МетаданныеОбъекта,
            ОбъектИдентификации);
    Иначе
        РегистрыСведений.ВходящиеСообщенияСервисаИнтеграции.ДобавитьИзменитьЗапись(
            СвойстваСообщения,
            СтруктураВходныхПараметров);
    КонецЕсли;

КонецПроцедуры

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

Вместо вывода

Для меня эта история была не только про транспорт сообщений, форматы и подписки. Она была про то, как перестать жить в логике «лишь бы этой ночью всё не развалилось» и вернуть себе нормальное инженерное управление ситуацией.

РИБ в свое время закрыл задачу и долго тянул сеть. Но в какой-то момент масштаб, слабый интернет на точках, постоянные обновления типовых и объем доработок сделали его слишком дорогим именно в сопровождении. Переход на 1С:Шину не убрал всю сложность мира, но дал нам гораздо более спокойный и взрослый контур: с событийной моделью, с понятной диагностикой, с адресной и широковещательной доставкой и с возможностью обновлять магазины без чувства, что на кону стоит вся сеть сразу.

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

Для первой статьи мне хотелось показать именно это: не «смотрите, какая красивая технология», а «вот реальная боль, вот реальный путь и вот решение, которое в живой рознице действительно делает жизнь легче». Если у вас похожий контур и вы тоже устали мерить стабильность обмена количеством бессонных ночей, возможно, этот опыт поможет вам сэкономить и время, и нервы.