Почему меняется WSDL после обновления 1С и как это исправить?

← На главную

При работе с веб-сервисами в среде 1С:Предприятие разработчики часто сталкиваются с неприятной особенностью: после внесения правок в код модуля или обновления версии платформы структура WSDL (Web Services Description Language) изменяется. Казалось бы, состав методов и параметров остался прежним, но внешние системы, потребляющие сервис, начинают выдавать ошибки. Рассмотрим подробнее, почему это происходит и какие шаги необходимо предпринять для стабилизации интеграции.

Выясним причину динамического изменения WSDL

Проанализируем ситуацию: в 1С файл WSDL не является статическим документом, который хранится в метаданных. Он генерируется «на лету» расширением веб-сервера (модулями wsap.dll для IIS или 1cws.so для Apache) в тот момент, когда внешняя система обращается к публикации по ссылке с параметром ?wsdl.

Разберем основные факторы, влияющие на этот процесс:

Алгоритм обхода метаданных: Платформа при генерации описания обходит дерево объектов и используемые пакеты XDTO. Любое изменение в конфигурации, даже если оно не касается текущего веб-сервиса, может изменить внутренний индекс или порядок перебора. В результате префиксы пространств имен (псевдонимы), такие как d1p1, d1p2 или xs1, переназначаются.
Обновление платформы: 1С регулярно оптимизирует механизмы сериализации. Переход на новый релиз часто влечет за собой изменение логики формирования XML-схем, что считается нормальным поведением с точки зрения стандартов SOAP, но критично для «хрупких» интеграций.
Зависимость от XDTO-пакетов: Если ваш сервис использует общие пакеты XDTO, добавление нового пакета в дерево метаданных или изменение порядка их следования гарантированно сдвинет схему в итоговом WSDL.

Почему ломаются внешние системы?

С точки зрения стандартов XML, префиксы (например, xs1:) не несут смысловой нагрузки. Важны только полные URI пространств имен, которые сопоставляются с этими префиксами в заголовке документа. Однако на практике многие внешние системы реализованы некорректно. Разберем типичные ошибки потребителей:

Жесткая привязка к строкам (Hardcoding): Сторонний клиент может искать данные простым поиском подстроки <d1p1:Name> вместо полноценного парсинга XML-дерева.
Кэширование схемы: Внешняя система может кэшировать WSDL и при малейшем изменении порядка элементов types или импортируемых схем выдавать ошибку валидации.

Решение №1: Использование статического WSDL-файла

Рассмотрим самый надежный способ решения проблемы, когда мы не можем изменить логику работы внешней системы. Мы можем «обмануть» потребителя, предоставив ему неизменяемый файл.

Выполним следующие шаги:

Откроем в браузере текущий рабочий WSDL нашего сервиса.
Сохраним содержимое страницы как локальный файл, например, myservice.wsdl.
Вручную отредактируем файл, установив те префиксы и тот порядок схем, который ожидает внешняя система.
Разместим этот файл в корневом каталоге веб-сервера (там, где лежит файл публикации .1cws).
Важный момент: Внутри файла в секции <soap:address location="..."/> убедимся, что указан правильный URL, ведущий к реальной публикации 1С.

Теперь внешняя система будет обращаться к статическому файлу http://server/base/myservice.wsdl, получать всегда одинаковую структуру, а фактические данные будут уходить на обработку в 1С.

Решение №2: Переход на HTTP-сервисы

Проанализируем альтернативный архитектурный подход. Если интеграция находится в стадии активной разработки, мы рекомендуем отказаться от SOAP (Web-сервисов) в пользу HTTP-сервисов (REST).

В чем преимущество для контроля структуры:

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

Посмотрим на пример кода формирования ответа в HTTP-сервисе, где мы жестко задаем структуру:


Функция ПолучитьДанные(Запрос)
    Ответ = Новый HTTPСервисОтвет(200);
    ЗаписьXML = Новый ЗаписьXML;
    ЗаписьXML.УстановитьСтроку();
    ЗаписьXML.ЗаписатьОбъявлениеXML();
    
    // Мы сами контролируем префиксы и пространства имен
    ЗаписьXML.ЗаписатьНачалоЭлемента("data", "http://www.mysite.ru/integration");
    ЗаписьXML.ЗаписатьАтрибут("xmlns:ns1", "http://www.mysite.ru/types");
    
    ЗаписьXML.ЗаписатьНачалоЭлемента("ns1:payload");
    ЗаписьXML.ЗаписатьТекст("Тестовые данные");
    ЗаписьXML.ЗаписатьКонецЭлемента();
    
    ЗаписьXML.ЗаписатьКонецЭлемента();
    
    Ответ.УстановитьТелоИзСтроки(ЗаписьXML.Закрыть());
    Возврат Ответ;
КонецФункции

Решение №3: Корректная работа с XDTO на стороне клиента

Если у нас есть доступ к коду внешней системы, правильным путем будет исправление логики чтения WSDL. Необходимо использовать полноценные библиотеки (SOAP-стеки), которые умеют сопоставлять Namespace URI с текущими префиксами документа.

Помните, что согласно спецификации WSDL, порядок следования схем в секции types и названия префиксов могут быть произвольными, если они корректно определены в заголовке. В 1С для работы с такими сервисами мы используем объект WSОпределения, который абстрагирует нас от текстового представления WSDL.


// Пример правильного обращения к сервису в 1С
Определения = Новый WSОпределения("http://server/base/ws/service?wsdl");
Прокси = Новый WSПрокси(Определения, "http://uri", "ServiceName", "EndpointName");
// Здесь платформа сама разберется с префиксами
Результат = Прокси.ВыполнитьОперацию();