Web-сервис 1С не отвечает или отвечает не то: проверяем по слоям

Быстрее всего проверить web-сервис 1С так: откройте в браузере адрес его описания http://сервер/имя_публикации/ws/ИмяСервиса.1cws?wsdl. Пришёл XML с тегами definitions, types, service — публикация работает, веб-сервер видит базу, пользователь авторизован. Дальше вызовите одну простую операцию через curl, SoapUI или обработку с WSПрокси, чтобы убедиться, что отвечает уже код конфигурации.

Если WSDL не открывается, искать причину в коде бесполезно: сломан один из нижних слоёв — сеть, веб-сервер, публикация или права. Поэтому диагностика web-сервисов идёт снизу вверх: доступность, описание, вызов, содержимое запроса, логи. Механизм общий для платформы 8.3 и не зависит от конфигурации: одинаково проверяется сервис в БП, УТ, ЗУП или в самописной базе.

1. Доступен ли web-сервис физически: сеть, веб-сервер, публикация

Web-сервис 1С не живёт сам по себе. Запрос проходит цепочку: клиент → веб-сервер (Apache или IIS) → модуль расширения веб-сервера 1С → информационная база → модуль web-сервиса. Обрыв на любом звене выглядит для внешней системы одинаково: «сервис недоступен».

Проверяйте по порядку:

1. 🌐 Сеть. С машины-потребителя выполните ping сервер и проверку порта: Test-NetConnection сервер -Port 80 в PowerShell или curl -I http://сервер/ в Linux. Нет ответа на порт — дело в файрволе или DNS, а не в 1С.
2. 🖥️ Веб-сервер. Откройте http://сервер/ в браузере на самом сервере. Стартовая страница Apache или IIS означает, что служба запущена.
3. 📂 Публикация. Откройте http://сервер/имя_публикации/ — у публикации с веб-клиентом откроется окно входа. Ответ 404 значит, что публикации с таким именем нет или веб-сервер её не подхватил.
4. 📄 WSDL. Откройте http://сервер/имя_публикации/ws/ИмяСервиса.1cws?wsdl. Здесь ИмяСервиса — имя публикации web-сервиса из его свойств в конфигурации, а не синоним.

Что проверить в публикации

Публикуют базу в Конфигураторе: Администрирование → Публикация на веб-сервере. На вкладке web-сервисов должны стоять две отметки: общая «Публиковать Web-сервисы» и флажок напротив конкретного сервиса. Частая ситуация: сервис добавили в конфигурацию после публикации, а флажок для него так и не поставили.

Результат публикации — файл default.vrd в каталоге публикации. Для web-сервиса в нём должна быть строка вида:

<ws pointEnableCommon="true">
    <point name="Exchange" alias="Exchange.1cws" enable="true"/>
</ws>

Нет нужной строки point или стоит enable="false" — сервис не опубликован, сколько бы вы ни правили код.

2. Проверка web-сервиса средствами самой 1С

Внешние утилиты удобны, но проверка из другой базы 1С ближе к реальной интеграции: так работают обмены между конфигурациями.

Вызов через WSПрокси во внешней обработке

Создайте внешнюю обработку с одной командой и выполните на сервере такой код:

URLОписания = "http://srv/base/ws/Exchange.1cws?wsdl";
Определения = Новый WSОпределения(URLОписания, "ОбменWS", "пароль");
Прокси = Новый WSПрокси(Определения, "http://www.example.org/exchange", "Exchange", "ExchangeSoap");
Прокси.Пользователь = "ОбменWS";
Прокси.Пароль = "пароль";
Результат = Прокси.Ping();
Сообщить("Ответ сервиса: " + Строка(Результат));

Пространство имён, имя сервиса и точку подключения берите из WSDL: атрибут targetNamespace в корне, тег service и вложенный port. Платформа публикует две точки — для SOAP 1.1 и SOAP 1.2, у 1С они обычно называются ИмяSoap и ИмяSoap12.

Если ошибка возникает уже на строке Новый WSОпределения, сервис до вызова кода даже не дошёл: смотрите адрес, логин и сеть. Если падает на Прокси.Ping() — описание получено, проблема в вызове или в самом методе.

WS-ссылка в конфигурации

Второй путь — добавить в конфигурацию-потребитель WS-ссылку: ветка Общие → WS-ссылки, при создании укажите адрес WSDL. Конструктор загрузит описание и покажет операции с параметрами. Если описание не загрузилось, конструктор выведет текст ошибки — это тоже быстрый тест.

Отладка метода на стороне базы-поставщика

Когда сервис отвечает, но возвращает не то, нужна пошаговая отладка. В Конфигураторе базы-поставщика:

1. Включите отладку для сервера 1С: на сервере кластера в параметрах службы агента должен стоять ключ -debug. На файловой базе этот шаг не нужен.
2. Откройте Отладка → Подключение и в настройках автоподключения отметьте сеансы web-сервисов.
3. Поставьте точку останова в модуле web-сервиса, в обработчике нужной операции.
4. Вызовите операцию из SoapUI или curl. Отладчик остановится на точке.

3. Что уходит и приходит по SOAP: анализ запроса

Половина проблем интеграции — не «сервис упал», а «отправили не то». Внешняя система шлёт пустое поле, другой namespace или дату в неожиданном формате. Чтобы это увидеть, нужен сам SOAP-конверт.

