Работа с внешними веб-сервисами и сложными структурами данных в 1С часто требует импорта XSD-схем в дерево метаданных. Однако многие разработчики сталкиваются с досадной проблемой: при загрузке основной схемы типы, описанные во внешних (зависимых) файлах, превращаются в anyType (http://www.w3.org/2001/XMLSchema). Это происходит даже в тех случаях, когда все необходимые схемы, казалось бы, уже загружены в конфигурацию по отдельности. В этой статье мы подробно разберем причины такого поведения платформы и изучим несколько надежных способов импорта, которые позволят сохранить строгую типизацию.
Прежде чем переходить к решениям, проанализируем ситуацию. Механизм импорта в Конфигураторе 1С работает по строгому алгоритму. Когда система встречает тег xs:import, она пытается разрешить ссылку на пространство имен. Если в теге указан только атрибут namespace, но отсутствует корректный schemaLocation, или если путь в этом атрибуте недоступен в момент импорта, платформа «сдается» и заменяет неизвестный тип на универсальный anyType.
Важно понимать, что Конфигуратор не всегда автоматически сопоставляет импортируемое пространство имен с уже существующими в метаданных XDTO-пакетами. Для него каждый процесс импорта — это изолированная операция чтения файлов. Рассмотрим основные стратегии преодоления этой проблемы.
Рассмотрим самый простой и эффективный способ исправления ситуации в режиме проектирования (в Конфигураторе). Чтобы 1С корректно «подцепила» все зависимости, нам нужно подготовить файлы схем определенным образом.
.xsd файлы в одну локальную папку на вашем диске.xs:import. Убедитесь, что для каждого импорта указан атрибут schemaLocation, и он содержит только имя файла (относительный путь), если файлы лежат в одной папке.Например, если ваша схема Blocks зависит от ApiCommonTypes, описание импорта должно выглядеть так:
<xs:schema xmlns:ns1="ApiCommonTypes" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="Blocks">
<xs:import namespace="ApiCommonTypes" schemaLocation="ApiCommonTypes.xsd"/>
...
</xs:schema>
При импорте в 1С выберите основной файл. Система, видя относительный путь в schemaLocation, автоматически прочитает соседние файлы в той же директории и создаст соответствующие XDTO-пакеты с корректными связями. Внимание: если вы будете загружать схемы по одной вручную через контекстное меню «Импорт схемы XSD», связи могут не восстановиться.
Зачастую работа с XDTO-пакетами в дереве метаданных избыточна или приводит к ошибкам при обновлении конфигурации. Проанализируем альтернативный подход — создание фабрики XDTO непосредственно в коде приложения. Этот метод считается более стабильным, так как платформа при создании фабрики из массива схем гораздо лучше сопоставляет типы.
Для этого метода нам потребуется сохранить тексты XSD-схем в макеты (тип «Текстовый документ» или «Двоичные данные»). Разберем по шагам, как инициализировать такую фабрику:
// 1. Создадим массив для хранения схем
МассивСхем = Новый Массив;
// 2. Читаем схемы из макетов и добавляем в массив
Для Каждого ИмяМакета Из СписокИменМакетов Цикл
МакетСхемы = ПолучитьМакет(ИмяМакета);
// Если макет текстовый, используем ЧтениеXML.УстановитьСтроку()
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.УстановитьСтроку(МакетСхемы.ПолучитьТекст());
// Создаем построитель схем XML
ПостроительСхем = Новый ПостроительСхемXML;
Схема = ПостроительСхем.Прочитать(ЧтениеXML);
МассивСхем.Добавить(Схема);
КонецЦикла;
// 3. Создаем фабрику XDTO, передавая ей весь массив схем одновременно
// Платформа сама свяжет импорты между схемами в массиве
ПользовательскаяФабрика = СоздатьФабрикуXDTO(МассивСхем);
Этот метод позволяет избежать проблем с регистрами имен и путями к файлам, так как все определения типов уже находятся в памяти в виде объектов СхемаXML. Мы рекомендуем использовать этот подход для интеграций со сторонними API, которые часто меняют свои протоколы.
Если вам все же необходимо иметь пакеты именно в метаданных, попробуйте создать вспомогательный файл wrapper.xsd. Это пустая схема, которая не содержит своих типов, но импортирует все остальные схемы проекта.
Пример структуры такой схемы:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://tempuri.org/wrapper">
<xs:import namespace="ApiCommonTypes" schemaLocation="ApiCommonTypes.xsd"/>
<xs:import namespace="RefTypes" schemaLocation="RefTypes.xsd"/>
<xs:import namespace="Blocks" schemaLocation="Blocks.xsd"/>
</xs:schema>
Попробуем загрузить этот «фасад» в 1С. В большинстве случаев платформа успешно выстроит дерево зависимостей и создаст сразу все необходимые пакеты. После этого саму «обертку» можно удалить из конфигурации, а созданные пакеты останутся и будут корректно ссылаться друг на друга.
Выясним, какие еще факторы могут приводить к потере типов, даже если файлы подготовлены правильно:
targetNamespace указан как "MyNamespace", а в другой импорт идет по "mynamespace", система посчитает их разными и установит anyType.targetNamespace. Всегда старайтесь задавать уникальный URI для своих типов.В самых тяжелых случаях, когда структура зависимостей слишком запутана, мы можем прибегнуть к методу «Flattening». Существуют специализированные утилиты (например, XSD-Flatten), которые объединяют разрозненные файлы в один гигантский .xsd. В таком файле все типы находятся в одном пространстве имен или описаны линейно, что полностью исключает использование xs:import. Этот метод гарантирует 100% результат загрузки в 1С, хотя и делает схему менее читаемой для человека.
Подводя итог, можно сказать: наиболее надежным способом для разработчика является программное создание фабрики через массив объектов СхемаXML. Если же пакеты нужны в дереве метаданных, ключевым фактором успеха станет наличие корректных относительных путей в schemaLocation и одновременная загрузка всех файлов из одной папки.