Почему XDTO-пакет не отображается в списке выбора возвращаемого значения Web-сервиса 1С

При разработке интеграционных решений на платформе 1С программисты часто сталкиваются с тем, что созданный XDTO-пакет упорно отказывается появляться в выпадающем списке при настройке параметров или возвращаемых значений метода Web-сервиса. Эта ситуация типична для тех, кто только начинает осваивать технологию SOAP-обмена. Разберем детально, как правильно связать пакет данных с сервисом и какие нюансы настройки необходимо учесть, чтобы архитектура обмена работала корректно.

Настройка свойства «Пакеты XDTO» у объекта Web-сервис

Проанализируем первую и самую распространенную причину проблемы. В среде разработки 1С недостаточно просто создать XDTO-пакет в дереве конфигурации. Объект Web-сервис является изолированным описанием интерфейса, и ему нужно явно «сообщить», какие именно схемы данных он имеет право использовать.

Рассмотрим порядок действий для подключения пакета:

1. Откроем окно свойств вашего Web-сервиса.
2. Найдем свойство, которое называется «Пакеты XDTO».
3. Нажмем на кнопку выбора (три точки) и в открывшемся списке выберем наш пакет (например, Order).

Только после того, как пакет добавлен в этот «белый список», платформа позволит выбирать типы, определенные внутри этого пакета, в качестве типов параметров и возвращаемых значений методов. Это фундаментальный механизм типизации в 1С: без явного указания состава пакетов WSDL-описание сервиса не сможет корректно сформироваться.

Проверка структуры XDTO-пакета: Тип или Элемент

Выясним вторую важную причину, по которой нужный объект может не отображаться в списке. В структуре XDTO-пакета существует разделение на Типы объектов (Type Definitions) и Свойства/Элементы.

Разберем ситуацию подробнее: если вы создали в пакете только корневой Элемент, но не определили для него Тип объекта (Complex Type), то в списке выбора Web-сервиса вы его не увидите. Платформа ожидает, что возвращаемое значение метода — это конкретный Тип, а не экземпляр элемента. Для решения этой задачи проверим структуру пакета:

• Убедимся, что структура данных описана именно в ветке «Типы объектов».
• Назовем его, например, OrderType.
• Если у вас уже создан элемент, создайте тип и назначьте его этому элементу. В самом Web-сервисе теперь выбирайте созданный OrderType.

Синхронизация пространств имен (URI)

Посмотрим на технический аспект именования. Для корректной работы Web-сервиса и XDTO-пакета крайне желательно, чтобы их Пространства имен (URI) соответствовали логике вашего приложения. Хотя технически они могут различаться, их несовпадение часто вносит путаницу при генерации WSDL-схемы.

Рекомендуется придерживаться следующих правил:

• URI пространства имен пакета должен быть уникальным (например, http://www.yourcompany.ru/orders).
• В самом Web-сервисе свойство Имя пространства имен должно логически соотноситься с типами данных, которые он отдает.
• Избегайте использования кириллицы в URI и именах типов, так как сторонние системы (на Java, C#, Python) могут некорректно обработать такие символы в WSDL.

Реализация метода Web-сервиса на встроенном языке

После того как мы успешно настроили метаданные и тип Order стал доступен в интерфейсе, необходимо правильно написать программный код метода GetData. Нам нужно не просто вернуть структуру или таблицу, а создать объект через ФабрикуXDTO.

Проанализируем пример кода для формирования возвращаемого значения:

Функция GetData(НомерЗаказа)
    // 1. Определяем тип объекта из нашего пакета
    ТипОбъектаOrder = ФабрикаXDTO.Тип("http://www.yourcompany.ru/orders", "OrderType");
    
    // 2. Создаем экземпляр объекта XDTO
    НовыйЗаказ = ФабрикаXDTO.Создать(ТипОбъектаOrder);
    
    // 3. Заполняем свойства объекта
    НовыйЗаказ.Number = НомерЗаказа;
    НовыйЗаказ.Date = ТекущаяДата();
    
    // 4. Возвращаем объект XDTO
    Возврат НовыйЗаказ;
КонецФункции

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

Преимущества SOAP перед HTTP-сервисами

В ходе обсуждения часто звучат советы перейти на HTTP-сервисы как на более современные. Однако у Web-сервисов (SOAP) есть неоспоримые преимущества, которые мы разберем:

1. Строгая типизация: Благодаря XDTO-пакетам, 1С автоматически проверяет структуру входящих данных. Если клиент пришлет некорректный XML, код 1С даже не начнет выполняться — платформа сама вернет ошибку валидации.
2. Автоматическая генерация WSDL: Вам не нужно вручную описывать API (как в Swagger/OpenAPI для HTTP). Достаточно дать ссылку на сервис, и любая современная среда разработки сама построит классы для работы с вашим сервисом.
3. Нативность: Механизм XDTO глубоко интегрирован в платформу, что позволяет прозрачно передавать сложные типы данных между разными конфигурациями 1С.

Проблема кэширования при публикации

Рассмотрим еще один важный момент. Бывает так, что все настройки выполнены верно, но внешние потребители (или SoapUI) не видят обновленную структуру. Это происходит из-за кэширования WSDL-описания на стороне веб-сервера (Apache или IIS).

В таких случаях выполним следующие действия:

• Переопубликуем Web-сервис через конфигуратор (Администрирование -> Публикация на веб-сервере).
• Перезапустим службу веб-сервера.
• Если используется отладка, убедимся, что в строке подключения к сервису указан актуальный адрес.

Используя комплексный подход — от настройки списка Пакеты XDTO в свойствах сервиса до программного создания объектов через ФабрикаXDTO.Создать() — вы сможете успешно реализовать надежный механизм обмена данными.