Как использовать свойство {КлючПоискаИБВИсточнике} для синхронизации объектов в Конвертации данных 2.0?

Программист 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

При настройке сложных обменов данными между конфигурациями, такими как ЗУП 3.1 и УПП 1.3, разработчики часто сталкиваются с необходимостью не просто сопоставить объекты, но и зафиксировать эту связь в специализированных регистрах. В старых конфигурациях на базе обычных форм (УПП, КА 1.1) для этих целей используется регистр сведений СоответствиеОбъектовДляОбмена. Чтобы типовой механизм загрузки автоматически создавал записи в этом регистре, используется системный маркер {КлючПоискаИБВИсточнике}. Разберем подробно, как заставить этот механизм работать, несмотря на ограничения визуального редактора конфигурации «Конвертация данных 2.0».

Зачем нужно свойство {КлючПоискаИБВИсточнике}?

Проанализируем ситуацию: когда мы передаем данные из одной информационной базы в другую, стандартный поиск по внутреннему идентификатору (GUID) может не сработать, если объекты создавались независимо. Типовая обработка УниверсальныйОбменДаннымиВФорматеXML при наличии в правилах поля {КлючПоискаИБВИсточнике} выполняет особую логику. Она считывает уникальный идентификатор объекта из базы-источника и, если объект успешно найден или создан в базе-приемнике, записывает связь в регистр соответствия. Это позволяет в будущем однозначно идентифицировать объект, даже если его реквизиты поиска (например, ИНН или Наименование) изменятся.

Проблема визуального редактора Конвертации данных

Основная сложность, которую мы обсудим, заключается в том, что в конфигурации «Конвертация данных 2.0» невозможно просто так добавить правило конвертации свойства (ПКС) с именем {КлючПоискаИБВИсточнике} и отметить его флагом «Поиск». Редактор проверяет наличие такого реквизита в метаданных конфигурации-приемника. Поскольку это поле виртуальное и системное, в метаданных его нет, и программа выдает ошибку или просто не позволяет установить нужную галочку. При этом простая передача значения через параметры объекта (ПараметрыОбъекта) не решает проблему, так как алгоритм загрузки ищет это значение именно в структуре свойств поиска, а не в параметрах.

Решение 1: Ручная правка файла правил (XML)

Рассмотрим наиболее эффективный, хоть и «ручной» способ решения проблемы. Если визуальный интерфейс блокирует наши действия, мы можем обойти его на уровне самого файла правил обмена.

  1. В конфигурации «Конвертация данных» создадим ПКС для нужного объекта (ПКО). В качестве Имени свойства приемника укажем точно: {КлючПоискаИБВИсточнике} (обязательно в фигурных скобках).
  2. Источник оставим пустым, но в обработчике «Перед выгрузкой» напишем код для передачи GUID источника:
  3. Значение = Строка(Источник.УникальныйИдентификатор());
  4. Сохраним правила обмена в файл XML.
  5. Откроем полученный XML-файл в любом текстовом редакторе (например, Notepad++). Найдем наш узел ПКС с именем {КлючПоискаИБВИсточнике}.
  6. Внутри этого узла найдем атрибут Поиск="false" и вручную заменим его на Поиск="true".
  7. Сохраним файл и будем использовать его для обмена. Теперь при загрузке механизм увидит это поле как поисковое и активирует логику работы с регистром соответствий.

Решение 2: Программное добавление в обработчике «Поля поиска»

Если мы не хотим каждый раз править XML вручную, проанализируем возможность внедрения в процесс через программные обработчики. В ПКО существует обработчик «Поля поиска». В нем нам доступна коллекция СвойстваПоиска, которая представляет собой Соответствие.

Выясним причину, почему простая вставка в СвойстваПоиска иногда не срабатывает. Это происходит из-за того, что типовая обработка загрузки инициализирует поиск только по тем полям, которые в XML помечены как поисковые. Однако мы можем попробовать «обмануть» систему следующим кодом:


// В обработчике "Поля поиска"
// Допустим, мы передали UID через параметр объекта
Если ПараметрыОбъекта <> Неопределено Тогда
    UIDИсточника = ПараметрыОбъекта.Получить("ИдентификаторИсточника");
    Если ЗначениеЗаполнено(UIDИсточника) Тогда
        СвойстваПоиска.Вставить("{КлючПоискаИБВИсточнике}", UIDИсточника);
    КонецЕсли;
КонецЕсли;

// Важно: чтобы этот обработчик вообще вызвался, в ПКО должно быть 
// хотя бы одно другое поле, отмеченное для поиска!

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

Особенности для обмена между ЗУП 3 и УПП 1.3

При работе с ЗУП 3 и УПП 1.3 следует учитывать разницу платформ. ЗУП работает на 8.3 в режиме управляемых форм, а УПП — это зачастую 8.2 или 8.3 в режиме обычных форм. Проанализируем важный нюанс: формат передачи GUID. В коде УПП часто ожидается, что соответствие — это либо строка, либо ссылка. При передаче значения в свойство {КлючПоискаИБВИсточнике} лучше принудительно преобразовывать его в строку в обработчике «Перед выгрузкой» на стороне источника:

Значение = СтрЗаменить(Строка(Источник.УникальныйИдентификатор()), " ", "");

Это гарантирует, что на стороне приемника (УПП) при парсинге XML не возникнет конфликтов типов и процедура записи в регистр СоответствиеОбъектовДляОбмена получит корректные строковые данные для формирования связи.

Почему нельзя просто использовать «После загрузки»?

Часто предлагают реализовать поиск и запись в регистр в обработчике «После загрузки». Разберем, почему это не всегда оптимально:

Таким образом, использование свойства {КлючПоискаИБВИсточнике} — это мощный инструмент для обеспечения ссылочной целостности между базами. Несмотря на сложности с интерфейсом «Конвертации данных», ручная правка XML или грамотное использование обработчика «Поля поиска» позволяют полностью автоматизировать процесс сопоставления объектов.

← На главную