Как устроен и работает регистр ПубличныеИдентификаторыСинхронизируемыхОбъектов в 1С?

При переходе с механизмов обмена данными на базе Конвертации данных 2.0 (КД2) на обмен через универсальный формат EnterpriseData (КД3) разработчики сталкиваются с заменой привычного регистра сведений СоответствияОбъектовИнформационныхБаз на новый регистр — ПубличныеИдентификаторыСинхронизируемыхОбъектов. Разберем детально архитектуру этого регистра, логику поиска и сопоставления ссылок, а также ответим на ключевые вопросы его практического применения.

Судьба старого регистра соответствий и обратная совместимость

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

Структура регистра и обработка объектов с одинаковым GUID

Выясним, как разрешается ситуация, если в базе присутствуют разнотипные объекты с одинаковым внутренним идентификатором или когда внешняя система присылает один и тот же GUID для сущностей разного назначения. Например, когда из одной входящей накладной формируются два связанных объекта или исторически справочник физических лиц и контрагентов содержат элементы с одинаковым УникальныйИдентификатор().

Кажется, что отсутствие отдельного измерения типа данных должно приводить к коллизиям, однако это не так. Рассмотрим структуру хранения данных в регистре:

1. Измерение УзелИнформационнойБазы — ссылка на узел плана обмена.
2. Измерение Идентификатор — строковое представление публичного идентификатора (GUID).
3. Измерение Ссылка — составной тип (ЛюбаяСсылка).
4. Ресурс ОбъектФормата — строка, содержащая имя сущности в формате EnterpriseData.
5. Ресурс Основной — булево, определяющее приоритетное соответствие.

На уровне СУБД поле составного типа Ссылка физически раскладывается на три колонки: тип данных, код таблицы метаданных и бинарный идентификатор ссылки. Таким образом, ссылка на СправочникСсылка.Сотрудники и ссылка на ДокументСсылка.РеализацияТоваровУслуг с абсолютно одинаковыми GUID — это две совершенно разные записи в регистре. Поскольку первичный ключ формируется тройкой Узел + Идентификатор + Ссылка, конфликта уникальности записей не возникает.

Посмотрим, как отрабатывает типовой алгоритм поиска при загрузке данных:

1. Выполняется запрос к регистру сведений по фильтру Узел и Идентификатор. При этом ресурс ОбъектФормата должен совпадать с типом входящей сущности либо быть пустым.
2. Запрос возвращает набор ссылок. На этом этапе отсекаются неактуальные или удаленные объекты.
3. В коде типовой подсистемы обмена выполняется жесткая проверка типа полученной ссылки:

Если ТипЗнч(СсылкаИзРегистра) <> ТипОбъектаИБ Тогда
    Продолжить;
КонецЕсли;

Если в регистре сопоставления ничего не найдено, поиск выполняется напрямую через менеджер требуемого объекта методом ПолучитьСсылку(ГУИД), где тип метаданных также строго зафиксирован правилом конвертации.

В каких случаях запись в регистр публичных идентификаторов НЕ создается?

Разберем ситуации, при которых сопоставление не фиксируется в регистре:

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

Удаление ссылок и его влияние на регистр сопоставления

Проанализируем поведение системы при удалении данных:

1. Удаление в текущей информационной базе. При непосредственном физическом удалении объекта из базы каскадного удаления записи из регистра ПубличныеИдентификаторыСинхронизируемыхОбъектов средствами СУБД не происходит. В поле Ссылка образуется «битая ссылка» (<Объект не найден>). Очистка таких записей выполняется типовыми механизмами БСП: либо регламентными процедурами обслуживания, либо автоматически при следующем сеансе синхронизации, когда отбор отсеивает отсутствующую ссылку и зачищает запись регистра.
2. Удаление в базе-корреспонденте. Физическое удаление элемента в источнике не очищает автоматически регистр на стороне приемника. Чтобы удаление отразилось в другой базе, на узле плана обмена должна быть зарегистрирована регистрация удаления. В формате EnterpriseData формируется пакет с признаком удаления сущности. Если удаление выполнено напрямую в обход планов обмена или регистрация была очищена, запись в регистре корреспондента останется нетронутой.

Использование строковых идентификаторов внешних систем (например, Bitrix)

Рассмотрим возможность использования произвольных строковых ID (например, цифровых или текстовых кодов из CRM) в качестве идентификатора в регистре. В типовом механизме EnterpriseData поле Идентификатор строго ожидает строку формата UUID (36 символов, стандартизированных по RFC 4122).

Если передать произвольную строку и попытаться сгенерировать новую ссылку через вызов конструктора:

НовыйУИД = Новый УникальныйИдентификатор(СтрокаИдентификатора);

платформа вызовет фатальное исключение «Недопустимый формат». Для интеграции со сторонними сервисами применяются следующие подходы:

1. Хеширование идентификатора. Программное преобразование строкового ID внешней системы в детерминированный UUIDv5 или MD5 (16 байт в шестнадцатеричном представлении). В этом случае один и тот же внешний ключ всегда порождает валидный GUID.
2. Использование поля XML_ID. В типовых интеграциях с сайтами (включая 1С-Битрикс) сопоставление ведется по реквизиту XML_ID. При выгрузке из 1С туда помещается внутренний GUID системы, который затем возвращается обратно без необходимости преобразовывать внутренние числовые ID сайта.
3. Передача через расширенные свойства. Передача внешнего идентификатора в узле дополнительных сведений формата (AdditionalInfo), с последующим сопоставлением в алгоритме поиска ПКО по отдельному нетиповому регистру сведений.

Рекомендации по безопасному переходу с обмена КД2 на КД3

Перевод рабочей синхронизации со старых правил на формат EnterpriseData требует внимания, так как автоматического переноса записей из СоответствияОбъектовИнформационныхБаз в новый регистр платформа не выполняет. Если внутренние GUID объектов в базах не совпадали и связь держалась исключительно на таблице старого регистра, переход на новый обмен «с нуля» приведет к массовому дублированию данных.

Разберем по шагам безопасный порядок миграции:

1. Предварительный перенос соответствий. До запуска регулярного обмена напишем сервисную обработку, которая прочитает записи регистра СоответствияОбъектовИнформационныхБаз по нужному узлу и создаст эквивалентные записи в ПубличныеИдентификаторыСинхронизируемыхОбъектов, заполнив корректный ОбъектФормата.
2. Первый запуск в интерактивном режиме. Настроим первую синхронизацию через форму сопоставления данных БСП с отключенной опцией автоматического создания новых элементов. Это позволит вручную проконтролировать нераспознанные объекты.
3. Корректировка состава изменений. Проверим таблицу регистрации изменений нового узла плана обмена и снимем с регистрации исторические документы и неизмененные справочники, чтобы не перегружать каналы связи повторной выгрузкой всей базы.