При настройке сложных обменов данными между конфигурациями, такими как ЗУП 3.1 и УПП 1.3, разработчики часто сталкиваются с необходимостью не просто сопоставить объекты, но и зафиксировать эту связь в специализированных регистрах. В старых конфигурациях на базе обычных форм (УПП, КА 1.1) для этих целей используется регистр сведений СоответствиеОбъектовДляОбмена. Чтобы типовой механизм загрузки автоматически создавал записи в этом регистре, используется системный маркер {КлючПоискаИБВИсточнике}. Разберем подробно, как заставить этот механизм работать, несмотря на ограничения визуального редактора конфигурации «Конвертация данных 2.0».
Проанализируем ситуацию: когда мы передаем данные из одной информационной базы в другую, стандартный поиск по внутреннему идентификатору (GUID) может не сработать, если объекты создавались независимо. Типовая обработка УниверсальныйОбменДаннымиВФорматеXML при наличии в правилах поля {КлючПоискаИБВИсточнике} выполняет особую логику. Она считывает уникальный идентификатор объекта из базы-источника и, если объект успешно найден или создан в базе-приемнике, записывает связь в регистр соответствия. Это позволяет в будущем однозначно идентифицировать объект, даже если его реквизиты поиска (например, ИНН или Наименование) изменятся.
Основная сложность, которую мы обсудим, заключается в том, что в конфигурации «Конвертация данных 2.0» невозможно просто так добавить правило конвертации свойства (ПКС) с именем {КлючПоискаИБВИсточнике} и отметить его флагом «Поиск». Редактор проверяет наличие такого реквизита в метаданных конфигурации-приемника. Поскольку это поле виртуальное и системное, в метаданных его нет, и программа выдает ошибку или просто не позволяет установить нужную галочку. При этом простая передача значения через параметры объекта (ПараметрыОбъекта) не решает проблему, так как алгоритм загрузки ищет это значение именно в структуре свойств поиска, а не в параметрах.
Рассмотрим наиболее эффективный, хоть и «ручной» способ решения проблемы. Если визуальный интерфейс блокирует наши действия, мы можем обойти его на уровне самого файла правил обмена.
{КлючПоискаИБВИсточнике} (обязательно в фигурных скобках).
Значение = Строка(Источник.УникальныйИдентификатор());
{КлючПоискаИБВИсточнике}.Поиск="false" и вручную заменим его на Поиск="true".Если мы не хотим каждый раз править XML вручную, проанализируем возможность внедрения в процесс через программные обработчики. В ПКО существует обработчик «Поля поиска». В нем нам доступна коллекция СвойстваПоиска, которая представляет собой Соответствие.
Выясним причину, почему простая вставка в СвойстваПоиска иногда не срабатывает. Это происходит из-за того, что типовая обработка загрузки инициализирует поиск только по тем полям, которые в XML помечены как поисковые. Однако мы можем попробовать «обмануть» систему следующим кодом:
// В обработчике "Поля поиска"
// Допустим, мы передали UID через параметр объекта
Если ПараметрыОбъекта <> Неопределено Тогда
UIDИсточника = ПараметрыОбъекта.Получить("ИдентификаторИсточника");
Если ЗначениеЗаполнено(UIDИсточника) Тогда
СвойстваПоиска.Вставить("{КлючПоискаИБВИсточнике}", UIDИсточника);
КонецЕсли;
КонецЕсли;
// Важно: чтобы этот обработчик вообще вызвался, в ПКО должно быть
// хотя бы одно другое поле, отмеченное для поиска!
Посмотрим на пример внимательнее: этот метод сработает только в том случае, если в правилах взведен флаг «Продолжить поиск по полям поиска, если по идентификатору объект не найден». В этом случае обработка вызовет наш код, мы дополним структуру поиска системным полем, и УПП сможет корректно отработать процедуру ПроцедурыОбменаДанными.ЗаписатьСоответствиеОбъектов().
При работе с ЗУП 3 и УПП 1.3 следует учитывать разницу платформ. ЗУП работает на 8.3 в режиме управляемых форм, а УПП — это зачастую 8.2 или 8.3 в режиме обычных форм. Проанализируем важный нюанс: формат передачи GUID. В коде УПП часто ожидается, что соответствие — это либо строка, либо ссылка. При передаче значения в свойство {КлючПоискаИБВИсточнике} лучше принудительно преобразовывать его в строку в обработчике «Перед выгрузкой» на стороне источника:
Значение = СтрЗаменить(Строка(Источник.УникальныйИдентификатор()), " ", "");
Это гарантирует, что на стороне приемника (УПП) при парсинге XML не возникнет конфликтов типов и процедура записи в регистр СоответствиеОбъектовДляОбмена получит корректные строковые данные для формирования связи.
Часто предлагают реализовать поиск и запись в регистр в обработчике «После загрузки». Разберем, почему это не всегда оптимально:
Таким образом, использование свойства {КлючПоискаИБВИсточнике} — это мощный инструмент для обеспечения ссылочной целостности между базами. Несмотря на сложности с интерфейсом «Конвертации данных», ручная правка XML или грамотное использование обработчика «Поля поиска» позволяют полностью автоматизировать процесс сопоставления объектов.