При работе с механизмом EnterpriseData (универсальный формат обмена данными) программисты часто сталкиваются с вопросом: насколько жестко регламентированы так называемые «ключевые свойства» в пакетах XDTO? Существует мнение, что они носят рекомендательный характер, однако практика показывает, что игнорирование этих полей ведет к серьезным сбоям в логике обмена. Разберем детально, как устроены эти механизмы, почему иногда удается выгрузить данные без ключей и к каким последствиям в базе-приемнике это приводит.
Для начала определимся с терминологией. В универсальном формате обмена под ключевыми свойствами понимается набор полей, которые позволяют однозначно идентифицировать объект в информационной базе. Например, для справочника Контрагенты ключевыми свойствами обычно выступают ИНН и КПП (или Наименование, если ИНН не заполнен), а для документов — Номер и Дата.
С технической точки зрения ключевые свойства в пакете XDTO имеют настройку Возможно пустое = Ложь и Минимальное количество = 1. Это означает, что на уровне структуры XML-схемы эти поля обязательны для присутствия в файле. Если поле помечено как ключевое, оно формирует фундамент для поиска объекта в базе-приемнике.
Рассмотрим ситуацию, когда в самописной базе или нетиповой конфигурации создаются правила обмена, и при выгрузке данных ключевое свойство оказывается пустым, но система не выдает ошибку. Выясним причину такого поведения. В 1С механизм выгрузки через XDTO может работать в двух режимах:
Проверить(). Если обязательное свойство не заполнено, система прерывает процесс с ошибкой несоответствия схеме XDTO.ЗаписатьXDTO() без предварительной проверки. В этом случае платформа сформирует XML-файл, «проигнорировав» требования схемы. Именно поэтому на практике можно увидеть файлы, в которых отсутствуют обязательные по логике поля.Проанализируем пример, когда разработчик в модуле менеджера обмена обходит стандартные проверки БСП. Если в конфигурации-источнике свойство вообще отсутствует (например, в справочнике нет реквизита ИНН), а в формате EnterpriseData оно заявлено как ключевое, выгрузка без программной «заглушки» или отключения валидации должна завершиться аварией.
Теперь посмотрим, что происходит на стороне базы-приемника, когда туда попадает такой «неполноценный» файл. Стандартные алгоритмы загрузки, используемые в типовых конфигурациях (например, 1С:ERP или 1С:Бухгалтерия 3.0), ведут себя следующим образом:
Во-первых, происходит сбой идентификации. Поля поиска, настроенные в правилах конвертации объектов (ПКО) внутри Конвертации данных 3.0, опираются именно на ключевые свойства. Если ключевого свойства нет в файле, код поиска не сможет составить запрос к базе данных.
Во-вторых, риск появления дублей. Если система настроена на создание новых объектов при неудачном поиске, то отсутствие ключа приведет к тому, что при каждой загрузке будет создаваться новый элемент, так как найти старый по «пустым» признакам невозможно.
В-третьих, программная ошибка. В большинстве случаев при чтении файла через СериализаторXDTO база-приемник выдаст исключение: «Значение не соответствует типу...» или «Не найдено обязательное свойство». Это происходит потому, что приемник, в отличие от источника, обычно выполняет проверку входящих данных на соответствие пакету XDTO.
В конфигурации «Конвертация данных 3.0» мы управляем процессом обмена через настройку ПКО (Правил конвертации объектов) и ПВД (Правил выгрузки данных). Рассмотрим, как правильно обрабатывать ключевые свойства:
ПередВыгрузкой или ПриОтправке модуля менеджера обмена.Посмотрим на пример кода, который позволяет подставить значение, если оно отсутствует в реквизитах объекта:
// В модуле менеджера обмена
Процедура ПКО_Справочник_Контрагенты_Отправка_ПриОтправке(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Если в базе нет ИНН, но формат его требует как ключевое
Если Не ЗначениеЗаполнено(ДанныеИБ.ИНН) Тогда
// Реализуем логику заполнения по умолчанию или генерации временного ключа
ДанныеXDTO.ИНН = "0000000000";
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует, что файл будет валидным с точки зрения структуры XDTO, хотя и может потребовать дополнительной логики поиска на стороне приемника.
Подводя итог техническому анализу, можно утверждать следующее: ключевые свойства обязательны для корректной работы штатных механизмов обмена. Аргумент о том, что они являются «рекомендованными», ошибочен и обычно основан на том, что система позволяет технически сформировать некорректный XML-файл при отключении проверок.
Рассмотрим рекомендации для разработчиков, внедряющих обмен через универсальный формат в нетиповые конфигурации:
minOccurs="1"), оно должно быть передано.Таким образом, понимание работы XDTO и механизмов идентификации БСП позволяет избежать конфликтов при интеграции различных информационных систем и гарантирует целостность данных при обмене.