Одной из неприятных проблем, с которой может столкнуться разработчик при поддержке распределенных информационных баз (РИБ), является ситуация, когда данные независимых регистров сведений перестают выгружаться в периферийные узлы. Даже при корректных настройках плана обмена, включенной авторегистрации и отсутствии блокирующего кода, изменения могут «застревать» в центральной базе.
Рассмотрим, как диагностировать эту проблему, какие причины могут на нее влиять и как восстановить работоспособность механизмов обмена.
Прежде чем приступать к исправлению, необходимо убедиться, что причина именно в работе механизма обмена, а не в логике прикладного решения. Выполним следующие действия:
ЗарегистрироватьИзменения для набора записей проблемного регистра. Если после ручной регистрации записи успешно уходят в обмен, значит, механизм транспорта данных исправен, и проблема кроется исключительно в этапе автоматического формирования записей в таблице регистрации изменений (регистрация изменений объектов).подписок на события (особенно ПриЗаписи), которые могут выполняться при изменении набора записей. В некоторых случаях отраслевые конфигурации могут программно «сбрасывать» или отменять регистрацию изменений для определенных объектов.плане обмена не содержат условий фильтрации, которые исключают текущий набор записей из передачи в подчиненный узел.Если конфигурация не менялась, а проблема возникла после обновления, стоит обратить внимание на следующие факторы:
авторегистрации для независимых регистров. В частности, ошибки могут проявляться при определенных сочетаниях измерений и структуры метаданных.режима совместимости конфигурации при обновлении платформы приводит к тому, что механизм обмена начинает интерпретировать метаданные регистра иначе, пропуская его при регистрации.Тестирования и исправления (пункты «Пересчет итогов» и «Реструктуризация таблиц»).Как показывает практика, наиболее частой причиной внезапной остановки регистрации данных в РИБ после обновления платформы является внутренняя ошибка движка 1С. В таких случаях исправлением кода конфигурации проблему не решить.
Рассмотрим алгоритм действий при подтверждении ошибки платформы:
bugboard.v8.1c.ru и поищите информацию о наличии ошибок, связанных с авторегистрацией (например, ошибку 000117546).Если по каким-то причинам обновление платформы невозможно, или проблема носит специфический характер, можно реализовать принудительную регистрацию с помощью расширения конфигурации.
Разберем создание подписки на событие в расширении:
подписку на событие для события ПриЗаписи всех наборов записей проблемного регистра.ЗарегистрироватьИзменение для нужного плана обмена.Пример программной реализации регистрации изменений:
Процедура ПриЗаписиНабораЗаписей(Источник, Отказ)
// Определяем узлы, в которые нужно передать данные
Выборка = ПланыОбмена.ВашПланОбмена.Выбрать();
Пока Выборка.Следующий() Цикл
Если Выборка.Ссылка <> ПланыОбмена.ВашПланОбмена.ЭтотУзел() Тогда
// Регистрируем изменения для конкретного узла
ПланыОбмена.ЗарегистрироватьИзменения(Выборка.Ссылка, Источник.Отбор.ВашеИзмерение.Значение);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Использование расширения позволяет управлять процессом регистрации изменений, не затрагивая основной код конфигурации. Это наиболее безопасный способ «починить» обмен в условиях, когда стандартный механизм авторегистрации работает нестабильно. Однако помните, что основной рекомендацией всегда остается переход на версию платформы, в которой исправлены подобные системные ошибки.
Проанализируйте логи технологического журнала, чтобы увидеть, происходят ли вообще вызовы процедур записи в таблицу регистрации изменений при сохранении набора записей. Это даст окончательный ответ: игнорирует ли платформа событие или оно не возникает вовсе.