Петли обмена в 1С: эхо-пакеты, РИБ и CD3 - три боевых разбора

Петли обмена в 1С: когда пакет ходит по кругу, а не по сети

Успешная выгрузка в журнале обмена не гарантирует, что на приёме не включилась повторная регистрация изменений. Ниже - таблица типовых симптомов и три разобранных случая из EnterpriseData и РИБ: эхо архивного каталога, коллизия кодов узлов после копии базы и правило CD3, которое перезаписывает регистр сведений при каждой загрузке.

Таблица симптомов

Таблица симптомов: где смотреть и типичная причина петли

Случай 1: эхо исходящего пакета на узле-получателе

На узле «Склад_Юг» включён обмен EnterpriseData с центром. После обновления типовой доработки в модуле менеджера обмена исчезла проверка «узел-источник сообщения». Симптом из таблицы про GUID «ЗаказКлиента» с номером 00001427 проявился через два часа после первой успешной выгрузки.

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

// фрагмент технологического журнала (пример)
26:41:03.012-0,EXCP,2,process=rphost,p:12345,t:67890,Event=ExchangeLoad,Data=MessageId={A1B2C3D4-...}
26:41:03.890-0,EXCP,2,process=rphost,p:12345,t:67890,Event=ExchangeSave,Data=MessageId={A1B2C3D4-...}
26:56:11.004-0,EXCP,2,process=rphost,p:12345,t:67890,Event=ExchangeLoad,Data=MessageId={A1B2C3D4-...}

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

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

На стороне СУБД мониторинг блокировок не показывал эскалаций; узкое место было в прикладном коде и в маршруте каталогов. После правки маршрутизации архив перестал попадать в очередь входящих, а счётчик исходящих записей для проблемного GUID обнулился примерно через один регламентный цикл (в той базе интервал был 15 минут).

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

Случай 2: коллизия узлов РИБ после восстановления копии

Вторая база, схема РИБ: три узла, обмен файлами. После восстановления тестовой копии в продуктивный контур у двух узлов совпал префикс номера сообщения и код в справочнике «Узлы информационной базы». Симптом из таблицы про стабильный размер XML проявился как «пустые» пакеты с одним документом «ПеремещениеТоваров».

// журнал регистрации (пример строки)
Обмен данными. Выгрузка для узла ЦентральныйOffice
Размер сообщения: 11854
Количество объектов: 1
Узел отправитель: Склад_Север (код SK1)
Узел получатель: Склад_Север (код SK1)

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

Исправленный фрагмент обработчика после загрузки (упрощённо, логика проекта):

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

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

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

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

Случай 3: правило CD3 и повторная запись регистра сведений

Третий контур: обмен EnterpriseData между ERP и отдельной базой учёта затрат. В правилах конвертации для документа «ОтражениеЗарплатыВФинансовомУчёте» в обработчике «После загрузки» вызывалось заполнение регистра сведений «НастройкиРаспределенияЗатрат» с принудительной записью набора. Каждая запись набора регистрировала изменения для всех узлов плана, хотя сам документ уже был помечен как принятый извне.

-- пример запроса для поиска «горячего» регистратора (СУБД)
SELECT TOP 20
 _NodeID,
 _RecorderRRef,
 COUNT(*) AS Cnt
FROM dbo._1SChanged
WHERE _NodeID = 0x00000000000000000000000000000005
GROUP BY _NodeID, _RecorderRRef
ORDER BY Cnt DESC;

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

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

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

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

Граничные случаи

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

Профилактика

• Раз в неделю снимать TOP регистраторов из служебных таблиц регистрации изменений по каждому проблемному узлу и сравнивать с журналом обмена за тот же интервал.
• Фиксировать в журнале регистрации пару «идентификатор сообщения + узел-источник» на этапе загрузки; без источника расследование эхо-пакетов растягивается на дни.
• После любого восстановления ИБ из копии проверять уникальность кодов узлов и номеров сообщений до включения регламентного обмена.
• В правилах CD3 запрещать безусловную запись связанных регистров в обработчиках «После загрузки»; переносить тяжёлую логику в отложенные задания с явным флагом локального изменения.
• Для EnterpriseData держать один канал доставки на узел; архивные каталоги не должны совпадать с рабочими входящими.
• Нагрузочный тест обмена: один искусственный документ, три цикла «выгрузка-загрузка», контроль что запись в «Изменения для обмена» не появляется после третьего цикла.
• Перед включением нового узла EnterpriseData зафиксировать эталонный снимок: количество записей в регистре изменений, TOP регистратор, средний размер последних десяти сообщений; после первого суточного цикла сравнение с эталоном часто выявляет петлю раньше, чем пользователи заметят расхождение в отчётах.
• Для CD3 вести лист соответствия: какие обработчики «После загрузки» трогают регистры и документы с движениями; при обновлении типовой сверять его с diff правил конвертации, даже если формально обмен «не менялся».

До/после: архивный каталог отделён от входящих, TOP регистраторов сходится

Три правила на будущее

1. Успешный статус в журнале обмена доказывает только доставку пакета, но не отсутствие повторной регистрации на стороне приёма; петлю ищут по паре событий Load/Save и по регистратору в служебных таблицах.
2. Коллизия кодов узлов РИБ после копирования баз выглядит как «мелкий XML каждые N минут», а не как ошибка сети; первым делом сверяют отправителя и получателя в одной строке журнала.
3. Правила CD3, которые пишут регистры в «После загрузки», масштабируют зацикливание на весь план обмена; изоляция такой логики важнее очередной оптимизации SQL на выгрузке.

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