Как проверить опубликованный веб-сервис 1С

После публикации веб-сервиса 1С на веб-сервере (IIS или Apache) администратору нужно убедиться, что сервис действительно доступен извне, отвечает на запросы и корректно выполняет операции. Публикация в конфигураторе сама по себе не гарантирует работоспособность: ошибки в файле default.vrd, неверные права на каталог или отсутствие аутентификации проявляются только при реальном обращении.

Проверка строится поэтапно: сначала подтверждается доступность WSDL-описания, затем выполняется тестовый вызов операции, после чего анализируются коды ответов и журналы ошибок. Такой порядок позволяет локализовать проблему — на уровне веб-сервера, публикации или самого кода сервиса в конфигурации.

Ниже описан практический порядок действий с инструментами, которые есть почти в любой среде: браузер, командная строка, SoapUI или Postman. Отдельно разобраны типичные коды ошибок и признаки, по которым можно отличить нормальную работу от сбоя.

Что понадобится перед проверкой

Для полноценной проверки соберите исходные данные: адрес публикации (имя сервера и имя публикации информационной базы), точное имя веб-сервиса из конфигурации, а также логин и пароль пользователя 1С, у которого есть право на использование сервиса. Без действующей учётной записи вы будете получать ошибку 401 даже при корректной публикации.

Имя веб-сервиса и имена его операций смотрите в конфигураторе: ветка «Общие» → «Web-сервисы». Там же указано пространство имён — оно понадобится при формировании запросов в SoapUI. Имя в публикации чувствительно к регистру на некоторых веб-серверах, поэтому копируйте его точно.

Уточните, какой веб-сервер используется — IIS или Apache, и на каком порту он принимает соединения. Если публикация выполнена по HTTPS, потребуется действующий сертификат, иначе браузер и клиентские приложения будут отклонять соединение.

Шаг 1. Проверка доступности WSDL через браузер

Самый быстрый тест — запрос WSDL-описания. В адресной строке браузера введите URL по шаблону: http://имя_сервера/имя_публикации/ws/ИмяСервиса?wsdl. Для HTTPS-публикаций замените протокол на https и при необходимости укажите порт.

Если всё настроено верно, браузер сначала запросит логин и пароль пользователя 1С (при включённой аутентификации), а затем покажет XML-документ — описание сервиса со списком операций, типов данных и точек подключения. Наличие этого XML означает, что веб-сервер передаёт запросы в 1С, расширение веб-сервера загружено и сервис опубликован.

Если вместо WSDL отображается страница ошибки, запомните её код — по нему определяется источник проблемы. Подробный разбор кодов приведён ниже в соответствующем разделе.

1. 1
   Откройте браузер и введите URL: http://сервер/публикация/ws/ИмяСервиса?wsdl
2. 2
   При запросе введите логин и пароль пользователя 1С с правом на сервис
3. 3
   Убедитесь, что вернулся XML-документ с элементами definitions и списком операций
4. 4
   Проверьте, что внутри WSDL указан корректный адрес точки подключения (soap:address)
5. 5
   Если вернулась ошибка — зафиксируйте её код и перейдите к разбору типичных сбоев

Шаг 2. Тестовый вызов операции сервиса

Доступность WSDL подтверждает только факт публикации, но не работоспособность логики. Следующий шаг — вызвать реальную операцию и проверить ответ. Для этого удобнее всего использовать SoapUI (для SOAP-сервисов) или Postman.

Проверка через SoapUI

Создайте новый SOAP-проект и укажите URL WSDL. SoapUI автоматически построит дерево операций и шаблоны запросов. Откройте шаблон нужной операции, заполните параметры тестовыми данными и отправьте запрос. В настройках авторизации (Auth) выберите Basic и укажите учётные данные пользователя 1С.

Успешный результат — ответ с HTTP-кодом 200 и XML в теле, соответствующий типу возвращаемого значения операции. Если операция возвращает строку или структуру, проверьте, что данные осмысленные, а не пустой ответ или описание исключения.

Проверка через Postman

В Postman создайте POST-запрос на URL сервиса без параметра ?wsdl. В заголовках укажите Content-Type: text/xml; charset=utf-8 и SOAPAction с именем операции, тело запроса — SOAP-конверт. Авторизацию настройте на вкладке Authorization как Basic Auth.

curl -u Пользователь:Пароль "http://server/base/ws/ServiceName?wsdl" -i

Команда curl с ключом -i покажет заголовки ответа и код состояния — это удобно для быстрой диагностики из командной строки без установки дополнительных инструментов. Код 200 и XML в теле означают успех.

Шаг 3. Разбор типичных ошибок по кодам ответа

Код HTTP-ответа — главный диагностический признак. Он указывает, на каком уровне произошёл сбой: веб-сервер, публикация или код сервиса.

Ошибка 404 чаще всего означает опечатку в имени сервиса или то, что публикация выполнена с другим именем каталога. Откройте файл default.vrd в каталоге публикации и сверьте значение атрибута name в элементе point с именем в URL.

Ошибка 500 требует анализа журнала регистрации: откройте его в конфигураторе или консоли кластера и найдите события с ошибкой в момент вызова. Текст исключения из кода операции обычно содержится в теле SOAP-ответа как Fault.

Проверка с внешней сети и по HTTPS

Если сервис предназначен для внешних потребителей, обязательно выполните проверку с машины вне локальной сети — например, через мобильный интернет. Внутренняя доступность ничего не говорит о внешней: запросы могут блокироваться межсетевым экраном, не проброшен порт на маршрутизаторе или внешний адрес не сопоставлен с внутренним.

При работе по HTTPS проверьте цепочку сертификатов: браузер не должен показывать предупреждений о недоверенном сертификате. Самоподписанный сертификат приемлем только для тестовой среды — внешние системы часто отклоняют такие соединения без возможности отключить проверку.

Также убедитесь, что в WSDL в элементе soap:address указан внешний адрес, а не внутреннее имя сервера. Если внутри описания стоит локальный адрес, внешний клиент получит WSDL, но не сможет обратиться к точке подключения. Это исправляется настройкой публикации или перезаписью адреса на обратном прокси.

Диагностика на стороне сервера 1С

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

В журнале регистрации отфильтруйте события по пользователю, под которым выполняется вызов, и по уровню «Ошибка». Ошибки компиляции кода операции, обращения к несуществующим объектам и нарушения прав видны именно здесь.

Технологический журнал включается настройкой logcfg.xml и позволяет отслеживать события Web-сервисов (событие WEBS) с длительностью вызовов. Это полезно, когда сервис работает, но медленно: по длительности видно, где теряется время — в запросах к базе или в логике операции.

Логи IIS (каталог Logs) или Apache (access.log и error.log) показывают сам факт обращения и код ответа. Если в access.log нет записи о вашем запросе — запрос вообще не дошёл до веб-сервера, и проблему нужно искать в сети, DNS или брандмауэре.

Автоматизация регулярного контроля

Разовая проверка не защищает от сбоев после перезапуска сервера, обновления конфигурации или смены сертификата. Для критичных интеграций настройте периодический мониторинг: простейший вариант — скрипт, который с заданным интервалом запрашивает WSDL и сравнивает код ответа с 200.

Более надёжный вариант — вызов специальной тестовой операции (например, Ping), добавленной в сервис специально для мониторинга. Она не обращается к данным и возвращает фиксированный ответ, поэтому подходит для частых проверок без нагрузки на базу.

Результаты мониторинга стоит направлять в систему оповещений администратора. Реагировать на недоступность сервиса по жалобе внешнего потребителя — худший сценарий, особенно если через сервис идут заказы или обмен справочниками.

Частые вопросы