Механизм XDTO в 1С: пакеты, фабрика и сериализация

XDTO — это встроенная в платформу 1С:Предприятие 8 система типов для работы со структурированными данными. Если коротко: механизм даёт описать данные строгой схемой, а потом превращать их в XML и обратно, не разбирая теги вручную.

Расшифровывается как eXtensible Data Transfer Objects — «расширяемые объекты передачи данных». Под капотом лежит язык XML Schema (XSD): каждый тип XDTO соответствует типу в схеме. Из-за этой строгой типизации структуру XDTO применяют там, где нужен жёсткий контракт данных — в веб-сервисах, HTTP-сервисах, планах обмена и формате EnterpriseData.

Разберём по порядку: из чего состоит пакет, как собрать его в конфигураторе, чем XDTO отличается от «сырого» XML и от JSON и как сериализовать прикладные объекты прямо из встроенного языка.

Как устроен XDTO: типы, свойства и пространства имён

В основе механизма — два вида типов. Понимание разницы между ними снимает половину вопросов.

• 🔤 Тип значения (ТипЗначенияXDTO) — простой тип без внутренней структуры. Это аналог simpleType в XSD: строка, целое число, дата, булево. У него нет дочерних свойств, только значение.
• 🧱 Объектный тип (ОбъектныйТипXDTO) — сложный тип со свойствами. Аналог complexType. Именно из объектных типов собирают описание документа, контрагента, строки табличной части.

У объектного типа есть набор свойств (СвойствоXDTO). Каждое свойство имеет имя, тип и форму представления в XML — элемент (Элемент, отдельный тег) или атрибут (Атрибут, значение внутри открывающего тега). Форма влияет только на то, как значение ляжет в XML, а не на его смысл.

Все типы живут в пространстве имён (namespace). Пространство задаётся строкой URI, например http://v8.1c.ru/data. URI — это не адрес в интернете, а уникальный идентификатор: по паре «URI + имя типа» платформа однозначно находит нужный тип.

Форму представления видно по итоговому XML. Допустим, у объектного типа Контрагент свойство ИНН описано как атрибут, а Наименование — как элемент. Тогда на выходе получится примерно так:

<Контрагент ИНН="7700000000">
  <Наименование>ООО Ромашка</Наименование>
</Контрагент>

Поменяете форму свойства ИНН на элемент — и ИНН переедет из открывающего тега в отдельную строку внутри блока. Смысл данных не меняется, меняется только их раскладка в XML. Это важно, когда внешняя система ждёт строго определённый вид документа.

Пакеты XDTO в дереве конфигурации

Все типы собираются в пакеты. Пакет — это контейнер, который хранит один набор типов под общим пространством имён. В конфигураторе пакеты лежат в ветке Общие → Пакеты XDTO.

Чтобы описать свою структуру данных вручную:

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

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

Пакеты, которые платформа использует для собственных нужд (например, для обмена), часто идут в конфигурации уже готовыми — их не нужно создавать с нуля.

Как платформа строит типы: импорт XSD и WSDL

Описывать пакет вручную — только один из путей. Чаще типы попадают в конфигурацию автоматически, и это важная часть ответа на вопрос про «генерацию кода».

• 📥 Импорт XML-схемы. Если у вас есть готовый XSD-файл от внешней системы, его содержимое можно загрузить в пакет XDTO. Платформа разберёт схему и создаст соответствующие типы и свойства.
• 🌐 WS-ссылка. При добавлении WS-ссылки (ветка Общие → WS-ссылки) конфигуратор читает WSDL-описание внешнего веб-сервиса и сам формирует пакеты XDTO по всем типам, объявленным в этом описании.
• 🛠 Собственный веб-сервис. Когда вы публикуете веб-сервис из 1С, платформа строит его WSDL на основе тех пакетов XDTO, что вы указали в типах параметров операций.

Отдельных файлов с классами, как в «классической» генерации кода на стороне Java или .NET, здесь нет. Типы XDTO существуют внутри платформы, а доступ к ним даёт фабрика — через неё создаются объекты и выполняется чтение-запись. Фактически роль «сгенерированных классов» играет пара «пакет + фабрика».

У каждого веб-сервиса и WS-ссылки своя локальная фабрика, которая знает только их типы. Для типов конфигурации используют глобальную фабрику.

Фабрика XDTO: создаём и читаем объекты в коде

Фабрика — точка входа для работы с типами из встроенного языка. Глобальный объект называется ФабрикаXDTO. Её основные методы:

• Тип(URIПространстваИмен, Имя) — получить объект типа по пространству имён и имени.
• Создать(ТипXDTO) — создать новый экземпляр объекта этого типа.
• ЗаписатьXML(ЗаписьXML, ОбъектXDTO) — записать объект в поток XML.
• ПрочитатьXML(ЧтениеXML, ТипXDTO) — прочитать объект из потока XML.

Создание объекта и запись его в строку XML выглядят так:

ТипОбъекта = ФабрикаXDTO.Тип("http://example.org/data", "Контрагент");
Объект = ФабрикаXDTO.Создать(ТипОбъекта);
Объект.Наименование = "ООО Ромашка";
Объект.ИНН = "7700000000";

Запись = Новый ЗаписьXML;
Запись.УстановитьСтроку();
ФабрикаXDTO.ЗаписатьXML(Запись, Объект);
СтрокаXML = Запись.Закрыть();

Обратная операция — разобрать входящий XML в типизированный объект:

Чтение = Новый ЧтениеXML;
Чтение.УстановитьСтроку(СтрокаXML);
Объект = ФабрикаXDTO.ПрочитатьXML(Чтение, ТипОбъекта);

