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

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

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

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

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

Для проверки потребуется минимум четыре вещи: адрес публикации сервиса, имя пользователя и пароль с правами на вызов, инструмент для отправки запросов и тестовые данные. Адрес публикации складывается из адреса веб-сервера, имени публикации базы и имени веб-сервиса, заданного в конфигураторе.

Уточните у администратора, на каком веб-сервере опубликована база — IIS или Apache, и как называется виртуальный каталог. Если публикацию делали вы сами, имя каталога видно в диалоге публикации в конфигураторе (Администрирование → Публикация на веб-сервере).

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

Проверка доступности сервиса через браузер

Первый и самый быстрый тест — запрос WSDL-описания. Откройте браузер и введите адрес вида: http://server/base/ws/ServiceName?wsdl. Если сервис опубликован корректно, браузер запросит логин и пароль, а затем покажет XML-документ с описанием операций, параметров и типов данных.

Ответ сервера сразу показывает, на каком уровне проблема. Ошибка 404 означает, что публикация не выполнена или адрес набран неверно. Ошибка 500 обычно указывает на сбой в расширении веб-сервера или недоступность базы. Запрос авторизации, который не принимает верный пароль, говорит о проблеме с аутентификацией на веб-сервере.

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

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

Postman тоже подходит, хотя и менее удобен для SOAP: запрос придётся формировать вручную как POST с XML-телом, заголовком Content-Type: text/xml и, при необходимости, заголовком SOAPAction. Этот способ полезен, когда нужно быстро отправить один запрос без создания проекта.

Успешный вызов возвращает SOAP-ответ с данными. Если приходит SOAP Fault — читайте текст ошибки: 1С передаёт туда описание исключения из кода операции, что сильно упрощает диагностику. Типичные сообщения: «Операция не найдена», ошибки преобразования типов XDTO, исключения из прикладного кода.

1. 1
   Создайте проект: File → New SOAP Project, укажите URL с ?wsdl
2. 2
   Дождитесь загрузки списка операций и откройте Request 1 нужной операции
3. 3
   В Auth выберите Basic и введите логин и пароль пользователя 1С
4. 4
   Замените знаки вопроса в параметрах на тестовые значения
5. 5
   Нажмите зелёную стрелку и изучите ответ: данные или SOAP Fault

Проверка веб-сервиса средствами самой 1С

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

Для быстрой проверки без изменения конфигурации напишите тестовую внешнюю обработку. В ней создайте WSПрокси динамически и вызовите операцию, обернув вызов в попытку-исключение, чтобы увидеть текст ошибки.

Попытка
    Определения = Новый WSОпределения("http://server/base/ws/ServiceName?wsdl", "Логин", "Пароль");
    Прокси = Новый WSПрокси(Определения, "http://example.org/", "ServiceName", "ServiceNameSoap");
    Результат = Прокси.MyOperation("Тест");
    Сообщить("Ответ: " + Результат);
Исключение
    Сообщить("Ошибка: " + ОписаниеОшибки());
КонецПопытки;

Обратите внимание на второй параметр конструктора WSПрокси — URI пространства имён. Он должен точно совпадать с тем, что указан в свойствах веб-сервиса в конфигураторе. Несовпадение пространства имён — частая причина ошибки «Операция не найдена» при внешне правильном коде.

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

Большинство проблем при проверке веб-сервиса сводится к ограниченному набору причин. Полезно идти по списку сверху вниз, исключая уровни по очереди: сеть, веб-сервер, публикация, аутентификация, права, код операции.

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

Отладка кода операции в конфигураторе

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

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

Проверка производительности и стабильности

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

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

Часто задаваемые вопросы