1С: как проверить публикацию веб-сервиса

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

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

Ниже разобран полный цикл проверки: от запроса WSDL в браузере до тестового вызова операции, а также диагностика типичных ошибок HTTP 404, 500 и 401.

Что считается успешной публикацией веб-сервиса

Веб-сервис 1С считается корректно опубликованным, когда выполняются три условия. Во-первых, по URL сервиса с параметром ?wsdl возвращается XML-документ с описанием сервиса, его операций и типов данных. Во-вторых, SOAP-запрос к операции обрабатывается и возвращает осмысленный ответ, а не ошибку сервера. В-третьих, аутентификация проходит под предусмотренной учётной записью, а анонимный доступ закрыт, если он не планировался.

Формат адреса публикации обычно выглядит так: http://имя_сервера/имя_публикации/ws/ИмяВебСервиса, где имя публикации — это имя виртуального каталога, заданное при публикации базы. Имя веб-сервиса берётся из свойства «Имя» объекта в ветке «Общие — Web-сервисы» конфигурации, а не из синонима.

Проверка публикации через браузер по запросу WSDL

Самый быстрый способ — открыть в браузере адрес сервиса с суффиксом ?wsdl, например: http://srv1c/trade/ws/Exchange?wsdl. Если всё настроено верно, браузер покажет XML-документ (или предложит его скачать). Внутри должны быть элементы definitions, service с именем вашего сервиса и перечисление операций.

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

Ошибка 404 на этом шаге означает, что веб-сервер не находит публикацию: неверный URL, не создан виртуальный каталог или не выполнена публикация именно на этом сервере. Ошибка 500 говорит о том, что запрос дошёл, но возникла внутренняя проблема — чаще всего с доступом к базе или файлу default.vrd.

Проверка настроек публикации в конфигураторе

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

Проверьте файл публикации default.vrd в каталоге виртуального приложения. В нём должна присутствовать секция <ws> с элементами <point name="ИмяСервиса"> для каждого опубликованного сервиса. Если секции нет — сервисы физически не опубликованы, даже если галочки в конфигураторе стояли.

Тестовый вызов операции веб-сервиса

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

Проверка через soapUI или Postman

Инструмент soapUI (или аналогичный) позволяет импортировать WSDL по URL и автоматически сформировать шаблоны запросов ко всем операциям. Заполните обязательные параметры тестовыми значениями, укажите аутентификацию (Basic Auth с логином и паролем пользователя 1С) и отправьте запрос. Успешный ответ — SOAP-конверт с результатом операции. Ошибка вернётся как SOAP Fault с текстом исключения из 1С.

Проверка обработкой с WS-прокси из другой базы 1С

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

Определение = Новый WSОпределения("http://srv1c/trade/ws/Exchange?wsdl", "user", "password");
Прокси = Новый WSПрокси(Определение, "http://localhost/exchange", "Exchange", "ExchangeSoap");
Результат = Прокси.Ping("test");
Сообщить(Результат);

Имя пространства имён (второй параметр WSПрокси) берётся из свойства «URI пространства имен» веб-сервиса в конфигурации, а имя порта — из WSDL, элемент port внутри service.

Диагностика типичных ошибок

Большинство проблем публикации сводится к нескольким повторяющимся сценариям. Их удобно разбирать по коду HTTP-ответа.

Отдельный частый случай для IIS: не установлен или не сопоставлен модуль расширения веб-сервисов 1С (ISAPI). Проверьте, что при установке платформы были выбраны компоненты «Модули расширения веб-сервера», а в IIS разрешено выполнение ISAPI-расширений соответствующей разрядности. Для Apache проверяется подключение модуля wsap24.so (или аналогичного для вашей версии платформы) в httpd.conf.

Где искать диагностическую информацию

Если по HTTP-коду причина не ясна, смотрите журналы. Журнал регистрации информационной базы покажет ошибки сеансов веб-сервиса: отфильтруйте события по виду «Сеанс» и имени пользователя, под которым идёт обращение. Там видны ошибки аутентификации и исключения в коде операций.

Логи веб-сервера (access.log и error.log у Apache, журналы сайта в IIS) показывают, дошёл ли запрос до сервера и какой код он вернул. Если запроса нет в логах веб-сервера — проблема на уровне сети: файрвол, закрытый порт, неверное имя хоста. Проверьте доступность порта командой telnet сервер 80 или аналогом.

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

1. 1
   Убедиться, что в конфигураторе включена публикация Web-сервисов и отмечены нужные сервисы; нажать «Опубликовать»
2. 2
   Проверить наличие секции ws в файле default.vrd каталога публикации
3. 3
   Открыть в браузере URL сервиса с ?wsdl и получить XML-описание
4. 4
   Ввести учётные данные пользователя 1С при запросе аутентификации
5. 5
   Выполнить тестовый вызов операции через soapUI или WSПрокси
6. 6
   При ошибках — сверить HTTP-код с таблицей причин и проверить журналы веб-сервера и регистрации

Проверка безопасности перед передачей сервиса потребителям

Работающий сервис — ещё не безопасный сервис. Перед тем как отдать адрес внешней системе, убедитесь, что анонимный доступ закрыт: запрос ?wsdl без учётных данных должен возвращать 401, а не XML. Если WSDL доступен анонимно, любой может изучить структуру операций и типов данных.

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

Для доступа извне локальной сети используйте HTTPS: базовая аутентификация передаёт логин и пароль в открытом виде, и без шифрования они перехватываются в трафике. Настройка сертификата выполняется средствами веб-сервера, а не 1С.

FAQ