Как отлаживать HTTP-сервис в 1С

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

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

Материал подходит для платформы 8.3.x. Описанные приёмы работают как в клиент-серверном, так и в файловом варианте, но есть различия в настройке, которые отдельно отмечены в соответствующих разделах.

Почему точка останова в HTTP-сервисе не срабатывает

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

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

Третья причина — запрос обрабатывается, но падает раньше точки останова: например, на этапе маршрутизации URL-шаблона или из-за ошибки аутентификации. В этом случае полезно временно поставить точку останова на самую первую строку обработчика и включить остановку по ошибке.

Включение отладки на сервере и в файловой базе

В клиент-серверном варианте агент сервера 1С должен быть запущен с ключом отладки. На Windows это делается через реестр в параметре ImagePath службы «Агент сервера 1С:Предприятия» — в строку запуска добавляется -debug. На Linux ключ добавляется в скрипт запуска или unit-файл systemd. После изменения службу необходимо перезапустить, иначе режим не применится.

В файловом варианте при работе через веб-сервер (IIS или Apache) отладка включается параметром публикации. При публикации из конфигуратора (Администрирование → Публикация на веб-сервере) в файле default.vrd задаётся атрибут debug="true" в элементе point для http-сервисов. Альтернативный способ — запустить отладку прямо из конфигуратора: тогда платформа поднимает встроенный механизм отладки файловой базы без внешнего веб-сервера, но это подходит только для проверки логики, а не реальной публикации.

Настройка автоматического подключения предмета отладки

Ключевой шаг — разрешить конфигуратору автоматически подключать сеансы HTTP-сервисов. Откройте в конфигураторе: Отладка → Подключение → кнопка «Автоматическое подключение». В списке типов предметов отладки отметьте «HTTP-сервисы» (в новых версиях платформы пункт может называться «Сервисы http»). Без этой настройки сеанс обработки запроса не появится в списке доступных для подключения.

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

Если автоподключение не срабатывает, можно подключить сеанс вручную: Отладка → Подключение, в списке найти сеанс с типом «HTTP-сервис» и подключить его. Это удобно, когда запрос обрабатывается долго (фоновая выгрузка) и сеанс живёт достаточно долго, чтобы успеть подключиться.

1. 1
   Убедитесь, что сервер запущен в режиме отладки или в публикации файловой базы включён debug
2. 2
   В конфигураторе откройте Отладка → Подключение → Автоматическое подключение и отметьте «HTTP-сервисы»
3. 3
   Поставьте точку останова в первой строке функции-обработчика шаблона URL
4. 4
   Отправьте HTTP-запрос из браузера, Postman или curl на адрес публикации
5. 5
   Дождитесь остановки в конфигураторе, проверьте параметры запроса через табло и стек вызовов
6. 6
   Снимите точку останова и отпустите выполнение, чтобы клиент получил ответ

Как отправить тестовый запрос к сервису

Для GET-запросов без тела проще всего использовать браузер: достаточно открыть адрес вида http://server/base/hs/api/data?param=1. Однако браузер не подходит для методов POST, PUT, DELETE и для запросов с телом в формате JSON — здесь нужен специальный инструмент.

Наиболее распространённые варианты — Postman, Insomnia или консольная утилита curl. В них можно задать метод, заголовки (например, Content-Type: application/json), тело запроса и базовую аутентификацию. Curl удобен для быстрых проверок из командной строки и для автоматизации тестовых прогонов в скриптах.

curl -X POST "http://server/base/hs/orders/create" -H "Content-Type: application/json" -u user:password -d "{\"number\":\"0001\",\"sum\":1500}" -i

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

Что смотреть в отладчике при остановке

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

Частая ошибка — чтение тела дважды. Тело HTTP-запроса в 1С можно прочитать только один раз: если вы уже вызвали ПолучитьТелоКакСтроку() в отладочном табло, повторный вызов в коде вернёт пустую строку. Поэтому при отладке лучше сохранять тело в локальную переменную в начале обработчика и работать дальше с ней.

Для формирования ответа используйте объект HTTPСервисОтвет: задавайте код состояния, заголовки и тело. В отладчике удобно проверять объект ответа перед возвратом из функции — так видно, какой именно JSON или текст уйдёт клиенту, и корректен ли код состояния (200, 201, 400, 500).

Диагностика ошибок без точек останова

Не всегда есть возможность остановить выполнение: например, ошибка воспроизводится только на сервере заказчика или только под нагрузкой. В таких случаях помогает технологический журнал. Включите в logcfg.xml события EXCP (исключения) и, при необходимости, HTTP-события — в журнале будут видны тексты ошибок с контекстом сеанса HTTP-сервиса.

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

Полезно также включить остановку по ошибке в конфигураторе (Отладка → Остановка по ошибке) с фильтром по тексту. Тогда отладчик остановится именно в момент исключения, даже если оно возникает глубоко в общих модулях, вызванных из обработчика сервиса.

Ограничения и альтернативные подходы

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

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

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

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