В конфигурациях 1С на базе Библиотеки стандартных подсистем (БСП) для синхронизации данных применяется универсальный формат (EnterpriseData). Разработчики, привыкшие к конфигурации «Конвертация данных 2.0» (КД 2.0), часто сталкиваются с непониманием новой концепции: где хранятся правила, как их выгрузить, отредактировать и загрузить обратно в рабочую базу.
Разберем фундаментальные различия архитектуры, выясним причины изменений и подробно проанализируем основные подходы к доработке типовых правил обмена.
Архитектурные отличия КД 3.0 от КД 2.0
В классической КД 2.0 правила конвертации формировались в виде отдельного XML-файла и интерпретировались универсальной обработкой обмена. В КД 3.0 подход принципиально изменился:
Правила представляют собой исполняемый код: Алгоритмы конвертации компилируются в чистый программный код встроенного языка 1С и размещаются непосредственно внутри конфигурации — чаще всего в общем модуле МенеджерОбменаЧерезУниверсальныйФормат (или версионированных модулях, например, МенеджерОбменаЧерезУниверсальныйФормат1_11).
Роль конфигурации «Конвертация данных 3.0»: Сама КД 3.0 больше не участвует в непосредственном обмене данными. Она выступает исключительно специализированной средой разработки правил, из которой по итогу работы генерируется готовый текст модуля для вставки в базу.
Стандартизация формата: Обмен происходит через промежуточный формат XDTO (EnterpriseData), благодаря чему базы не знают структуры метаданных друг друга, а оперируют общими бизнес-сущностями.
Способ 1. Использование внешней обработки с модулем менеджера обмена
Рассмотрим популярный практический подход, позволяющий вносить изменения в правила и отлаживать их без постоянного обновления конфигурации через КД 3.0. Подсистема синхронизации БСП позволяет подключать внешний модуль менеджера обмена.
Разберем пошаговый порядок действий:
Создадим новую внешнюю обработку в конфигураторе.
Скопируем все содержимое типового общего модуля МенеджерОбменаЧерезУниверсальныйФормат из рабочей конфигурации в модуль объекта созданной внешней обработки.
Внесем необходимые правки в обработчики выборки данных, заполнения реквизитов или алгоритмы сопоставления объектов.
Подключим полученную обработку в настройках синхронизации данных (в узле плана обмена) вместо типового встроенного модуля.
Этот способ позволяет оперативно тестировать алгоритмы, используя конфигурацию КД 3.0 только в качестве справочника и средства навигации по объектам формата.
Способ 2. Доработка через расширение конфигурации
Если требуется сохранить типовую конфигурацию на полной поддержке без снятия с замка и избежать подключения внешних обработок, наиболее надежным решением выступает механизм расширений. Проанализируем, как это реализовать:
Добавим общий модуль МенеджерОбменаЧерезУниверсальныйФормат в расширение конфигурации.
С помощью аннотаций &Вместо, &После или &ИзменениеИКонтроль переопределим необходимые процедуры формирования данных или сопоставления.
Для событийной логики проверим наличие процедур в переопределяемом общем модуле ОбменДаннымиПереопределяемый, где доступны точки входа для регистрации данных и постобработки объектов.
Способ 3. Классическая разработка через конфигурацию КД 3.0
Если проект требует масштабных изменений структуры обмена, рассмотрим классический цикл разработки:
Выгрузим структуру метаданных конфигурации с помощью обработки MD83Exp.epf.
Выгрузим текущие правила из базы в формате модуля обмена. В типовом модуле часто реализована поддержка нескольких версий формата. Поэтому необходимо последовательно выгрузить и затем загрузить в КД 3.0 каждую поддерживаемую версию формата в одну и ту же конвертацию, чтобы результирующий модуль соответствовал типовой структуре.
Загрузим метаданные и правила в конфигурацию КД 3.0, настроим правила конвертации объектов (ПКО), свойств (ПКС) и предопределенных данных (ПКПД).
Сгенерируем готовый программный код модуля и перенесем его в общий модуль рабочей конфигурации или расширения.
Особенности выгрузки метаданных регистров сведений в MD83Exp.epf
При подготовке метаданных через обработку MD83Exp.epf разработчики нередко сталкиваются с тем, что регистры сведений (например, штрихкоды номенклатуры) по умолчанию не попадают в файл выгрузки. Выясним причину: в форме обработки часть настроек состава метаданных скрыта программно.
Посмотрим на пример доработки модуля формы обработки MD83Exp.epf для включения видимости скрытых настроек:
&НаКлиенте
Процедура ИзменитьРежимОбработки()
Элементы.ИмяФайлаВыгрузки.Доступность = Не ЭтоКлиент;
// Включаем видимость панели настроек состава метаданных:
Элементы.Настройки.Видимость = Истина;
КонецПроцедуры
После включения видимости панели настроек появится возможность явно отметить регистры сведений флагами для их корректной выгрузки в файл метаданных.
Важные ограничения формата EnterpriseData и версионирование
При доработке правил через программный код или КД 3.0 необходимо учитывать ключевые архитектурные ограничения:
Строгость схемы XDTO: Нельзя произвольно добавить реквизит в XML-сообщение, если его нет в утвержденной XSD-схеме EnterpriseData выбранной версии. Это вызовет ошибку валидации при чтении сообщения. Нестандартные данные передают либо через встроенную таблицу дополнительных реквизитов (ДополнительныеРеквизиты), либо через сериализацию в строковые поля (например, поле комментария), либо путем создания расширения пакета XDTO в обеих базах.
Согласование версии формата: Обмен данными всегда выполняется по минимальной общей версии формата, поддерживаемой обоими узлами. Если в базе-источнике изменения внесены только для версии формата 1.12, а база-приемник поддерживает формат только до версии 1.8, обмен будет выполнен по правилам версии 1.8, и новые алгоритмы не сработают. Изменения в коде следует дублировать во всех актуальных для обмена версиях формата.
Отладка алгоритмов: Так как правила представляют собой обычный код на языке 1С, их отладка осуществляется стандартным отладчиком платформы. Точки останова устанавливаются непосредственно в процедурах модуля менеджера обмена при интерактивном выполнении синхронизации или при включенной отладке фоновых заданий на сервере.