При работе с инструментом «1С:Конвертация данных 3.0» (КД 3.0) разработчики часто сталкиваются с тем, что привычные механизмы, работающие для справочников и документов, не применимы к константам. Основная сложность заключается в том, что архитектура обмена через EnterpriseData и сама конфигурация КД 3.0 ориентированы на ссылочные типы данных. Константы, не имея уникального идентификатора (GUID) и ссылки, выпадают из стандартного цикла «выгрузка — сопоставление — загрузка».
В данной статье мы подробно разберем, почему возникает эта проблема, проанализируем ограничения системы и рассмотрим несколько эффективных способов передачи констант между базами.
Если мы попытаемся стандартным способом настроить правила конвертации объектов (ПКО) для констант, то обнаружим, что они отсутствуют в списках выбора объектов конфигурации. Проанализируем причину этого поведения. В конфигурации КД 3.0 механизмы загрузки структуры и фильтрации метаданных жестко ограничены запросами. Рассмотрим типичное условие, которое используется в обработках настройки обмена:
И (ОбъектыФормата.Наименование ПОДОБНО "Справочник.%" ИЛИ ОбъектыФормата.Наименование ПОДОБНО "Документ.%")
Как мы видим, интерактивная настройка обмена константами просто не предусмотрена разработчиками КД 3.0. Система ожидает объект, который обладает ссылкой (Ref), чтобы обеспечить уникальность данных. Поскольку константа — это одиночное значение, она не вписывается в модель «Объект формата — Объект конфигурации».
Самым элегантным и правильным с точки зрения архитектуры EnterpriseData способом является передача констант в качестве дополнительных данных (AdditionalInfo) к какому-либо ссылочному объекту, который гарантированно участвует в обмене. Чаще всего в качестве такого «контейнера» выбирают справочник Организации или Валюты.
Разберем реализацию этого метода по шагам:
Шаг 1. Выгрузка данных на стороне источника
В правилах конвертации объекта (например, для организации) в обработчике «При отправке» нам необходимо программно заполнить структуру дополнительных данных. Рассмотрим пример кода, где мы передаем дату начала использования новой системы из константы:
// В обработчике ПКО "Организация" -> При отправке
ДанныеXDTO.Вставить("AdditionalInfo", Новый Структура("ДатаНачалаРаботы", Константы.ДатаНачалаРаботы.Получить()));
Шаг 2. Прием данных на стороне приемника
На стороне базы-получателя нам нужно извлечь эти данные. В ПКО того же объекта (Организация) в обработчике «После загрузки» или «При внедрении» мы считываем структуру и записываем значение в соответствующую константу:
// В обработчике ПКО "Организация" -> После загрузки
Если ДанныеXDTO.Свойство("AdditionalInfo") Тогда
Если ДанныеXDTO.AdditionalInfo.Свойство("ДатаНачалаРаботы") Тогда
Константы.ДатаНачалаРаботы.Установить(ДанныеXDTO.AdditionalInfo.ДатаНачалаРаботы);
КонецЕсли;
КонецЕсли;
Этот метод хорош тем, что он не требует внесения изменений в XDTO-пакет и не ломает типовую логику конвертации.
Если констант много или они логически не привязаны ни к одному из существующих объектов, мы можем применить архитектурный маневр. Создадим в конфигурации технический справочник, например, НастройкиОбмена.
Проанализируем алгоритм работы в этом случае:
ПриЗаписи для каждой нужной константы. В обработчике подписки мы обновляем значение реквизита в нашем справочнике НастройкиОбмена.На стороне приемника при записи элемента справочника НастройкиОбмена мы прописываем код, который «раскладывает» значения реквизитов обратно по константам. Таким образом, мы обходим ограничение КД 3.0, превращая нессылочные данные в ссылочные.
Даже если мы решили передавать константы через AdditionalInfo, остается вопрос: как заставить систему инициировать обмен при изменении самой константы? Константы нельзя напрямую включить в состав плана обмена для автоматической регистрации.
Для решения этой задачи воспользуемся программным методом. Создадим подписку на событие ПриЗаписи для интересующих нас констант. Внутри обработчика будем принудительно регистрировать изменения для нашего «объекта-контейнера» (например, основной организации).
Рассмотрим пример кода регистрации:
Процедура ПриЗаписиКонстанты(Источник, Отказ) Экспорт
// Получаем узел плана обмена
УзелОбмена = НайтиНужныйУзел();
// Регистрируем изменения для "якорного" объекта, к которому привязана передача константы
ОсновнаяОрганизация = Справочники.Организации.НайтиПоРеквизиту("ИНН", "7700000000");
Если ЗначениеЗаполнено(ОсновнаяОрганизация) Тогда
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ОсновнаяОрганизация);
КонецЕсли;
КонецПроцедуры
Таким образом, как только пользователь изменит константу, система пометит Организацию к выгрузке, и при следующем сеансе обмена константа уедет в базу-приемник в структуре AdditionalInfo.
Если необходимо, чтобы константа фигурировала в XDTO-пакете как отдельный тип объекта (например, для сторонних систем), нам придется выполнить ряд манипуляций со схемой.
Проанализируем, как можно описать константу в пакете XDTO:
ConstantSettings.xs:string, xs:date или Key (для ссылочных констант).Catalog.ConstantSettings. После того как ПКО будет создано, имя типа в пакете можно вернуть к исходному, поправив XML-файл выгрузки структуры или используя расширения.Важный нюанс: Если константа хранит ссылку (например, СправочникСсылка.Организации), в XDTO-пакете ее свойство должно иметь тип Key, принятый в EnterpriseData для передачи ссылок. Если это простое число или дата, используйте стандартные типы XML Schema.
Подводя итог, можно сказать, что Конвертация данных 3.0 не предназначена для прямого обмена константами. Однако, используя гибкость платформы 1С, мы можем выбрать наиболее подходящий обходной путь:
Рассмотренные методы позволяют сохранить стабильность обмена и не прибегать к радикальным переработкам типовых механизмов 1С.