XDTO-пакеты в 1С: назначение, устройство и практика работы

XDTO-пакет — это объект метаданных конфигурации 1С, который описывает структуру данных для обмена с внешними системами: веб-сервисами, другими базами 1С, сторонними приложениями. Название расшифровывается как XML Data Transfer Objects — объекты переноса данных в формате XML. По сути, это схема, которая определяет, какие типы данных, поля и вложенные структуры будут передаваться при сериализации и десериализации.

Механизм XDTO появился как универсальный способ обмена данными без привязки к конкретной конфигурации. Если планы обмена требуют одинаковой структуры метаданных на обеих сторонах, то XDTO позволяет согласовать формат сообщений между разнородными системами: 1С и сайтом, 1С и CRM, 1С и банковским сервисом. Именно на XDTO построена работа веб-сервисов в 1С и технология EnterpriseData.

Разработчик сталкивается с XDTO-пакетами в трёх типовых сценариях: публикация собственного веб-сервиса, интеграция с внешним API по WSDL-описанию и настройка обмена данными через формат EnterpriseData. Во всех случаях логика одинакова — сначала описывается модель данных, затем объекты создаются, заполняются и сериализуются в XML либо читаются из XML обратно.

Из чего состоит XDTO-пакет

Каждый пакет имеет пространство имён — уникальный URI, который отличает его от других пакетов и предотвращает конфликты типов при совместном использовании. Например, типовые пакеты 1С используют пространства вида «http://v8.1c.ru/edi/edi_stnd/EnterpriseData». Пространство имён не обязано вести на реальный сайт — это просто уникальный идентификатор.

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

Пакеты могут импортировать другие пакеты и использовать их типы. Так строятся сложные модели: базовый пакет описывает общие типы (например, «Контрагент», «Номенклатура»), а прикладные пакеты ссылаются на него. Это снижает дублирование, но создаёт зависимость — при изменении базового пакета нужно проверять все зависимые.

Где XDTO применяется на практике

Первый сценарий — веб-сервисы. Когда вы публикуете веб-сервис в 1С, платформа автоматически формирует WSDL-описание на основе XDTO-пакетов, указанных в свойствах сервиса. Типы параметров операций и возвращаемых значений должны быть описаны в пакетах — иначе внешняя система не сможет корректно сформировать запрос.

Второй сценарий — обмен EnterpriseData, стандартный формат интеграции продуктов 1С с сайтами, CRM и между собой. Вся модель данных этого обмена описана в XDTO-пакетах, и при доработке обмена (добавлении своих полей или документов) разработчик расширяет именно пакеты.

Третий сценарий — подключение к чужим сервисам. Если у внешней системы есть WSDL, на его основе создаётся WS-ссылка, и платформа генерирует соответствующие XDTO-структуры. Далее в коде вы работаете с объектами XDTO, а платформа сама превращает их в SOAP-сообщения.

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

Пакет создаётся в ветке «Общие — XDTO-пакеты» дерева конфигурации. При добавлении нового пакета первым делом задайте пространство имён — осмысленный URI, отражающий назначение пакета, например «http://mycompany.ru/exchange/orders». Изменение пространства имён после начала использования пакета сломает совместимость с уже сформированными сообщениями.

Затем добавляются типы. Для типа объекта перечислите свойства: имя, тип (встроенный примитивный тип XML Schema, тип значения из этого же пакета или тип объекта), минимальное и максимальное количество. Свойство с максимальным количеством «-1» или больше 1 становится списком при работе в коде. Для необязательных полей ставьте минимальное количество 0 — тогда отсутствие значения не вызовет ошибку валидации.

Если у вас уже есть готовая XML-схема (файл .xsd) от контрагента, пакет можно импортировать: в палитре свойств пакета есть команда импорта схемы. Это заметно быстрее ручного описания и исключает расхождения с ожиданиями внешней системы.

1. 1
   Создайте пакет в ветке «Общие — XDTO-пакеты», задайте уникальное пространство имён
2. 2
   Добавьте типы значений с ограничениями (длина, точность, перечисления)
3. 3
   Добавьте типы объектов и опишите их свойства с указанием кратности
4. 4
   Обновите конфигурацию базы данных — пакеты доступны в коде только после обновления
5. 5
   Напишите тестовый код: создайте объект через фабрику, заполните, запишите в XML и прочитайте обратно
6. 6
   Сравните полученный XML с образцом от внешней системы или контрагента

Работа с XDTO в коде: создание, запись, чтение

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

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

ТипЗаказа = ФабрикаXDTO.Тип("http://mycompany.ru/exchange/orders", "Заказ");
Заказ = ФабрикаXDTO.Создать(ТипЗаказа);
Заказ.Номер = "А-00125";
Заказ.Дата = ТекущаяДатаСеанса();

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

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

Типичные ошибки и ограничения механизма

Самая частая проблема — несовпадение версий пакетов на стороне отправителя и получателя. Добавили обязательное поле в пакет, обновили одну базу, а вторую забыли — обмен падает с ошибкой валидации. Правило простое: новые поля в действующем обмене делайте необязательными (минимальное количество 0), а версионирование ведите через пространства имён с номером версии.

Вторая группа ошибок связана с типами данных. Дата без времени и дата со временем — разные типы в XML Schema; пустая строка и отсутствующее значение — тоже разные вещи. Если внешняя система присылает пустой тег там, где схема ожидает число, чтение упадёт. В таких случаях тип поля в пакете делают строковым, а преобразование выполняют в коде.

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

Производительность и безопасная работа

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

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

Как проверить, что всё работает правильно

Минимальная проверка — полный цикл на тестовых данных: создание объекта, запись в XML, чтение обратно, сверка значений. Далее — сравнение сформированного XML с образцом, который предоставила внешняя система: имена элементов, порядок, пространства имён, формат дат и чисел должны совпадать.

Для веб-сервисов дополнительно проверьте WSDL: откройте его в браузере или SoapUI и убедитесь, что операции и типы видны так, как ожидает потребитель. Для обменов EnterpriseData контрольные точки — журнал регистрации и очередь сообщений: сообщение должно уходить без ошибок валидации и приниматься на той стороне без отказов.

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