Проблема
В системах 1С на базе БСП, таких как ЕРП/КА/УТ, предусмотрена система синхронизации данных, из которой можно развернуть узлы распределенной информационной базы. После очередного обновления конфигурации метаданные или логика работы могут быть изменены, что способно повлиять на сами данные, которые должны быть приведены в соответствие. Для этого запускаются обработчики обновления, которые и приводят данные в соответствие с новой конфигурацией. Эти обновленные данные мигрируют по узлам информационной базы согласно правилам обмена для обеспечения консистентности информационных баз.
Последовательность обновления данных рассмотрим на примере плана обмена из УТ11 "РИБ с фильтрами":
- Обновление данных в центральном узле;
- Выгрузка данных на узел и запуск обработчиков обновления на узлах;
- Загрузка в центральном узле файла с периферийного узла;
- Запуск в центральном узле всех! обработчиков обновления конфигурации;
Проблемное место — это пункт №4, на заглавной картинке таких обработчиков набралось 247. Зачастую обработчики написаны так, чтобы обновлять только незаполненные данные, которые они должны заполнить, то есть повторный запуск не должен приводить к перезаписи. Но логика может оказаться совсем иной: обработка снова запускается и повторяет ранее сделанные действия, что совсем нехорошо - съедается время, ресурсы. Ниже приведен пример такого обработчика из последних обновлений. Подобный обработчик будет запускаться постоянно при каждом последующем обновлении, так как просто с определенной даты регистрирует документы к обработке независимо от того, надо это или нет.
В общем случае, возможна такая ситуация, когда после обновления с узла могут прийти данные не обновленные и их надо повторно обновить именно только в центральном узле, так как, например, только в центральном узле предполагается наличие всех нужных данных. Однако если мы на момент обновления центральной базы и узла уверены, что на узле новых данных не появится и обмены последними новыми данными успешно завершены, то запускать пункт №4 смысла нет. В моем случае именно такой сценарий при каждом обновлении, поэтому далее рассмотрим как исключить пункт №4.
Вариант решения
Процесс повторного вызова всех обработчиков регулируется регистром сведений ОбработчикиСобытийСинхронизацииДанных. Именно в нем регистрируется повторный вызов обработчиков в центральном узле с именем обработчика ОбновлениеИнформационнойБазы:
Возможные решения состоят в том, чтобы либо не регистрировать это событие, либо не обрабатывать. Я выбрал второй путь, как он проще: наглядней и более читаемый. Обработчик находится в модуле менеджера указанного регистра сведений, через расширение меняем его логику, по сути нам нужно избежать вызова процедуры ОбновлениеИнформационнойБазыСлужебный.ПриПолученииПервогоСообщенияОбменаРИБПослеОбновления():
После исправления и проверке на демке УТ 11 версии 11.5.22.170 с переходом на 11.5.22.174, убеждаемся, что вызов с регистрацией и запуском всех обработчиков предыдущих версий не выполняется, и видим только обработчики текущего релиза (14 вместо 247):
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.22.174
Вступайте в нашу телеграмм-группу Инфостарт