Вызов через curl

Сохраните запрос в файл req.xml:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ex="http://www.example.org/exchange">
  <soap:Body>
    <ex:Ping/>
  </soap:Body>
</soap:Envelope>

И отправьте его:

curl -v -u ObmenWS:password \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: \"http://www.example.org/exchange#Exchange:Ping\"" \
  --data-binary @req.xml \
  http://srv/base/ws/Exchange.1cws

Ключ -v покажет код ответа и заголовки. Точное значение SOAPAction возьмите из WSDL, из атрибута soapAction у нужной операции.

SoapUI

SoapUI удобнее curl, когда операций много. Создайте проект, укажите адрес WSDL — программа сама построит шаблоны запросов для каждой операции. Логин и пароль задаются на вкладке авторизации запроса (Basic). В ответе видно и тело, и HTTP-код.

Перехват реального обмена

Если нужно увидеть, что шлёт сама внешняя система или база-потребитель, поставьте между ними прокси-сниффер (Fiddler, mitmproxy) или снимите трафик Wireshark. У WSПрокси есть параметр интернет-прокси: направьте его на Fiddler, и каждый конверт будет виден целиком. По HTTPS трафик в Wireshark зашифрован, поэтому для разбора удобнее прокси с подменой сертификата на тестовом стенде.

4. Ошибки при проверке web-сервиса и как их снять

Ещё две ситуации, которые путают с поломкой сервиса:

• 🔄 WSDL открывается, а вызов падает. Описание отдаётся из метаданных, код метода при этом не выполняется. Ошибка в модуле, нехватка прав на справочник или документ проявятся только при вызове операции.
• 🔒 Работает в браузере, не работает у внешней системы. Браузер мог запомнить логин или пройти Windows-аутентификацию. Повторите вызов через curl с явным логином — так вы проверите ровно то, что делает внешняя система.

5. Логи сервера: где искать подробности ошибки

Когда ответ сервиса — голый HTTP 500, подробности лежат в журналах. Смотреть нужно три места.

В журнале регистрации отфильтруйте события по приложению «Соединение web-сервиса» и по уровню «Ошибка». Так вы отделите вызовы сервиса от работы пользователей.

Технологический журнал для web-сервисов

Файл logcfg.xml кладут в каталог conf платформы, например C:\Program Files\1cv8\conf. Для web-сервисов полезны события VRSREQUEST и VRSRESPONSE — входящие HTTP-запросы и ответы — и EXCP с исключениями:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\TechLog\ws" history="24">
    <event><eq property="name" value="VRSREQUEST"/></event>
    <event><eq property="name" value="VRSRESPONSE"/></event>
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

Модуль расширения работает внутри процесса веб-сервера. Поэтому у учётной записи службы Apache или пула IIS должны быть права на запись в каталог журнала, иначе он останется пустым.

6. Мониторинг web-сервиса: узнать о сбое раньше пользователей

Ручная проверка помогает, когда уже сломалось. Чтобы узнавать о сбое первым, нужна регулярная автоматическая.

Служебная операция для проверки

Добавьте в сервис простую операцию вроде Ping, которая возвращает строку с версией конфигурации и текущим временем сервера. Она не трогает данные, работает быстро и показывает, что вся цепочка до кода 1С жива. Проверка одного WSDL этого не гарантирует.

Что проверять по расписанию

Проверку WSDL и вызов Ping удобно поставить в Zabbix или другую систему мониторинга как обычную HTTP-проверку с порогом времени ответа. На стороне потребителя то же самое делает регламентное задание: вызывает сервис и пишет результат в журнал.

Сеансы и переиспользование

В консоли администрирования кластера сеансы web-сервисов видны с приложением «Соединение web-сервиса». Если их число растёт и не падает, клиент не закрывает сеансы. В default.vrd у точки сервиса настраивается атрибут reuseSessions — повторное использование сеансов между вызовами. Значение подбирают под нагрузку и проверяют на копии базы.

7. Проверка безопасности опубликованного web-сервиса

Опубликованный сервис — дверь в базу из сети. Перед выводом наружу пройдитесь по списку:

• 🔐 Отдельный пользователь. Для сервиса заведите пользователя только с нужными ролями. Учётная запись администратора для интеграции — частая и опасная практика.
• 📝 Пароль в default.vrd. Если в строке подключения публикации прописаны логин и пароль, любой анонимный запрос выполняется от их имени. Проверьте атрибут ib в default.vrd: при пустой авторизации на уровне веб-сервера такой сервис открыт всем.
• 🔒 HTTPS. Basic-авторизация по HTTP передаёт пароль в открытом виде. Для доступа из интернета нужен сертификат и HTTPS на веб-сервере.
• 🧱 Ограничение по IP. Если сервис вызывает одна внешняя система, разрешите доступ только с её адресов средствами веб-сервера или файрвола.
• 📦 Лишние сервисы. Снимите публикацию с сервисов, которые никто не вызывает. Чем меньше точек, тем меньше поверхность атаки.
• 🧪 Проверка без пароля. Вызовите WSDL и операцию через curl без ключа -u. Правильный ответ — 401, а не данные.

8. Частые вопросы о проверке web-сервисов 1С