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

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

Главная сложность в том, что веб-сервис 1С живёт на стыке нескольких компонентов: конфигурации, сервера 1С или файловой базы, веб-сервера (IIS или Apache) и сетевой инфраструктуры. Сбой в любом звене даёт похожий симптом — «сервис не отвечает», — но лечится по-разному. Поэтому проверку стоит строить как цепочку исключений, а не как хаотичный перебор настроек.

Материал ориентирован на администраторов и разработчиков 1С, которым нужно быстро локализовать проблему: убедиться, что публикация работает, WSDL-описание отдаётся, операции выполняются, а ошибки читаются из логов. Отдельно разобраны HTTP-сервисы, которые проверяются проще, но имеют свои особенности.

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

Для осмысленной диагностики нужны три вещи: адрес публикации, учётные данные и понимание, какой тип сервиса вы проверяете. Адрес публикации обычно выглядит как http://имя_сервера/имя_публикации/ws/ИмяСервиса для SOAP-сервиса или http://имя_сервера/имя_публикации/hs/шаблон для HTTP-сервиса. Имя публикации совпадает с именем виртуального каталога, который задавался при публикации базы на веб-сервере.

Учётная запись, под которой выполняется вызов, должна существовать в списке пользователей информационной базы и иметь права на использование веб-сервиса. Частая ситуация: сервис опубликован корректно, но вызов падает с ошибкой 401, потому что пользователь заведён в Active Directory, а в самой базе 1С его нет, либо у него не установлено право на конкретный сервис в роли.

Также уточните, какой веб-сервер обслуживает публикацию — IIS или Apache. Это важно, потому что логи, механизмы аутентификации и типичные сбои у них разные. Если вы не публиковали базу сами, спросите у администратора путь к файлу default.vrd — в нём описаны все опубликованные сервисы и параметры подключения к базе.

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

Самый быстрый тест не требует никаких инструментов, кроме браузера. Откройте адрес сервиса с суффиксом ?wsdl, например: http://server/trade/ws/Orders?wsdl. Браузер запросит логин и пароль — введите учётные данные пользователя базы 1С. Если в ответ загружается XML-документ с описанием операций, базовая цепочка работает: веб-сервер принял запрос, нашёл публикацию, подключился к базе и сформировал описание сервиса.

Для HTTP-сервиса суффикс ?wsdl не применяется — проверяйте прямой вызов шаблона URL, который реализован в методе сервиса. Если метод обрабатывает GET-запросы, откройте полный адрес вида http://server/trade/hs/exchange/ping и оцените ответ: JSON, XML или текст с кодом 200 означают, что сервис отвечает.

Выполняйте проверку сначала с самого сервера (через localhost), затем с рабочей станции в локальной сети, и только потом — извне, если сервис должен быть доступен снаружи. Так вы отделите проблемы публикации от проблем сети: если на localhost всё работает, а с соседней машины нет, виноваты брандмауэр, DNS или сетевые правила, а не 1С.

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

Шаг 2. Расшифруйте коды ошибок HTTP

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

Ошибка 404 — самая частая при первичной настройке. Проверьте, что имя публикации в URL точно совпадает с именем виртуального каталога (регистр символов на Apache имеет значение), а сам сервис объявлен в файле default.vrd внутри элемента <ws>. Если сервис добавили в конфигурацию после публикации, публикацию нужно обновить — иначе веб-сервер о нём просто не знает.

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

Шаг 3. Выполните тестовый вызов операции

Полученный WSDL подтверждает только доступность сервиса, но не работоспособность его логики. Следующий шаг — реальный вызов операции с тестовыми данными. Для SOAP-сервисов удобнее всего использовать SoapUI или Postman: импортируйте WSDL, сформируйте запрос, укажите Basic-аутентификацию и отправьте запрос. Успешный ответ с кодом 200 и осмысленным содержимым означает, что сервис работает полностью.

Для HTTP-сервисов достаточно Postman или даже curl. Укажите метод (GET/POST), заголовки авторизации и тело запроса, если оно требуется. Проверяйте не только «отвечает ли», но и содержимое ответа: сервис может возвращать код 200 с сообщением об ошибке в теле — это зависит от того, как написан обработчик.

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

Для тестов используйте данные, которые не испортят учёт: если операция создаёт документы в базе, выполняйте вызов на копии базы или используйте операции только на чтение. Вызов SOAP-операции — это полноценное выполнение кода в базе со всеми последствиями: проведение документов, запись регистров, запуск подписок на события.

Шаг 4. Проверьте публикацию и файл default.vrd

Если браузер возвращает 404 или 500 уже на этапе WSDL, разбирайтесь с публикацией. Откройте файл default.vrd в каталоге публикации и проверьте ключевые параметры: строку подключения к базе (атрибут ib), имя публикации и наличие нужного сервиса в секциях <ws> или <httpServices>. Ошибка в строке подключения — например, устаревший путь к файловой базе или недоступный сервер 1С — даёт ошибку 500 ещё до выполнения любого кода.

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

Отдельный случай — файловая база, опубликованная на веб-сервере. Веб-сервер обращается к файлу базы от имени своей учётной записи (для IIS это обычно учётная запись пула приложений). Если у этой учётной записи нет прав на чтение и запись каталога базы, сервис будет отвечать ошибкой 500. Проверьте NTFS-права на каталог базы и на каталог с служебными файлами публикации.

Шаг 5. Разберите ошибки через журнал регистрации и логи

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

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

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

Особенности проверки HTTP-сервисов

HTTP-сервисы в 1С легче тестировать, потому что они работают с обычными HTTP-запросами без SOAP-обёртки. Любой шаблон URL можно вызвать напрямую из браузера (для GET) или из Postman/curl (для POST, PUT, DELETE). Ответ приходит в том виде, в каком его сформировал код: JSON, XML, двоичные данные или просто текст с кодом состояния.

Обратите внимание на соответствие метода запроса шаблону: если в конфигурации для шаблона разрешён только POST, GET-запрос вернёт ошибку 405. Также проверяйте заголовки Content-Type при отправке тела — если обработчик ожидает JSON, а вы отправили form-data, запрос может отклониться или обработаться некорректно.

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

Регулярный мониторинг вместо разовой проверки

Разовая проверка решает текущую проблему, но не защищает от следующей. Если веб-сервис критичен для бизнес-процессов, настройте простейший мониторинг: периодический запрос к лёгкой операции сервиса (или к ?wsdl) с контролем кода ответа и времени выполнения. Это может делать любая система мониторинга — Zabbix, Nagios или даже плановый скрипт на PowerShell с отправкой уведомления при отказе.

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

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