Как проверить веб-сервис в 1С: от публикации до диагностики ошибок

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

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

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

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

Также уточните, какой тип сервиса проверяется. В 1С есть классические SOAP-сервисы (объект «Web-сервисы») и HTTP-сервисы (объект «HTTP-сервисы»). У них разный формат URL и разные способы тестирования: SOAP проверяется через WSDL и вызов операций, HTTP-сервис — прямыми GET/POST-запросами к шаблону URL.

Шаг 1. Проверка публикации и получение WSDL

Самая быстрая проверка — открыть в браузере адрес вида http://сервер/ИмяБазы/ws/ИмяСервиса?wsdl. Для HTTP-сервисов используется путь http://сервер/ИмяБазы/hs/КорневойURL/.... Если в ответ приходит XML-документ с описанием сервиса — публикация работает, веб-сервер передаёт запросы платформе 1С.

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

Ошибка 401 или запрос логина и пароля, который не принимает корректные данные, указывает на проблему аутентификации. Убедитесь, что пользователь существует в базе, у него есть право на использование сервиса и на веб-сервере настроен подходящий метод аутентификации (Basic или анонимный доступ).

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

Шаг 2. Тестирование операций через SoapUI или Postman

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

Для HTTP-сервисов удобнее Postman или curl. Отправьте GET или POST-запрос на URL шаблона сервиса, задайте заголовки (Content-Type, Authorization) и тело запроса, если оно требуется. Корректный ответ — HTTP 200 с ожидаемыми данными в JSON, XML или другом формате, который возвращает ваш код.

curl -u Пользователь:Пароль -X GET "http://server/base/hs/api/goods/123" -H "Accept: application/json"

Для SOAP-сервиса тот же тест через curl выглядит сложнее — нужно сформировать SOAP-конверт. Проще взять готовый шаблон из SoapUI и подставить свои значения параметров.

Шаг 3. Проверка из тестовой обработки 1С

Если сервис будут вызывать другие базы 1С, полезно проверить его именно из 1С — через WS-ссылки или программное создание WS-прокси. В конфигураторе добавьте WS-ссылку (ветка «Общие» → «WS-ссылки»), укажите URL WSDL — если ссылка создалась без ошибок, платформа успешно прочитала описание сервиса.

Вызов операции выполняется через объект WSПрокси. Ниже пример кода для теста:

Определение = Новый WSОпределения("http://server/base/ws/TestService?wsdl",
"Пользователь", "Пароль");
Прокси = Новый WSПрокси(Определение,
"http://example.org/webservice", "TestService", "TestServiceSoap");
Результат = Прокси.TestOperation("Проверка связи");
Сообщить(Результат);

Если вызов из 1С не работает, а из SoapUI работает — проблема обычно в прокси-сервере, настройках безопасного соединения (TLS) или в версии платформы на стороне клиента. Проверьте, доступен ли сервер с машины, где запускается клиент 1С.

Диагностика по HTTP-кодам ошибок

Код ответа веб-сервера — главный индикатор, на каком уровне сбой. Ниже типовые ситуации при проверке сервисов 1С.

Журнал регистрации и отладка кода сервиса

Когда сервис возвращает ошибку 500, источник — код операции внутри 1С. Откройте журнал регистрации (в режиме предприятия: «Администрирование» → «Обслуживание» → «Журнал регистрации») и отфильтруйте события по пользователю, под которым выполняется вызов. Там будет текст исключения с указанием модуля и строки.

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

Типовые проблемы и их устранение

Чаще всего проверка выявляет не сложные дефекты кода, а ошибки окружения. Ниже — ситуации, которые встречаются регулярно.

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

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