При переходе на технологию Enterprise Data (Конвертация данных 3.0) многие разработчики сталкиваются с концептуальной сложностью: формат обмена ориентирован на объекты, имеющие уникальную ссылку (справочники, документы), в то время как независимые регистры сведений оперируют наборами записей без использования UUID. Стандартные механизмы БСП и КД 3.0 не предлагают прямого выбора регистра в интерфейсе правил регистрации или выгрузки. Рассмотрим, как обойти эти ограничения и настроить стабильный обмен. Для лучшего понимания базовых принципов можно использовать материал об основах Конвертации Данных 3 и формате Enterprise Data.
В «Конвертации данных 2.0» мы привыкли работать с правилами выгрузки данных (ПВД) для регистров напрямую. В версии 3.0 (ED) обмен строится вокруг XDTO-пакета. Если вы откроете редактор формата, вы увидите, что там описаны сущности, аналогичные объектам метаданных. Для реализации передачи регистра нам придется «притвориться», что запись регистра — это объект. Разберем по шагам, как это реализовать.
Первым делом проанализируем структуру нашего регистра. Поскольку у записи регистра нет ссылки, нам нужно определить ключевые свойства, по которым приемник поймет, какую именно запись нужно обновить или создать. Выясним причину: в XDTO-пакете для таких сущностей создается тип объекта, где:
Если вы используете расширение формата, добавьте новый ObjectType. Например, для регистра «ЦеныНоменклатуры» ключевыми полями будут Номенклатура, ВидЦены и Период. В приемнике БСП будет использовать эти поля для сопоставления записи в наборе. Для настройки подобных соответствий подойдет руководство по формированию мэппинга объектов при использовании формата EnterpriseData.
Посмотрим на ситуацию с точки зрения регистрации изменений. В ПРО для КД 3.0 нельзя просто выбрать регистр сведений как объект для выгрузки. Проанализируем два способа решения этой задачи:
Способ А: Регистрация через программный код. Мы включаем регистр в состав плана обмена. В модуле объекта регистра или через подписку на событие ПриЗаписи нам необходимо программно регистрировать изменения. Однако, так как в план обмена для регистра записывается набор, нам нужно передать информацию о том, какой именно «виртуальный объект» мы хотим выгрузить.
Способ Б: Использование обработчика «При регистрации» в ПРО. В самих правилах регистрации (которые настраиваются в КД 3.1) можно прописать логику, которая будет анализировать измененный набор записей и регистрировать «пустышку» или связанный объект. Рассмотрим пример кода для ручной регистрации записи в плане обмена:
ПланыОбмена.ЗарегистрироватьИзменения(УзелИнформационнойБазы, СсылкаНаОбъект);
// Но так как ссылки нет, часто регистрируют связанный объект (например, Номенклатуру),
// а в правилах выгрузки номенклатуры добавляют выгрузку записей регистра.
Разберем подробнее работу в модуле МенеджерОбменаЧерезУниверсальныйФормат. Здесь происходит основная магия преобразования данных 1С в структуру XDTO. Нам нужно переопределить стандартное поведение в методе ПОСЛЕ_ПОДГОТОВКИ_ДАННЫХ_ОБЪЕКТА или реализовать собственную выборку данных.
При выгрузке мы должны сформировать структуру, которая будет передана в XDTO-объект. Выглядит это примерно так:
// В обработчике выгрузки данных
ДанныеXDTO = Новый Структура;
ДанныеXDTO.Вставить("Номенклатура", ЗаписьРегистра.Номенклатура);
ДанныеXDTO.Вставить("Цена", ЗаписьРегистра.Цена);
ДанныеXDTO.Вставить("ВидЦены", ЗаписьРегистра.ВидЦены);
// Передаем структуру для формирования XDTO
При загрузке в базе-приемнике нам необходимо выполнить обратную операцию. Поскольку мы получаем объект, нам нужно программно записать его в регистр через РегистрСведенийНаборЗаписей. Выясним, как это сделать правильно:
ПослеЗагрузкиОбъекта) считываем значения измерений из структуры XDTO.
Набор = РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей();
Набор.Отбор.Номенклатура.Установить(ДанныеОбъекта.Номенклатура);
Набор.Отбор.ВидЦены.Установить(ДанныеОбъекта.ВидЦены);
НоваяЗапись = Набор.Добавить();
ЗаполнитьЗначенияСвойств(НоваяЗапись, ДанныеОбъекта);
Набор.Записать();
Это самый критичный момент. Если запись в регистре удалена, в приемник должно уйти сообщение об удалении. Рассмотрим решение: в формате Enterprise Data существует стандартный тип УдалениеОбъекта. Нам нужно при удалении записи регистра программно сформировать этот объект, передав в него ключевые свойства (измерения). В приемнике при получении удаления с такими ключевыми свойствами должен сработать код, очищающий соответствующий набор записей по фильтру.
Проанализируем «хитрый» прием, который часто упрощает жизнь разработчику. Чтобы не бороться с отсутствием ссылок в регистрах, в конфигурации создается служебный (пустой) справочник. Алгоритм работы следующий:
Спр_ОбменРегистромЦен).Этот метод позволяет использовать стандартные Правила Регистрации Объектов (ПРО) и типовой механизм удаления объектов БСП без написания сложного кода обхода ограничений регистров.
Мы выяснили, что работа с независимыми регистрами в КД 3.0 требует либо расширения формата XDTO с эмуляцией ключевых полей, либо использования промежуточных объектов-ссылок. Выбор метода зависит от частоты изменений и объема данных. Для простых регистров лучше всего подходит расширение XDTO, а для сложных систем синхронизации — метод с виртуальными справочниками-обертками.