Как работает алгоритм поиска объектов при отправке и получении в Конвертации данных 3.0 (EnterpriseData)?

При переходе с конфигурации «Конвертация данных 2.1» на «Конвертацию данных 3.0» (работающую на базе формата EnterpriseData) разработчики часто сталкиваются с непониманием архитектуры сопоставления объектов. В интерфейсе правил конвертации объектов (ПКО) при настройке направления «Отправка и получение» можно увидеть настройки полей поиска, из-за чего возникает вопрос: какой вариант поиска приоритетнее — заданный при выгрузке из базы-источника или при загрузке в базу-приемник?

Архитектурная концепция EnterpriseData: разделение источника и приемника

Разберем фундаментальное отличие КД 3.0 от КД 2.1. В старой версии правила создавались для конкретной пары баз («Источник — Приемник»), а алгоритмы поиска жестко зашивались в общий файл правил. В «Конвертации данных 3.0» правила разрабатываются для одной конкретной конфигурации относительно универсального формата (XML/JSON):

1. Выгрузка (конфигурация → формат): объект информационной базы сериализуется в структуру данных EnterpriseData. В результирующее сообщение помещаются только реквизиты объекта и его уникальный идентификатор (UUID). Никаких алгоритмов поиска в выгружаемом сообщении нет.
2. Загрузка (формат → конфигурация): база-приемник читает входящий пакет данных и самостоятельно принимает решение, как именно найти или создать соответствующий объект в своей структуре.

Таким образом, настройки поиска, указанные в правилах для сценария выгрузки, при обработке данных в базе-приемнике не используются и игнорируются. Поиск объектов всегда осуществляется исключительно по алгоритмам и правилам, сгенерированным в общем модуле МенеджерОбменаЧерезУниверсальныйФормат принимающей базы.

Порядок сопоставления объектов при получении данных

Рассмотрим, как именно база-получатель выполняет поиск и идентификацию входящих элементов при загрузке. Процесс состоит из нескольких строгих этапов:

1. Проверка регистра соответствий: в первую очередь система обращается к регистру сведений Соответствия объектов информационных баз. Если в регистре уже зафиксирована связь «узел обмена + идентификатор источника = ссылка приемника», то поиск завершается мгновенно, а сопоставление по полям пропускается.
2. Поиск по уникальному идентификатору (UUID): если записи в регистре нет, система может выполнить поиск объекта по его исходному GUID (если данная опция включена в настройках ПКО).
3. Поэтапный поиск по полям (ПКО): если объект не найден по идентификаторам, запускается последовательный поиск по ключевым полям в порядке их приоритета (например: сначала ИНН + КПП, затем только ИНН, затем Наименование). Как только соответствие найдено по одному из наборов полей, поиск прекращается.
4. Создание нового объекта: если все варианты поиска завершились неудачно, создается новый элемент информационной базы, а его ссылка связывается с идентификатором источника в регистре соответствий для последующих обменов.

Программная кастомизация поиска в событиях ПКО

Проанализируем события-обработчики, которые можно использовать в КД 3.0 для переопределения логики сопоставления:

1. Событие «Перед поиском»: вызывается до начала стандартного поиска. В нем можно программно выполнить произвольный запрос и сразу вернуть найденную ссылку.
2. Событие «Поля поиска»: позволяет динамически изменить состав ключевых полей в таблице СтрокаТаблицыПоиска в зависимости от значений входящих данных.
3. Событие «После поиска»: выполняется после завершения алгоритмов поиска и позволяет проверить корректность найденного объекта или скорректировать его свойства.

Посмотрим на пример переопределения логики в обработчике «Перед поиском», когда необходимо найти элемент по нестандартному условию и прервать типовой поиск:

// ВходящиеДанные содержат структуру свойств из формата EnterpriseData
Если Не ПустаяСтрока(ВходящиеДанные.Артикул) Тогда
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ ПЕРВЫЕ 1
        |	Номенклатура.Ссылка КАК Ссылка
        |ИЗ
        |	Справочник.Номенклатура КАК Номенклатура
        |ГДЕ
        |	Номенклатура.Артикул = &Артикул
        |	И НЕ Номенклатура.ПометкаУдаления";
    
    Запрос.УстановитьПараметр("Артикул", ВходящиеДанные.Артикул);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        СсылкаНаОбъект = Выборка.Ссылка;
        ПрекратитьПоиск = Истина;
    КонецЕсли;
КонецЕсли;

Важные практические нюансы при настройке правил

Выясним основные проблемы, с которыми можно столкнуться при отладке правил поиска в КД 3.0:

1. Кэширование сопоставлений: если объект хотя бы один раз сопоставился ошибочно, корректировка правил поиска в ПКО не исправит старые связи. Для пересопоставления необходимо вручную очистить ошибочную запись в регистре Соответствия объектов информационных баз.
2. Поиск по пустым полям: если в правилах указан поиск по реквизиту (например, Артикул или Код), а во входящем объекте этот реквизит не заполнен, система может найти первый попавшийся элемент с пустым значением. Для предотвращения таких коллизий обязательно проверяйте заполненность полей в обработчиках поиска.
3. Составные поля и владельцы: при поиске по подчиненным справочникам (например, ДоговорыКонтрагентов с поиском по владельцу и номеру) убедитесь, что ссылка на объект-владелец корректно идентифицирована до момента начала поиска подчиненного элемента.