При обновлении конфигураций или переносе функционала веб-сервисов из одной базы в другую разработчики часто сталкиваются с ситуацией, когда публикация проходит успешно, но при попытке программного обращения к сервису через конструктор WSОпределения возникает ошибка: «При создании описания сервиса произошла ошибка». Ситуация осложняется тем, что информационное сообщение 1С часто бывает малоинформативным, а журнал регистрации не фиксирует конкретных причин сбоя.
В этой статье мы подробно разберем, почему возникает эта проблема, и по шагам пройдем процесс диагностики и исправления ошибок, возникающих при построении WSDL-описания.
Рассмотрим типичный фрагмент кода, на котором происходит прерывание работы программы:
WSОпределение = Новый WSОпределения(АдресСервиса + "ws/" + ИмяПубликации + ".1cws?wsdl", ЛогинДляПодлкючения, ПарольДляПодключения);
Если на этой строке система выдает исключение, это означает, что платформа не смогла корректно десериализовать XML-описание сервиса (WSDL), которое генерирует серверная база 1С. Выясним причину, выполнив последовательную проверку всех узлов интеграции.
Первым делом проверим, что проблема не связана с сетевыми настройками или правами доступа веб-сервера. Скопируем адрес из ошибки и вставим его в адресную строку браузера. В нашем примере адрес выглядит так:
http://172.17.2.13/UVS2_test1/ws/ProductionOperation.1cws?wsdl
Возможные результаты:
.1cws. Убедитесь, что в default.vrd сервис прописан.Одной из наиболее частых причин ошибки при переносе веб-сервисов является наличие «битых» ссылок в XDT-пакетах. Проанализируем ситуацию: если в старой редакции веб-сервис использовал типы данных, связанные с документами или справочниками, которых больше нет в новой базе, генерация WSDL будет прервана.
Разберем, что нужно проверить в XDT-пакетах:
XDT-пакет, который назначен в качестве пространства имен для параметров или возвращаемых значений вашего веб-сервиса.ДокументОбъект.ЗаказПокупателя), а этого документа в новой базе нет или он называется иначе, пакет станет невалидным.Namespace, платформа не сможет однозначно определить структуру данных.Совет: Попробуйте временно изменить типы всех параметров и возвращаемого значения метода веб-сервиса на стандартный string (из пространства имен http://www.w3.org/2001/XMLSchema). Если после этого WSОпределения создается без ошибок, значит, проблема точно в исходном XDT-пакете.
Если журнал регистрации 1С пуст, а браузер не дает конкретики, воспользуемся специализированными инструментами, такими как SoapUI. Это позволит нам увидеть «чистый» HTTP-ответ сервера.
Проанализируем алгоритм проверки:
Выясним, правильно ли настроена публикация на веб-сервере. Найдем файл default.vrd в каталоге публикации (обычно это C:\inetpub\wwwroot\ИмяБазы\ для IIS). Проверим секцию ws:
<ws>
<point name="ProductionOperation"
alias="ProductionOperation.1cws"
enable="true"
reuseSessions="autouse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>
</ws>
Убедимся, что name совпадает с именем веб-сервиса в метаданных 1С, а alias соответствует тому, что мы вызываем в коде. Также стоит проверить настройки прав доступа: пользователь, под которым запущен пул приложений веб-сервера, должен иметь права на чтение этого каталога.
Веб-серверы и сама платформа 1С агрессивно кэшируют WSDL-описания. Даже если вы исправили ошибку в XDT-пакете, вы можете продолжать получать старую ошибку из кэша. Проанализируем шаги по очистке:
iisreset для IIS).Начиная с последних версий платформы 8.3 (особенно 8.3.20 и выше), усилен контроль за типами данных в веб-сервисах. Рассмотрим важные моменты:
ХранилищеЗначения или универсальных ссылок ЛюбаяСсылка напрямую в параметрах веб-сервиса при передаче между разными конфигурациями. Лучше использовать сериализацию в string (Base64 или JSON) или строго типизированные XDT-объекты.Соблюдение этих шагов позволит локализовать проблему, даже если стандартные средства отладки 1С не показывают явную причину сбоя.