При работе с механизмами синхронизации данных в 1С (поможет обработка для управления регистрацией объектов обмена), особенно в конфигурациях на базе Библиотеки стандартных подсистем (БСП), часто возникает специфическая проблема при попытке настроить обмен между основной рабочей базой и её точной копией. Система выдает ошибку «Обнаружено зацикливание синхронизаций». Рассмотрим подробнее, почему это происходит и как устранить данную коллизию, не прибегая к радикальному изменению префиксов документов.
Для начала проанализируем ситуацию: механизм обмена через формат EnterpriseData обладает встроенной защитой от бесконечной пересылки одних и тех же данных по кругу. В современных версиях БСП (начиная с 3.0) реализован алгоритм «Контура синхронизации». Суть его заключается в том, что в каждое сообщение обмена (XML-файл) упаковывается массив уникальных идентификаторов всех информационных баз, через которые прошел объект.
Когда база-приемник получает пакет данных, она проверяет этот массив. Если она обнаруживает в списке свой собственный уникальный идентификатор (UID), система делает вывод: «Эти данные я уже отправляла или они уже проходили через меня, значит, возникло кольцо». В случае с копией базы ситуация осложняется тем, что при обычном копировании (через SQL или файловый 1Cv8.1CD) копия наследует абсолютно все внутренние идентификаторы оригинала. Таким образом, база-копия «считает» себя той же самой базой, что и источник.
Ошибочно полагать, что зацикливание определяется только по префиксу информационной базы (например, «ЦБ» или «УТ»). Для системы критичны следующие параметры:
Простое изменение префикса в настройках не всегда решает проблему, так как внутренние связи в регистрах остаются прежними. Посмотрим на последовательность шагов, необходимых для исправления ситуации.
Первым делом нам необходимо сделать так, чтобы копия базы получила новый, уникальный GUID, отличный от оригинала. Этот идентификатор обычно хранится в составе константы ПараметрыАдминистрированияИБ. Если мы не изменим его, никакие манипуляции с планами обмена не помогут.
Выполним программный код во внешней обработке или через консоль кода в базе-копии:
// Создаем новый менеджер значения для константы параметров администрирования
МенеджерЗначения = Константы.ПараметрыАдминистрированияИБ.СоздатьМенеджерЗначения();
МенеджерЗначения.Прочитать();
// Устанавливаем новый уникальный идентификатор для текущей базы
МенеджерЗначения.ИдентификаторИнформационнойБазы = Новый УникальныйИдентификатор();
МенеджерЗначения.Записать();
Сообщить("Идентификатор информационной базы успешно обновлен.");
Важный момент: Эту операцию следует проводить только в копии базы. После выполнения кода рекомендуется перезагрузить сеанс 1С.
Даже после смены идентификатора базы в системе могут остаться записи о прошлых обменах, которые «тянут» за собой старые связи (от таких коллизий спасает обработка удаления дублей в синхронизированных базах). Регистр сведений КонтурыСинхронизации (в метаданных может называться InformationRegister.SynchronizationContours) хранит цепочки идентификаторов.
Разберем, как его очистить:
После очистки система начнет строить «дерево» прохождения объектов заново, уже с учетом нового UID базы, который мы задали на первом шаге.
Теперь проанализируем настройки самих планов обмена. В каждой базе (источнике и приемнике) есть элемент Этот узел. Распространенная ошибка при копировании — оставить коды «Этого узла» одинаковыми в обеих базах.
Для успешной работы должна соблюдаться следующая логика:
Этого узла — «ОРИГ», а код узла-приемника — «КОПИЯ».Этого узла — «КОПИЯ», а код узла-источника — «ОРИГ».Если в базе-копии вы не можете сменить префикс из-за уже созданных документов, попробуйте сменить именно Код узла в плане обмена. Код узла и префикс номеров документов в 1С — это разные сущности, хотя часто они совпадают по умолчанию.
Система 1С хранит информацию о том, какие данные были успешно получены и отправлены, в регистре СостоянияОбменаДанными. При копировании базы записи из этого регистра копируются вместе со всеми данными. Это приводит к тому, что база-приемник «думает», что она уже успешно загрузила те пакеты, которые на самом деле были загружены оригиналом.
Проанализируем ситуацию: если в регистре висит запись о получении сообщения №150, а источник присылает файл с номером 151, но при этом внутренние идентификаторы баз конфликтуют, БСП может выдать ошибку зацикливания, пытаясь защитить целостность данных.
Рекомендуется в базе-копии очистить записи в регистре Состояния успешного обмена данными для конкретного узла. Это заставит систему инициализировать обмен «с чистого листа» — проверить результат поможет инструмент сравнения данных между базами 1С.
Рассмотрим специфику «Эха» при односторонней синхронизации. Даже если вы настроили выгрузку только в одну сторону (из оригинала в копию), транспортный механизм (особенно через каталог) все равно предполагает наличие ответного файла с квитанцией о приеме. Если идентификаторы баз в ПараметрыАдминистрированияИБ совпадают, то база-источник, прочитав ответную квитанцию от «самой себя» (как она думает), может заблокировать дальнейший обмен.
Итоговый чек-лист для решения проблемы:
UUID базы через Константы.ПараметрыАдминистрированияИБ.Контуры синхронизации.Код (не путать с наименованием) элемента Этот узел в плане обмена уникален для каждой из баз.Помните, что использование Группового изменения реквизитов позволяет быстро проверить и изменить коды узлов в планах обмена, если они заблокированы для редактирования в стандартном интерфейсе. Обязательно включите отображение служебных реквизитов в настройках обработки, чтобы увидеть поле Код.