Пакеты XDTO в 1С: назначение, настройка и отличие от XDTO Tools

Пакет XDTO в 1С 8.3 — это объект метаданных конфигурации, который описывает структуру данных в терминах XML-схемы: пространство имён, типы объектов и их свойства. Через такой пакет платформа читает и пишет XML строго по заданным типам, а не как произвольный текст. Отсюда и его главная роль — типизированный обмен данными с веб-сервисами, внешними системами и универсальным форматом EnterpriseData.

XDTO Tools — это не часть платформы, а внешняя обработка (.epf), которой пользуются, чтобы визуально собрать пакет, сгенерировать XSD или протестировать сериализацию. Для работы с XDTO она не обязательна: то же самое делается штатными средствами конфигуратора и встроенного языка.

Пакет метаданных и обработка XDTO Tools — не одно и то же

Путаница почти всегда в одном: пакет и инструмент решают разные задачи.

Пакет XDTO — это часть вашей конфигурации. Он живёт в дереве метаданных, попадает в хранилище, переносится между базами вместе с конфигурацией и доступен из встроенного языка через глобальную фабрику ФабрикаXDTO. Это описание типов, которое платформа использует в рантайме.

XDTO Tools — сторонняя обработка, которую подключают как внешний файл. Она помогает:

• 🔧 собрать или отредактировать описание типов в удобном редакторе;
• 📄 выгрузить описание в файл XML-схемы (.xsd) и наоборот — разобрать чужую схему;
• 🧪 проверить, как объект сериализуется в XML и читается обратно.

Обработка ничего не добавляет в саму конфигурацию: она лишь ускоряет ручную работу. Если XDTO Tools нет под рукой, пакет полностью создаётся и настраивается конфигуратором. Поэтому выбор «пакет или инструмент» некорректен: пакет — это объект, инструмент — вспомогательная среда для его подготовки.

Вывод простой: без пакета обмен по схеме не построить, а без XDTO Tools — вполне.

Отдельно стоит сказать, когда с XDTO вообще не нужно связываться. Если обмен идёт между двумя базами 1С типовыми средствами (планы обмена, «Конвертация данных », синхронизация) — пакеты уже описаны в формате обмена, и трогать их руками не придётся. XDTO напрямую берут тогда, когда на другом конце не 1С: сторонний веб-сервис, портал, банковский шлюз или любая система, которая диктует свою XML-схему. Если же партнёр работает по REST и шлёт JSON, схема XDTO не нужна совсем — это сразу отсекает половину задач, где новички пытаются «натянуть» пакет туда, где он лишний.

Из чего состоит пакет: пространство имён, типы и свойства

Открыть структуру можно в конфигураторе: ветка Общие → XDTO-пакеты. Внутри одного пакета три уровня.

Пространство имён (namespace). У каждого пакета есть свойство с URI вида http://example.org/exchange. Это уникальный идентификатор набора типов. Именно по паре «пространство имён + имя типа» вы потом обращаетесь к типу из кода.

Типы объектов и типы значений. Тип объекта — это составная структура со своими свойствами (похож на запись или объект). Тип значения — простой или производный скалярный тип (строка с ограничением длины, число с точностью, перечисление допустимых значений).

Свойства типа объекта. У каждого свойства задаются:

Нижняя граница 1 делает свойство обязательным — без него XML не пройдёт проверку при чтении. Верхняя граница -1 означает неограниченную множественность (список элементов).

Чтобы было нагляднее, как форма XML влияет на результат: пусть у типа объекта Документ свойство Номер задано как атрибут, а Сумма — как элемент. Тогда объект ляжет в XML так:

<Документ Номер="0001">
  <Сумма>1500</Сумма>
</Документ>

Поменяли форму XML у Номер на «элемент» — и он переедет из атрибута в отдельный вложенный тег. Принимающая сторона ждёт конкретную форму, поэтому её согласуют заранее: несовпадение атрибута и элемента — типичная причина, почему «XML вроде правильный, а не читается».

Как создать пакет и импортировать XSD в конфигураторе

Два типовых сценария: описать структуру с нуля или подтянуть готовую схему от стороннего сервиса.

Создание вручную:

1. В дереве конфигурации правой кнопкой по ветке XDTO-пакеты → добавить новый пакет.
2. Задать имя пакета и его пространство имён (URI). URI согласуйте с принимающей стороной — он должен совпадать с тем, что ждёт внешняя система.
3. Добавить типы объектов, внутри каждого — свойства с типом, формой XML и границами.
4. Для полей со списком фиксированных значений завести тип значения с ограничением.

Импорт из XSD. Если партнёр по обмену прислал готовую XML-схему, её не нужно перебивать руками. В редакторе пакета есть команда импорта XML-схемы: выбираете файл .xsd, и платформа разворачивает его в типы и свойства пакета. После импорта пакет становится обычным объектом метаданных — его можно дорабатывать, переименовывать типы, менять границы.

Обмен данными через фабрику XDTO: чтение и запись XML

Вся работа в коде идёт через глобальную фабрику ФабрикаXDTO. Она знает все типы из пакетов конфигурации, поэтому для своих пакетов ничего дополнительно подключать не нужно.

Запись объекта в XML. Создаёте объект нужного типа, заполняете свойства, пишете через фабрику:

Тип = ФабрикаXDTO.Тип("http://example.org/exchange", "Документ");
Объект = ФабрикаXDTO.Создать(Тип);
Объект.Номер = "0001";
Объект.Дата  = ТекущаяДата();
Объект.Сумма = 1500;

