Почему при добавлении WS-ссылки возникает ошибка 404 и как ее исправить

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Анализ причин сбоя при импорте схемы WSDL

Рассмотрим подробнее, почему веб-сервер выдает код 404 вместо стандартного запроса авторизации. В работе связки платформы 1С и веб-сервера (в особенности Apache) есть несколько критических нюансов:

  1. Чувствительность к регистру символов (Case Sensitivity). В отличие от операционных систем семейства Windows и сервера IIS, веб-сервер Apache строго различает регистр букв в пути запроса. Если в дескрипторе публикации default.vrd сервис зарегистрирован как tradeEx.1cws, а в Конфигураторе мы запрашиваем TradeEx.1cws, веб-сервер не сможет найти целевую точку входа и вернет ошибку.
  2. Особенности механизма авторизации в платформе 1С. Когда в опубликованной базе заведены пользователи, любое обращение к платформе требует создания сеанса. Если Конфигуратор обращается к веб-сервису анонимно, а веб-расширение 1С не может сопоставить запрос с зарегистрированной точкой публикации, модуль возвращает внутреннее исключение об отсутствии сеанса. Вместо стандартного HTTP-статуса 401 Unauthorized сервер нередко возвращает 404 Not Found. Из-за этого Конфигуратор не запрашивает у пользователя логин и пароль, а сразу прерывает добавление метаданных.
  3. Кэширование авторизации браузерами. В веб-браузере схема может открываться успешно, поскольку браузер сохраняет авторизационные cookie или учетные данные сессии после первого входа, тогда как Конфигуратор выполняет новый, «чистый» запрос.

Способ 1. Проверка регистра и файла публикации default.vrd

Проанализируем файл дескриптора публикации информационной базы. Этот файл называется default.vrd и находится в каталоге публикации на веб-сервере. Разберем по шагам, на что обратить внимание:

  1. Откроем файл default.vrd любым текстовым редактором и найдем секцию ws.
  2. Проверим имена сервисов и их адреса. Они должны точно, символ в символ, с соблюдением регистра совпадать с тем адресом, который мы указываем при создании WS-ссылки:
    
    <ws>
        <service name="TradeExchange"
                 url="tradeEx.1cws"
                 enable="true"/>
    </ws>
    
  3. Если в параметре url указано tradeEx.1cws с маленькой буквы, то и в строке подключения WSDL в Конфигураторе мы обязаны указать:

    http://192.168.12.34/InfoBase3/ws/tradeEx.1cws?wsdl

    Любая опечатка в регистре приведет к ошибке маршрутизации и сбою сеанса.

Способ 2. Явная передача учетных данных в строке подключения

Если в базе включена аутентификация, обойти проблему отсутствия окна авторизации в Конфигураторе можно путем указания логина и пароля непосредственно в формате URL. Разберем синтаксис такой строки:

http://ИмяПользователя:Пароль@192.168.12.34/InfoBase3/ws/tradeEx.1cws?wsdl

В этом случае платформа сразу отправляет заголовок базовой аутентификации Authorization: Basic, сеанс стартует без промежуточных проверок, и Конфигуратор успешно считывает описание веб-сервиса.

Способ 3. Импорт схемы через локальный файл WSDL

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

  1. Откроем адрес схемы WSDL в браузере, введем логин и пароль пользователя базы.
  2. После того как в окне браузера отобразится дерево XML, сохраним страницу на локальный диск в виде файла (например, C:\TradeEx.wsdl).
  3. В окне создания WS-ссылки в Конфигураторе укажем путь к сохраненному файлу на диске:

    file:///C:/TradeEx.wsdl

  4. Нажмем кнопку загрузки. Конфигуратор моментально создаст метаданные WS-ссылки и пакеты XDTO без обращения к веб-серверу по сети.

Способ 4. Динамическое подключение без создания WS-ссылки в конфигурации

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


АдресWSDL = "http://192.168.12.34/InfoBase3/ws/tradeEx.1cws?wsdl";
ИмяПользователя = "Администратор";
ПарольПользователя = "SecretPass123";

// Создаем объект определений с передачей учетных данных
Определения = Новый WSОпределения(АдресWSDL, ИмяПользователя, ПарольПользователя);

URIПространстваИмен = "http://www.sample-package.org";
ИмяСервиса = "TradeExchange";
ТочкаПодключения = "TradeExchangeSoap";

// Инициализируем прокси
Прокси = Новый WSПрокси(Определения, URIПространстваИмен, ИмяСервиса, ТочкаПодключения);
Прокси.Пользователь = ИмяПользователя;
Прокси.Пароль = ПарольПользователя;

// Вызываем метод веб-сервиса
Результат = Прокси.ВыполнитьВыгрузку();

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

Настройка веб-сервера Apache

Если веб-сервер упорно не передает данные учетной записи в платформу 1С, проверим конфигурационный файл httpd.conf. В некоторых случаях требуется явно разрешить передачу авторизационных заголовков расширению 1С. Для этого добавим директиву:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

После внесения правок перезапустим службу веб-сервера Apache и повторим попытку подключения к веб-сервису.

← На главную