Переход с привычной «Конвертации данных 2.0» на версию 3.0 часто вызывает вопросы у разработчиков, особенно в части передачи произвольных данных, которые не предусмотрены стандартными реквизитами объектов. В КД 2.0 мы привыкли использовать узел AdditionalInfo (ДополнительнаяИнформация), куда можно было поместить любую структуру или значение. В КД 3.0, работающей на базе формата Enterprise Data, структура файла обмена жестко описана XSD-схемой, и просто так добавить новое поле «в лоб» не получится. Чтобы быстрее освоить архитектурные особенности обмена на БСП, можно использовать руководство по концепции обмена в Конвертации данных 3.0.
В этой статье мы разберем, как бороться с отсутствием AdditionalInfo, рассмотрим альтернативные механизмы передачи данных и изучим конкретные примеры кода для реализации обмена нестандартными реквизитами.
Проанализируем архитектурное различие. В КД 2.0 правила определяют саму структуру XML. Вы могли создать любое ПКС (Правило Конвертации Свойства), назвать его как угодно, и оно попадало в файл. В КД 3.0 обмен строится вокруг формата Enterprise Data. Это значит, что сначала описывается формат (XDTO-пакет), а затем объекты конфигурации «подтягиваются» к этому формату. Если в схеме XDTO для конкретного типа объекта (например, Справочник.Номенклатура) не предусмотрено поле AdditionalInfo, то платформа просто не даст вам его выгрузить стандартными средствами.
Однако задачи по передаче дополнительных признаков (например, специфических данных для алкогольной продукции или особых меток для логистики) остаются. Рассмотрим основные пути решения этой задачи.
Самый гибкий способ передать данные, не меняя саму схему XDTO (если это допустимо логикой формата), — это использование механизма ДополнительныеСвойства объекта и соответствующих обработчиков в модуле менеджера или правилах конвертации объектов (ПКО).
Рассмотрим по шагам процесс передачи данных на примере номенклатуры и специфических данных о виде алкогольной продукции.
Шаг 1. Отправка данных (сторона источника)
На стороне базы-отправителя нам нужно перехватить момент формирования данных XDTO. Мы используем обработчик ПКО_Справочник_Номенклатура_Отправка_ПриОтправкеДанных. Здесь мы можем вручную дозаполнить структуру ДанныеXDTO, если схема позволяет вставить данные в существующие узлы, или подготовить данные для передачи через доступные поля.
Посмотрим на пример кода:
// В обработчике ПриОтправкеДанных
Если Выборка.Следующий() И Выборка.АлкогольнаяПродукция Тогда
// Заполняем основные свойства из выборки
ЗаполнитьЗначенияСвойств(ДанныеXDTO, Выборка);
// Формируем структуру с доп. данными, которых нет в типовых реквизитах
ДанныеВидАК = Новый Структура("Код, Наименование, ВидЛицензии",
Выборка.ВидАлкогольнойПродукции_Код,
Выборка.ВидАлкогольнойПродукции_Наименование,
Выборка.ВидАлкогольнойПродукции_ВидЛицензии);
// Вставляем данные в узел XDTO, если схема это поддерживает
// (например, через расширение схемы или использование подходящего по типу поля)
ДанныеXDTO.Вставить("ВидАлкогольнойПродукции", ДанныеВидАК);
КонецЕсли;
Шаг 2. Получение данных (сторона приемника)
На стороне базы-приемника нам нужно извлечь эти данные из входящего сообщения XDTO до того, как объект будет записан. Для этого используется обработчик ПКО_Справочник_Номенклатура_Получение_ПриКонвертацииДанныхXDTO.
Важный момент: данные из XDTO мы помещаем не напрямую в реквизиты объекта, а в ДополнительныеСвойства получаемого объекта. Это позволит нам обратиться к ним позже, например, в событии ПередЗаписью.
// В обработчике ПриКонвертацииДанныхXDTO
Если ДанныеXDTO.Свойство("АлкогольнаяПродукция") И ДанныеXDTO.АлкогольнаяПродукция Тогда
Если ДанныеXDTO.Свойство("ВидАлкогольнойПродукции") Тогда
// Помещаем данные во временное хранилище объекта
ПолученныеДанные.ДополнительныеСвойства.Вставить("ВидАлкогольнойПродукции", ДанныеXDTO.ВидАлкогольнойПродукции);
КонецЕсли;
КонецЕсли;
Шаг 3. Обработка перед записью
Теперь, когда данные лежат в ДополнительныеСвойства, мы можем извлечь их в обработчике ПКО_Справочник_Номенклатура_Получение_ПередЗаписьюПолученныхДанных и выполнить необходимые действия (например, поиск или создание связанных элементов в справочниках).
// Извлекаем данные из ДополнительныхСвойств
ПолученныеДанные_ВидАлкогольнойПродукции = ПолученныеДанные.ДополнительныеСвойства.ВидАлкогольнойПродукции;
ВидАлкогольнойПродукции_Код = "";
Если ПолученныеДанные_ВидАлкогольнойПродукции.Свойство("Код") Тогда
ВидАлкогольнойПродукции_Код = ПолученныеДанные_ВидАлкогольнойПродукции.Код;
КонецЕсли;
// Далее следует логика поиска объекта в базе по коду или иным признакам
Во многих современных версиях формата Enterprise Data (начиная с 1.5 и выше) для большинства ссылочных объектов предусмотрен табличный узел ДополнительныеРеквизиты. Рассмотрим, как это можно использовать.
Этот узел предназначен для интеграции с подсистемой «Дополнительные отчеты и обработки» из БСП. Если вам нужно передать простое значение «Ключ — Значение», выясним, нет ли возможности передать его именно туда. Это более «штатный» путь с точки зрения логики 1С, так как он не требует модификации XSD-схемы.
Проанализируем ситуацию: если вы используете типовые конфигурации, то при заполнении коллекции ДополнительныеРеквизиты в ДанныеXDTO, на стороне приемника БСП сама попытается сопоставить эти данные с имеющимися в базе дополнительными сведениями или реквизитами.
Если проект масштабный и передавать данные через «костыли» в виде ДополнительныеСвойства неудобно, стоит рассмотреть вариант создания собственного расширения для XDTO-пакета EnterpriseData.
EnterpriseData_1_16_1).AdditionalInfo с типом string или AnyType).Этот способ является самым чистым с технической точки зрения, так как он делает передачу данных явной и типизированной. Однако он требует внесения изменений в конфигурацию (путь и через расширение) на обеих сторонах обмена.
Разберем несколько нюансов, которые помогут избежать ошибок при реализации обмена:
ДополнительныеРеквизиты — это часть схемы данных Enterprise Data (обычно табличная часть). ДополнительныеСвойства — это свойство программного объекта 1С (типа Структура), которое существует только в памяти во время работы кода.Подводя итог, можно сказать: отсутствие AdditionalInfo в КД 3.0 — это не ошибка, а следствие перехода к строгой типизации данных. Используя обработчики ПриОтправкеДанных и ПриКонвертацииДанныхXDTO в связке с ДополнительнымиСвойствами, вы сможете передать любую информацию, сохранив при этом гибкость и надежность обмена. Для отладки и проверки работы написанного в обработчиках кода можно использовать инструмент для генерации внешней обработки правил КД 3.0.