Запись = Новый ЗаписьXML;
Запись.ОткрытьФайл(ПутьКФайлу, "UTF-8");
ФабрикаXDTO.ЗаписатьXML(Запись, Объект);
Запись.Закрыть();

Чтение XML обратно в объект. Тип указываете тот же — по пространству имён и имени:

Чтение = Новый ЧтениеXML;
Чтение.ОткрытьФайл(ПутьКФайлу);

Тип = ФабрикаXDTO.Тип("http://example.org/exchange", "Документ");
Объект = ФабрикаXDTO.ПрочитатьXML(Чтение, Тип);
Чтение.Закрыть();

Сообщить(Объект.Номер + " / " + Формат(Объект.Сумма, "ЧГ=0"));

Обратите внимание: число и строку нельзя складывать «как есть» — результат приводится через Формат() или СтрШаблон(), иначе будет ошибка типов.

Если внешняя схема приходит в рантайме и её нет в конфигурации, можно построить собственную фабрику конструктором Новый ФабрикаXDTO(...), передав ей набор схем. Для пакетов, описанных в конфигурации, это не требуется — хватает глобальной ФабрикаXDTO.

Отдельно стоит сериализатор СериализаторXDTO. Это не то же самое, что фабрика: он переводит в XML и обратно прикладные объекты базы — ссылки, документы, справочники. Его применяют в обменах по правилам и в выгрузках, когда нужно сохранить именно объект 1С, а не абстрактную структуру по схеме.

XDTO в веб-сервисах и HTTP-сервисах

Здесь различие между SOAP и REST принципиально.

Веб-сервисы (SOAP). Параметры операций веб-сервиса типизируются именно типами XDTO. Когда вы подключаете внешний сервис через WS-ссылку и указываете адрес его WSDL, платформа сама разбирает описание и создаёт XDTO-пакеты под все типы этого сервиса. Дальше вы работаете с ними как с обычными объектами XDTO — заполняете свойства параметра и вызываете операцию.

HTTP-сервисы (REST). Тело запроса и ответа здесь не типизируется автоматически — это произвольный поток. Если партнёр присылает XML, вы разбираете его сами: открываете ЧтениеXML на теле запроса и читаете через фабрику в объект нужного типа. Ответ формируете обратным способом. Для JSON-тел XDTO не нужен вовсе — там работают ЧтениеJSON и ЗаписьJSON.

Универсальный формат EnterpriseData, на котором построены типовые обмены между конфигурациями, — это тоже набор XDTO-пакетов. Когда вы настраиваете обмен в «Конвертации данных», под капотом происходит та же сериализация через XDTO: правила конвертации лишь сопоставляют объекты базы с типами формата.

Из этого следует практический момент: если типовой обмен падает на конкретном сообщении, смотреть нужно не только правила конвертации, но и соответствие данных типам формата. Нередко ошибка не в логике обмена, а в том, что в поле попало значение, которого схема EnterpriseData не допускает, — и валидация XDTO его отсекает ещё до правил.

Валидация данных и разбор ошибок

XDTO проверяет структуру при чтении. Если во входящем XML нет обязательного свойства (нижняя граница 1), не тот тип значения или лишний элемент не по схеме — ПрочитатьXML вызовет исключение. Это и есть встроенная валидация: вам не нужно сверять каждое поле руками, достаточно поймать ошибку.

Попытка
    Объект = ФабрикаXDTO.ПрочитатьXML(Чтение, Тип);
Исключение
    ЗаписьЖурналаРегистрации("Обмен.XDTO",
        УровеньЖурналаРегистрации.Ошибка, , ,
        "XML не соответствует схеме: " + ОписаниеОшибки());
    Возврат;
КонецПопытки;

Что полезно делать дополнительно:

• 📝 логировать текст ошибки через ОписаниеОшибки() и часть проблемного XML — без этого искать причину в чужом файле тяжело;
• 🔎 после чтения проверять заполненность необязательных, но важных для вас свойств (нижняя граница 0) — платформа их пропуск ошибкой не считает;
• 🧩 отделять ошибку разбора (битый XML) от бизнес-проверки (структура верна, но данные недопустимы) — это разные ветки обработки.

Как не потерять в скорости на больших объёмах

На мелких сообщениях XDTO работает незаметно. Проблемы начинаются на выгрузках в тысячи и десятки тысяч объектов, когда накладные расходы на каждый вызов множатся на количество записей.

Кэшируйте тип вне цикла. Вызов ФабрикаXDTO.Тип(...) внутри цикла на каждой итерации — лишняя работа. Получите тип один раз до цикла и используйте переменную.

Не пересоздавайте пользовательскую фабрику. Построение фабрики из набора схем в рантайме — дорогая операция. Если она нужна, создавайте её один раз и держите, а не собирайте заново на каждый вызов.

Для больших файлов читайте потоком. Загружать гигантский XML целиком в один объект XDTO — удар по памяти. Там, где структура позволяет, читайте документ по узлам через ЧтениеXML порциями, разбирая по одной записи.

Сериализатор объектов базы — порциями. СериализаторXDTO по тяжёлым документам в длинном цикле заметно грузит сервер. Дробите выгрузку на пакеты и, если возможно, выносите её в фоновое задание, а не в клиентский вызов.

Закрывайте потоки чтения и записи. Незакрытый ЧтениеXML или ЗаписьXML держит файл и память до конца транзакции. На единичном вызове это незаметно, на серии из тысяч файлов — утечка, которая валит фоновое задание.

Частые вопросы