Почему возникает ошибка «Сервис не найден» при обращении к веб-сервису 1С на IIS и как её исправить?

← На главную

При интеграции систем на базе 1С с внешними приложениями через веб-сервисы (SOAP) разработчики часто сталкиваются с ситуацией, когда WSDL-описание сервиса успешно открывается в браузере, но при попытке вызвать конкретную операцию через Postman или SoapUI сервер возвращает ошибку 500 Internal Server Error или 404 Not Found с пояснением «Сервис не найден». Рассмотрим подробно причины возникновения этой проблемы и разберем по шагам способы её решения.

Анализ проблемы: почему WSDL виден, а сервис нет?

Разберем типичную ситуацию. Вы создали в конфигураторе объект ВебСервис, определили операции и опубликовали его на веб-сервере IIS. Когда вы вводите в браузере адрес вида http://server/base/ws/MyService.1cws?wsdl, вы видите XML-структуру. Это означает, что расширение веб-сервера 1С работает и файл публикации .vrd корректно указывает на информационную базу. Однако, когда внешний клиент (например, Postman) пытается отправить POST запрос к операции, 1С не может сопоставить входящий URL с конкретным методом модуля веб-сервиса.

Причина №1: Использование кириллицы в именах

Проанализируем наиболее частую причину — именование объектов. 1С позволяет называть веб-сервисы и их операции на русском языке (например, УК_Мониторинг), но стандарты HTTP и реализация IIS накладывают свои ограничения. Рассмотрим, почему это критично:

URL-кодирование: При генерации WSDL русские буквы преобразуются в спецсимволы (процентное кодирование, например, %D0%90). Не все SOAP-клиенты корректно обрабатывают такие пути при обратной отправке запроса.
Обработка на стороне IIS: Модуль wsap24.dll (расширение 1С) может некорректно интерпретировать декодированные строки, если кодировка заголовков запроса отличается от ожидаемой.

Решение: Переименуем веб-сервис, его операции и параметры, используя только латиницу. Например, вместо ЗаблокированыРегламентныеЗадания используем ScheduledJobsIsBlocked. После переименования необходимо выполнить перепубликацию базы на веб-сервере. Если вы планируете строить современное API, стоит также изучить инструменты Swagger в 1С, которые помогают стандартизировать публикацию сервисов.

Причина №2: Некорректный метод и структура URL

Выясним, как правильно формировать адрес запроса. Часто разработчики ошибочно пытаются вызвать операцию, добавляя её имя прямо в URL или оставляя суффикс ?wsdl. Рассмотрим правильный подход:

Метод запроса: Для вызова операции веб-сервиса 1С всегда должен использоваться метод POST. Попытка выполнить GET запрос к адресу операции приведет к ошибке 500 или 404. Посмотрите пошаговый пример реализации POST-запроса для обмена данными с внешними сайтами.
Endpoint URL: Конечный адрес (Endpoint) для отправки SOAP-пакета должен выглядеть как http://server/base/ws/MyService.1cws. Не нужно добавлять имя операции в конец строки адреса. Имя вызываемой операции передается внутри XML-тела (в теге Body) или в заголовке SOAPAction.

Проанализируем пример структуры SOAP-запроса в Postman:


POST /BaseName/ws/BusinessMonitoring.1cws HTTP/1.1
Host: yourserver.com
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mon="http://www.your-uri.com/monitoring">
   <soapenv:Header/>
   <soapenv:Body>
      <mon:ScheduledJobsOnClusterIsBlocked/>
   </soapenv:Body>
</soapenv:Envelope>

Причина №3: Разрядность пула приложений IIS

Посмотрим на настройки веб-сервера. Если вы используете 64-битную платформу 1С, но в настройках IIS для пула приложений, в котором работает ваша публикация, разрешены 32-битные приложения (или наоборот), расширение веб-сервера может работать нестабильно. Выясним, как это проверить:

Откроем Диспетчер служб IIS.
Перейдем в раздел Пулы приложений (Application Pools).
Выберем пул, используемый вашей публикацией, и нажмем Дополнительные параметры.
Проверим параметр Разрешены 32-разрядные приложения. Для 64-битной платформы 1С здесь должно стоять False.

Причина №4: Права доступа и авторизация

Рассмотрим ситуацию, когда сервис не найден из-за невозможности 1С авторизовать пользователя. Если запрос не проходит аутентификацию, 1С может возвращать стандартную ошибку 500 вместо окна ввода логина/пароля в зависимости от настроек в .vrd файле.

Убедитесь, что в файле публикации (default.vrd) правильно настроены параметры доступа. Пример секции для веб-сервиса:


<ws>
    <service name="BusinessMonitoring"
             alias="BusinessMonitoring.1cws"
             publish="true"/>
</ws>

Также важно проверить, что у пользователя 1С, под которым выполняется запрос, назначены роли УдаленныйДоступЧерезВебСервис и специализированные роли для доступа к объектам метаданных, используемым в коде веб-сервиса.

Диагностика через Технологический журнал

Если вышеперечисленные шаги не помогли, разберем самый эффективный метод поиска причины — настройку Технологического журнала (ТЖ). Это позволит увидеть, доходит ли запрос до процесса 1С и какая именно ошибка возникает внутри платформы. Создадим файл logcfg.xml в папке conf сервера 1С со следующим содержанием:


<config xmlns="http://v8.1c.ru/7.4/getconfig/config">
    <log location="C:\Logs\1C\WebServices" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="WSCAL"/>
        </event>
        <property name="All"/>
    </log>
</config>

Событие EXCP зафиксирует все исключительные ситуации, а WSCAL покажет входящие вызовы веб-сервисов. Для более удобного чтения логов можно предварительно убрать лишние переносы строк в файлах ТЖ. Если данных становится слишком много, используйте конвертер журнала в формат JSON или настройте экспорт технологического журнала в Elastic для глубокого анализа. Проанализировав логи, вы точно определите, является ли проблема ошибкой прав доступа, ошибкой в коде модуля или проблемой разбора XML-пакета.

Итоги и рекомендации

Подводя итог, для стабильной работы веб-сервисов 1С на IIS придерживайтесь следующих правил:

Используйте только латиницу в именах веб-сервисов и операций.
Всегда вызывайте операции через POST запрос к файлу .1cws.
Следите за соответствием разрядности пула приложений IIS и установленной платформы 1С.
После внесения любых изменений в публикацию или конфигурацию выполняйте команду iisreset в командной строке для очистки кэша веб-сервера.

Соблюдение этих шагов позволит избежать большинства ошибок «Сервис не найден» и обеспечит надежную работу ваших интеграционных решений.

← На главную