Как проверить веб-сервис 1С в браузере

Веб-сервис 1С позволяет внешним системам обращаться к информационной базе по протоколу SOAP и получать данные в формате XML. Прежде чем передавать адрес сервиса разработчикам сторонней системы, нужно убедиться, что он опубликован, доступен из сети и корректно отвечает на запросы. Самый быстрый способ такой проверки — обычный браузер, без установки дополнительных инструментов.

Проверка через браузер не заменяет полноценное тестирование операций, но позволяет за минуту ответить на главный вопрос: «жив ли сервис». Если браузер открывает страницу описания сервиса (WSDL), значит, публикация работает, веб-сервер принимает запросы, а 1С отвечает. Если вместо описания вы видите ошибку — текст ошибки подскажет, на каком этапе искать проблему.

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

Что нужно подготовить перед проверкой

Для проверки потребуются три вещи: адрес публикации информационной базы, имя веб-сервиса и учётная запись пользователя 1С с правом на использование этого сервиса. Адрес публикации совпадает с адресом, по которому база открывается в браузере через веб-клиент, например http://server/base1c. Имя веб-сервиса можно посмотреть в конфигураторе: в дереве конфигурации откройте ветку «Общие» → «Web-сервисы» и найдите нужный объект — адрес формируется по его имени, а не по синониму.

Убедитесь, что база действительно опубликована на веб-сервере. Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». В диалоге публикации на вкладке «Web-сервисы» должны быть отмечены нужные сервисы либо установлен флаг публикации всех веб-сервисов. Если сервис добавили в конфигурацию после публикации, публикацию нужно обновить — иначе сервер о нём просто не узнает.

Как открыть WSDL-описание сервиса в браузере

Основной способ проверки — запрос WSDL-описания. В адресной строке браузера введите URL по шаблону: http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Например, если база опубликована как trade, а сервис называется Exchange, адрес будет http://server/trade/ws/Exchange?wsdl. Регистр букв в имени сервиса имеет значение — копируйте его из конфигуратора точно.

После ввода адреса браузер запросит логин и пароль — это стандартная HTTP-аутентификация. Введите имя и пароль пользователя информационной базы. Если аутентификация настроена через операционную систему или сертификаты, поведение может отличаться, но для типовой публикации достаточно пары «логин/пароль» пользователя 1С.

Признак успеха — в окне браузера отображается XML-документ, начинающийся с тега definitions или wsdl:definitions. Внутри перечислены операции сервиса, типы данных и точка подключения. Это и есть контракт сервиса: его можно сохранить в файл и передать разработчику внешней системы.

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

Проверка сервиса без параметра wsdl

Если открыть адрес http://сервер/Публикация/ws/ИмяСервиса без параметра ?wsdl, поведение зависит от веб-сервера и настроек. Чаще всего вы получите ошибку, потому что сервис ожидает SOAP-запрос методом POST, а браузер при открытии адреса отправляет GET. Это нормально: отсутствие содержимого при GET-запросе не означает, что сервис сломан.

Полноценно вызвать операцию сервиса из адресной строки нельзя — SOAP требует тела запроса в формате XML. Для такой проверки используют инструменты вроде Postman, SoapUI или встроенную обработку тестирования, но первичная диагностика «публикуется ли сервис вообще» решается именно запросом WSDL в браузере.

Как расшифровать коды ошибок

Код ответа HTTP в браузере — главный диагностический инструмент. У каждой типовой ошибки есть конкретная причина и свой путь исправления.

Отдельный случай — ответ 1С с текстом «Web-сервис не найден» или «Операция не найдена» в теле XML. Это означает, что веб-сервер и публикация работают, но конфигурация не содержит запрошенного объекта. Проверьте точное имя сервиса и не переименовывался ли он в последнем обновлении конфигурации.

Проверка прав доступа и аутентификации

Даже работающий сервис может отвечать отказом, если у пользователя нет права на его использование. В конфигураторе откройте роль пользователя и проверьте, что для объекта «Web-сервис» установлено право «Использование». Дополнительно в файле публикации default.vrd может быть явно задан список доступных сервисов через элемент point — если список есть, а сервиса в нём нет, доступ будет закрыт.

Для интеграций рекомендуется заводить отдельного технического пользователя с минимально необходимыми правами: только на нужный веб-сервис и на те объекты данных, которые читает или изменяет его код. Так проще и безопаснее, чем публиковать сервис под административной учётной записью.

Проверка по HTTPS и типичные проблемы с сертификатами

Если публикация работает по HTTPS, браузер дополнительно проверяет сертификат сервера. Предупреждение «Подключение не защищено» при самоподписанном сертификате — ожидаемое поведение: для диагностики можно временно продолжить переход, но внешняя система при таком сертификате, скорее всего, откажется соединяться, если не отключить у неё проверку или не добавить сертификат в доверенные.

Если WSDL открывается по HTTP, но не открывается по HTTPS, проверьте привязку сертификата к сайту в IIS или конфигурацию виртуального хоста Apache, а также открыт ли порт 443 на файрволе. Смешанная схема, когда WSDL получен по HTTPS, а точка подключения внутри него указана с http-адресом, — частая причина сбоев у потребителей: исправляется настройкой публикации или перезаписью адреса в файле default.vrd.

Что делать, если WSDL открывается, но операции не работают

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

Для ручной проверки операции сформируйте SOAP-запрос и отправьте его методом POST на адрес сервиса. В Postman это делается выбором метода POST, заголовком Content-Type: text/xml и телом запроса с SOAP-конвертом. Ответ с тегом Fault укажет на ошибку выполнения, корректный XML с данными — на успешный вызов.

curl -u Пользователь:Пароль "http://server/base/ws/Exchange?wsdl" -o service.wsdl -v

Команда curl с ключом -v покажет коды ответа и заголовки, что полезно, когда браузер скрывает детали. Сохранённый файл service.wsdl можно сравнить с тем, что получает внешняя система.

FAQ