Наименование = Объект.Наименование;
ИНН = Объект.ИНН;

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

Сериализация прикладных объектов через СериализаторXDTO

Отдельная задача — превратить в XML прикладной объект: ссылку на элемент справочника, документ, запись регистра. Для этого есть глобальный СериализаторXDTO (XDTOSerializer), который знает, как разложить объекты конфигурации по типам XDTO.

Запись = Новый ЗаписьXML;
Запись.УстановитьСтроку();
СериализаторXDTO.ЗаписатьXML(Запись, СсылкаНаКонтрагента);
Результат = Запись.Закрыть();

Чтение возвращает объект обратно:

Чтение = Новый ЧтениеXML;
Чтение.УстановитьСтроку(Результат);
Значение = СериализаторXDTO.ПрочитатьXML(Чтение);

Разница между фабрикой и сериализатором простая. Фабрика работает с типами, которые вы сами описали в пакете или импортировали из схемы. Сериализатор автоматически сопоставляет прикладные типы 1С (справочники, документы, перечисления) с их XDTO-представлением — вручную описывать пакет под них не нужно.

Сериализатор удобен для выгрузки и загрузки данных: сохранить ссылку в строку, передать во внешнюю систему, восстановить объект в другой базе. На нём же во многом построены типовые механизмы обмена.

Один нюанс при переносе между базами. Сериализатор сохраняет ссылки по внутреннему идентификатору (GUID). Чтобы восстановленный объект лёг на существующий элемент, в принимающей базе должен быть элемент с тем же идентификатором, иначе ссылка окажется «битой». Для обмена с сопоставлением по реквизитам (ИНН, код) чистого сериализатора мало — там и нужны правила обмена поверх XDTO.

XDTO, обычный XML и JSON: что когда выбирать

XDTO часто сравнивают с «просто XML» и с JSON. Сравнение не совсем корректное: это разные уровни. XML и JSON — форматы представления данных, а XDTO — система типов над XML. Но на практике выбор между механизмами стоит, поэтому сведём их в таблицу.

Ключевая мысль: XDTO даёт гарантию формата. Если данные не соответствуют схеме, вы получите ошибку на этапе чтения, а не кривой результат где-то дальше по коду. За это платите тем, что схему нужно заранее описать.

Прямой разбор XML и работа с JSON гибче и быстрее стартуют, но контроль структуры — на вас.

Где XDTO применяется в интеграции

На практике разработчик сталкивается с XDTO в нескольких сценариях:

• 🔌 SOAP-веб-сервисы. Параметры операций и возвращаемые значения описываются типами XDTO. Платформа строит по ним WSDL, а клиент — свои объекты.
• 📡 WS-ссылки. Обращение из 1С к внешнему веб-сервису: пакеты XDTO создаются автоматически по WSDL поставщика.
• 🔁 Планы обмена и EnterpriseData. Универсальный формат обмена между конфигурациями 1С построен на XDTO-пакетах. «Конвертация данных 3.0» оперирует именно этими структурами.
• 💾 Выгрузка и загрузка данных. Сохранение прикладных объектов в XML и восстановление в другой базе через сериализатор.
• 🌍 HTTP-сервисы. Когда тело запроса или ответа передаётся в XML по строгой схеме, его удобно разбирать через фабрику XDTO.

Общий признак: как только появляется договорённость о формате с внешней стороной, XDTO даёт инструмент эту договорённость формализовать и проверять автоматически.

Понять, что под капотом работает именно XDTO, можно по косвенным признакам. В обмене между конфигурациями 1С сообщения уходят в XML с объявленными пространствами имён и типами — это и есть сериализованные объекты XDTO. В веб-сервисе описание WSDL ссылается на XSD-схемы, которые платформа собрала из ваших пакетов. Если видите в коде обращение к ФабрикаXDTO, СериализаторXDTO или к фабрике прокси веб-сервиса — значит, данные идут через этот механизм.

Ограничения технологии и типичные грабли

Строгая типизация — сила и слабость XDTO одновременно. Что стоит держать в голове:

• ❗ Несоответствие схеме = ошибка. Лишний тег, другой регистр имени, неверный тип значения — чтение упадёт. Это ожидаемо для контракта, но болезненно при разборе «грязных» данных от внешних систем.
• 🏷 Пространство имён обязано совпадать. Самая частая причина, почему объект «не читается»: в документе URI пространства имён отличается от того, что ждёт фабрика. Проверяйте namespace, а не только имена тегов.
• 🧠 Память на больших объёмах. Фабрика загружает объект в память целиком. Если XML измеряется сотнями мегабайт, выгоднее последовательное чтение ЧтениеXML без материализации всего дерева.
• 🔒 Локальные фабрики изолированы. Тип из пакета конфигурации недоступен в фабрике веб-сервиса и наоборот. Берите ту фабрику, которой принадлежит тип.

По производительности для типовых объёмов обмена XDTO работает предсказуемо: узким местом обычно становится не разбор XML, а запросы к базе и сетевой обмен. Оптимизировать имеет смысл тогда, когда профилирование показало проблему именно здесь, а не заранее.

При разборе ошибок чтения помогает простой приём: сначала выведите входящий XML в лог или сообщение целиком, а затем сверьте его с ожидаемой схемой построчно — пространство имён, имена свойств, их регистр и обязательность. Чаще всего расхождение видно уже на первой паре строк, и лезть в отладчик не приходится.

Отдельная вещь, которую легко упустить: при импорте чужой XSD-схемы платформа переносит её ограничения как есть. Если во внешней схеме поле объявлено обязательным, пустое значение в вашем объекте приведёт к ошибке записи. Сверяйтесь с исходной схемой, а не только с полученным набором типов.