При настройке или тестировании обмена данными часто возникает специфическая задача: необходимо создать полную копию «той стороны» обмена (базы корреспондента), имея на руках только одну базу. В такой ситуации мы сталкиваемся с тем, что признак ЭтотУзел в плане обмена установлен для нашей текущей базы, а нам нужно «превратить» копию в базу заказчика или партнера. Простое изменение реквизита в форме часто блокируется платформой, а ручное редактирование кодов может привести к рассинхронизации номеров сообщений. Разберем подробно, как правильно организовать контур обмена и какими методами можно сменить основной узел.
Признак ЭтотУзел в планах обмена 1С — это не просто логическое поле (булево). Это уникальное состояние таблицы базы данных. Платформа на уровне ядра жестко контролирует, чтобы в каждом конкретном плане обмена ровно один элемент обладал этим признаком. Рассмотрим причины, по которым стандартные обработки редактирования реквизитов часто выдают ошибку «Не найдена запись для ЭтотУзел»:
ОбменДанными.Загрузка = Истина, контроль за наличием основного узла может сохраняться, так как это системная константа для механизмов регистрации изменений.Вместо того чтобы пытаться изменить реквизит как обычное поле через записи объектов, проанализируем возможности встроенного языка. Существует специализированный метод менеджера планов обмена, который корректно переназначает основной узел, соблюдая все внутренние механизмы платформы.
Для смены узла «А» на узел «Б» нам необходимо выполнить небольшой фрагмент кода в обработке или консоли кода:
// Определяем ссылку на узел, который должен стать основным (например, код "Б")
НовыйОсновнойУзел = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("Б");
Если Не НовыйОсновнойУзел.Пустая() Тогда
Попытка
// Используем штатный метод для переназначения признака ЭтотУзел
ПланыОбмена.УстановитьОсновнойУзел(НовыйОсновнойУзел);
Сообщить("Основной узел успешно изменен на: " + НовыйОсновнойУзел);
Исключение
Сообщить("Ошибка при смене узла: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
Этот метод автоматически снимет признак ЭтотУзел с предыдущего элемента и установит его новому, не вызывая конфликтов целостности БД.
Если обмен настроен через правила обмена (КД 2.0) или универсальный формат (XDTO), синхронизация между базами чаще всего происходит по Коду узла. В этом случае мы можем пойти по пути «обмана» системы, не меняя физически, какой объект является «ЭтимУзлом», а просто поменяв местами их идентификаторы.
Разберем этот процесс по шагам:
ЭтотУзел имеет код «А», а узел корреспондента — код «Б».ЭтотУзел) на временный, например, «ВРЕМ».Таким образом, физический объект, который был основным, теперь имеет код удаленной базы, и наоборот. Важно помнить: этот метод сработает только в том случае, если правила обмена ищут узлы исключительно по коду. Если в настройках обмена жестко прописаны ссылки (GUID), потребуется дополнительная обработка «Поиск и замена значений».
После смены ролей узлов вы неизбежно столкнетесь с ошибкой «Сообщение обмена было ранее принято» или «Номер сообщения меньше или равен ранее принятому». Это происходит потому, что счетчики отправленных и принятых сообщений в вашей копии настроены на старую схему работы.
Проанализируем ситуацию: в базе «А» счетчик отправленных был 1000, а принятых — 500. При превращении ее в базу «Б», она должна «ожидать» сообщение номер 1001 и «считать», что сама отправила 500. Чтобы выровнять нумерацию, необходимо вручную отредактировать реквизиты узлов:
НомерОтправленногоНомерПринятогоДля корректной работы можно использовать внешние обработки (например, «Инструменты разработчика») или выполнить простой код:
ОбъектУзла = УзелКорреспондент.ПолучитьОбъект();
ОбъектУзла.НомерОтправленного = 0; // Сбрасываем для начала нового цикла или ставим нужное число
ОбъектУзла.НомерПринятого = 0;
ОбъектУзла.Записать();
Если ваша конфигурация построена на базе БСП (Библиотека стандартных подсистем), помните, что номера сообщений могут кэшироваться в регистрах сведений. В таких случаях может потребоваться очистка или корректировка данных в соответствующих регистрах состояния обмена.
Выясним причину, почему в распределенных информационных базах (РИБ) все сложнее. В РИБ признак ЭтотУзел напрямую связан с конфигурацией. Смена узла там без изменения параметра ГлавныйУзел (через ПланыОбмена.УстановитьГлавныйУзел()) лишит базу возможности получать обновления конфигурации (.cf). Если же вы работаете с обычным обменом, обратите внимание на следующие нюансы:
_ChangeRec) остается привязанной к ссылке узла. Если вы хотите, чтобы данные начали выгружаться «с чистого листа», регистрацию лучше очистить.ЭтотУзел «битая» или их стало два. Она принудительно восстанавливает корректную привязку в системных таблицах.Таким образом, наиболее безопасным и «чистым» способом является использование программного метода УстановитьОсновнойУзел в сочетании с ручной корректировкой номеров сообщений в зависимости от того, какие данные были в исходной базе заказчика.