Как отлаживать веб-сервисы 1С: практическое руководство

Отладка веб-сервисов 1С отличается от обычной отладки прикладного кода: обработчики сервисов выполняются не в клиентском сеансе, а в отдельном сеансе на сервере (или в процессе веб-сервера при файловой базе), поэтому точки останова «из коробки» часто не срабатывают. Разработчик вызывает сервис через SOAP или HTTP, видит только код ошибки 500 или пустой ответ — и не понимает, где искать причину.

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

Ниже разобраны настройка отладки для клиент-серверного и файлового вариантов, отладка HTTP-сервисов и SOAP-сервисов, работа с журналом регистрации, типичные ошибки публикации и способы проверки результата. Материал ориентирован на платформу 8.3 с актуальными механизмами отладки по протоколу HTTP.

Как устроено выполнение веб-сервисов и почему отладка не срабатывает

Когда внешняя система вызывает веб-сервис 1С, запрос принимает веб-сервер (Apache или IIS) и передаёт его в расширение веб-сервера 1С. Дальше код обработчика выполняется в сеансе на сервере 1С — в клиент-серверном варианте это рабочий процесс rphost, в файловом — процесс веб-сервера или отдельный сеанс. Ваш клиентский сеанс конфигуратора к этому процессу отношения не имеет.

Именно поэтому точка останова в модуле HTTP-сервиса или веб-сервиса игнорируется: отладчик подключён к вашему клиенту, а код выполняется в другом сеансе. Нужно либо включить автоматическое подключение отладчика к сеансам веб-сервисов, либо вручную подключиться к нужному процессу через список доступных предметов отладки.

Вторая частая причина — отладка на сервере выключена на уровне кластера. Сервер 1С по умолчанию запускается без поддержки отладки, и никакие настройки конфигуратора не помогут, пока служба сервера не перезапущена с соответствующим ключом.

Включение отладки на сервере 1С

Для клиент-серверного варианта службу агента сервера 1С нужно запустить с ключом отладки. В Windows это делается через изменение параметров запуска службы: в реестре или в свойствах службы в строку запуска добавляется параметр -debug, а для современного протокола отладки — -debug -http. После изменения службу необходимо перезапустить.

"C:\Program Files\1cv8\<версия>\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\srvinfo" -debug -http

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

Проверить, что сервер запущен с отладкой, можно через консоль кластера или косвенно — в конфигураторе при подключении отладки серверные предметы станут доступны для выбора. Если список пуст или подключение завершается ошибкой, почти всегда причина в отсутствии ключа -debug или в сетевых ограничениях (порт отладчика закрыт брандмауэром).

Настройка конфигуратора и публикации для отладки

В конфигураторе откройте меню «Отладка» → «Настройка» и убедитесь, что выбран протокол отладки HTTP — он работает через сервер 1С и не требует прямого сетевого доступа к клиентской машине, в отличие от устаревшего TCP-протокола. Там же включите автоматическое подключение к нужным типам предметов отладки: отметьте «Веб-сервисы» и, при необходимости, «HTTP-сервисы» и фоновые задания.

В свойствах публикации базы на веб-сервере (пункт «Администрирование» → «Публикация на веб-сервере») должен быть разрешён доступ к веб-сервисам и HTTP-сервисам, а также включён флажок, разрешающий отладку для публикации. Если публикация настроена вручную через файл default.vrd, проверьте, что в нём присутствует атрибут debug="true" и включены нужные точки входа.

После изменения публикации веб-сервер нужно перезапустить, иначе изменения в default.vrd не подхватятся. Для Apache это перезапуск службы httpd, для IIS — перезапуск пула приложений или команда iisreset.

1. 1
   Перезапустите службу сервера 1С с ключами -debug -http (на тестовой базе)
2. 2
   В конфигураторе включите протокол отладки HTTP и автоподключение к веб-сервисам
3. 3
   Проверьте публикацию: разрешены веб-сервисы и отладка, перезапустите веб-сервер
4. 4
   Установите точку останова в модуле сервиса
5. 5
   Вызовите сервис внешним клиентом (Postman, curl, внешняя система)
6. 6
   Убедитесь, что отладчик остановился в обработчике и показывает параметры запроса

Отладка HTTP-сервисов

HTTP-сервисы удобно вызывать напрямую инструментами вроде Postman, curl или Insomnia — это позволяет точно воспроизвести запрос внешней системы, включая заголовки, параметры URL и тело запроса. Сначала проверьте, что сервис вообще отвечает: отправьте простой GET-запрос на URL шаблона сервиса. Ответ 404 означает проблему с публикацией или шаблоном URL, 401/403 — с аутентификацией, 500 — ошибку в коде обработчика.

Когда точка останова в обработчике сработала, первым делом изучите объект HTTPСервисЗапрос: метод, относительный URL, параметры URL, заголовки и тело запроса через Запрос.ПолучитьТелоКакСтроку(). Большинство ошибок интеграций — это несоответствие фактического формата данных ожидаемому: другой порядок полей, лишние пробелы, даты в другом формате, BOM в начале JSON.

Если отладчик не останавливается, но сервис отвечает, проверьте три вещи: автоподключение к HTTP-сервисам в настройках отладки, актуальность конфигурации базы данных (код обновлён в конфигурации БД, а не только в конфигурации поставщика) и то, что запрос попадает именно в вашу базу, а не в другую публикацию на том же веб-сервере.

Отладка SOAP-сервисов

SOAP-сервисы сложнее вызвать вручную из-за обёртки XML-конверта, поэтому для тестирования используйте SoapUI или аналогичный инструмент, который строит запросы по WSDL-описанию. WSDL доступен по адресу публикации с параметром wsdl, например: /ws/ИмяСервиса.1cws?wsdl. Если WSDL не отдаётся — проблема в публикации, а не в коде.

Отладка самого кода операции ничем не отличается: точка останова в модуле веб-сервиса, автоподключение отладчика, вызов операции из SoapUI. Внутри обработчика проверяйте параметры XDTO — типичная проблема в том, что внешняя система присылает данные, не соответствующие пакетам XDTO конфигурации, и платформа ещё до входа в ваш код возвращает SOAP-ошибку сериализации.

Если ошибка возникает до точки останова, смотрите текст SOAP Fault в ответе: там обычно указано, какое поле не прошло проверку типа. Это сигнал сверить фактический XML с описанием пакета XDTO и при необходимости ослабить обязательность полей или скорректировать типы.

Логирование запросов и работа с журналом регистрации

Отладчик показывает ситуацию «здесь и сейчас», но в промышленной эксплуатации важнее история: какие запросы приходили, с какими данными и чем закончились. Минимальный набор — запись ошибок в журнал регистрации через ЗаписьЖурналаРегистрации() в блоке Попытка...Исключение каждого обработчика с указанием имени сервиса, операции и текста ошибки.

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

При анализе ошибок на стороне веб-сервера смотрите логи Apache или IIS: там видны коды ответов, время обработки и обращения к несуществующим URL. Связка «лог веб-сервера → журнал регистрации → собственное логирование» позволяет локализовать проблему на любом уровне без подключения отладчика.

Типичные ошибки и их устранение

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

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

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

Частые вопросы по отладке веб-сервисов 1С