При настройке интеграции и обмена данными между конфигурациями 1С (например, между УПП и ERP) разработчики часто сталкиваются с необходимостью передавать реквизиты, которые были добавлены не в основную конфигурацию, а через механизмы расширений. Это обусловлено нежеланием администраторов и архитекторов менять типовое решение, чтобы не усложнять последующие обновления системы.
Однако при попытке получить структуру метаданных для программы Конвертация данных (версий 2.1 или 3.0) с помощью стандартной обработки MD83Exp.epf у специалистов нередко возникают трудности: добавленные реквизиты просто «не видны» в выгруженном файле. В рамках этой статьи мы подробно разберем, почему так происходит, как работает платформа с метаданными расширений и как правильно настроить процесс выгрузки, избежав досадных ошибок.
Для начала разберем важную техническую особенность работы платформы 1С:Предприятие 8.3. Когда пользователь или разработчик запускает клиентский сеанс (в режиме Предприятие), система динамически формирует единую объединенную структуру метаданных.
В этот момент глобальный контекст Метаданные собирает воедино:
Поскольку выгрузка структуры метаданных через обработку MD83Exp.epf выполняется непосредственно в режиме 1С:Предприятие, эта обработка обращается к стандартной коллекции через методы платформы. Ей не требуются специализированные аналоги. Стандартная обработка сама по себе способна прочитать и выгрузить реквизиты расширений, так как они уже встроены в общую программную модель текущего сеанса. Но почему тогда разработчики регулярно заявляют, что реквизиты «не считываются»?
Практический опыт показывает, что отсутствие реквизитов расширения в итоговом файле .xml почти всегда связано с организационными ошибками разработчика или особенностями окружения. Проанализируем основные сценарии, приводящие к этой проблеме:
MD83Exp.epf в копиях баз данных, где расширение еще не подключено, отключено перед обновлением, либо база запущена в безопасном режиме, блокирующем часть функционала. В таком случае в контексте Метаданные новые реквизиты физически отсутствуют, и обработка их не выгружает.Конвертацию данных файл конфигурации-приемника вместо источника..cf непосредственно из Конфигуратора, объекты расширения туда гарантированно не попадут. Расширения хранятся изолированно в файлах формата .cfe и не смешиваются с основным конфигурационным файлом на уровне диска.Рассмотрим небольшой пример кода, демонстрирующий, как в коде обработки можно проверить доступность реквизита расширения через глобальный контекст:
// Проверим программно, видит ли сеанс добавленный реквизит документа
ИмяДокумента = "РеализацияТоваровУслуг";
ИмяРеквизита = "Расш_ДополнительныйМетодДоставки";
ДокументМетаданные = Метаданные.Документы[ИмяДокумента];
Если ДокументМетаданные.Реквизиты.Найти(ИмяРеквизита) <> Неопределено Тогда
Сообщить("Успешно: Реквизит расширения найден в структуре метаданных сеанса!");
Иначе
Сообщить("Ошибка: Реквизит не найден. Проверьте активность расширения в этой базе.");
КонецЕсли;
Чтобы гарантированно выгрузить реквизиты расширения для последующей настройки правил обмена в Конвертации данных 2.1, выполним следующие шаги:
1С:Предприятие под пользователем с полными правами.MD83Exp.epf через меню Файл — Открыть.ERP_With_Extensions.xml).Конвертации данных стандартным способом. Все реквизиты расширения успешно отобразятся в дереве метаданных.Если интеграция строится по технологии универсального формата обмена (EnterpriseData) в КД 3.0, то подход к загрузке метаданных меняется кардинально. В современных версиях этой конфигурации разработчики отказываются от использования внешней обработки MD83Exp.epf.
Выясним, как правильно поступать в этом случае:
Конвертации данных 3.0 предусмотрен специализированный инструмент загрузки XDTO-пакетов расширений формата. При настройке сопоставления свойств обязательно отслеживайте версии схем обмена и используйте регистр взаимосвязей версий формата для корректной трансляции добавленных реквизитов.При проектировании систем интеграции важно понимать жизненный цикл данных, которые хранятся в объектах и реквизитах, созданных внутри расширений. Проанализируем последствия различных действий администратора:
Сценарий 1: Отключение расширения (снятие признака «Активно»).
В этом случае данные физически остаются в таблицах СУБД (например, MS SQL Server или PostgreSQL). Платформа просто перестает отображать эти реквизиты в интерфейсе и скрывает их из объектной модели. При повторной активации расширения все накопленные данные снова станут доступны без потерь.
Сценарий 2: Удаление расширения из списка в базе данных.
Это наиболее опасное действие. При удалении записи расширения из системы платформа выполняет реструктуризацию базы данных и физически удаляет (дропает) соответствующие таблицы и колонки из СУБД. Все накопленные данные по этим реквизитам будут безвозвратно утеряны.
Сценарий 3: Замена файла расширения (.cfe) новым файлом.
Если новое расширение содержит те же внутренние идентификаторы (GUID) и имена объектов, данные сохранятся. Однако если при разработке новой версии объекта или реквизита в расширении его создали «с нуля» вместо изменения существующего (даже при совпадении имени), уникальный идентификатор изменится, что приведет к очистке старых данных при обновлении расширения.
Рекомендация по безопасности: Перед любым обновлением, изменением или удалением расширений, содержащих уникальные реквизиты с данными, обязательно создавайте резервную копию базы данных (бэкап) или выгружайте информацию с помощью обработки «Универсальный обмен данными в формате XML» во временный файл!