Как поймать ошибку в веб-сервисе 1С: отладчик, журналы и тестовые запросы

Чтобы отладить веб-сервис в 1С 8.3, включите в Конфигураторе отладку по протоколу HTTP, добавьте в файл публикации default.vrd строку <debug enable="true" protocol="http" url="http://localhost:1550"/> и в окне Отладка → Подключение настройте автоматическое подключение сеансов веб-сервиса и HTTP-сервиса. После этого точка останова в модуле сервиса срабатывает при каждом внешнем запросе.

Остальная работа — найти, где именно ломается обмен: на веб-сервере, в публикации, в правах или в коде обработчика. Порядок ниже сужает круг поиска от простого к сложному. Инструкция подходит и для SOAP веб-сервисов, и для HTTP-сервисов (REST): механизм отладки у них общий.

Подготовка: что проверить до запуска отладчика

Отладку веб-сервиса начинают не с точки останова, а с окружения. Половина «ошибок в коде» на деле оказывается старой конфигурацией базы или чужой публикацией.

Проверьте по списку:

• 🧪 Тестовая база. Отлаживать на рабочей базе нельзя: точка останова держит сеанс, а внешняя система тем временем получает таймаут. Сделайте копию и опубликуйте её отдельно.
• 🔄 Конфигурация базы обновлена. Веб-сервис работает с конфигурацией базы данных, а не с основной конфигурацией в Конфигураторе. После правок нажмите F7 (Конфигурация → Обновить конфигурацию базы данных). Иначе отладчик покажет старый код, а точки останова «съедут».
• 🌐 Веб-сервер и модуль расширения. На машине должен стоять Apache или IIS и модуль веб-расширения той же версии платформы, что и сервер 1С.
• 👤 Пользователь для сервиса. Если в публикации не задан пользователь, клиент передаёт логин и пароль сам. У этого пользователя должны быть права на объекты, которые трогает код.

Проверка публикации веб-сервиса: WSDL и адрес HTTP-сервиса

Первая проверка занимает минуту и отсекает целый класс проблем. Откройте адрес сервиса в браузере или через curl.

Для SOAP веб-сервиса запросите описание WSDL:

curl -u Integration:Pass123 "http://srv01/trade/ws/Orders?wsdl"

Для HTTP-сервиса — любой метод GET из шаблона URL:

curl -i -u Integration:Pass123 "http://srv01/trade/hs/api/orders/125"

Здесь trade — имя публикации, Orders — адрес веб-сервиса из его свойств, api — корневой URL HTTP-сервиса. Ключ -i выводит заголовки ответа вместе с кодом.

Как читать ответ:

Откройте default.vrd в каталоге публикации. Каждый сервис, который должен отвечать, присутствует в секции ws или httpServices. Если при публикации сняли флажок у нужного сервиса, его там нет — и запрос получит 404, хотя в конфигурации всё есть.

Как включить отладку веб-сервиса в 1С

Отладка сеансов веб-сервисов работает только по протоколу HTTP. Протокол TCP, который многие используют по привычке, для них не подходит.

Файловая база

1. В Конфигураторе откройте Сервис → Параметры, вкладку «Отладка».
2. Выберите протокол отладки HTTP. Конфигуратор сам поднимет сервер отладки dbgs — по умолчанию на порту 1550.
3. Добавьте в default.vrd внутрь элемента point строку:

<debug enable="true" protocol="http" url="http://localhost:1550"/>

4. Перезапустите веб-сервер.
5. Откройте Отладка → Подключение, нажмите «Автоматическое подключение» и отметьте сеансы веб-сервиса и HTTP-сервиса.

Клиент-серверная база

Для серверной базы сервер 1С тоже должен работать в режиме отладки по HTTP. Агент сервера запускают с ключами -debug -http. Если служба создана стандартным установщиком, ключи дописывают в командную строку службы ragent.exe.

В url атрибута debug укажите адрес сервера отладки, доступный с сервера 1С. Если Конфигуратор запущен на машине разработчика dev-pc, это будет http://dev-pc:1550, а порт 1550 должен быть открыт в брандмауэре.

Строка с debug в публикации рабочей базы — уязвимость. Удалите её после окончания отладки.

Точки останова и пошаговая отладка обработчика

Когда подключение настроено, поставьте точку останова (F9) в первую строку функции-обработчика операции. Для веб-сервиса это функция, указанная в свойстве «Процедура» операции. Для HTTP-сервиса — обработчик метода шаблона URL.

Отправьте запрос из Postman или curl. Конфигуратор остановится на точке, а в окне Отладка → Подключение появится предмет отладки — сеанс веб-сервиса.

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

• 📥 Тело запроса. В HTTP-сервисе вычислите Запрос.ПолучитьТелоКакСтроку() в окне «Вычислить выражение» (Shift+F9). Сразу видно, что пришло на самом деле, а не что «должно было прийти».
• 🔗 Параметры. Запрос.ПараметрыURL — части адреса из шаблона, Запрос.ПараметрыЗапроса — всё после знака ?.
• 📋 Заголовки. Запрос.Заголовки покажет Content-Type и кодировку, которые прислал клиент.
• 👤 Пользователь. ПользователиИнформационнойБазы.ТекущийПользователь().Имя — от чьего имени идёт сеанс.

Ловушка повторного использования сеансов

У веб-сервисов и HTTP-сервисов есть свойство «Повторное использование сеансов». Если оно включено, второй и последующие запросы идут в уже открытый сеанс. Код установки параметров сеанса и модуль сеанса при этом не выполняются.

Отсюда частая путаница: точка останова в УстановкаПараметровСеанса срабатывает один раз и больше никогда. Чтобы поймать этот код, на время отладки поставьте «Не использовать» и обновите конфигурацию базы.

Отладка логики без HTTP

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

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

Внешняя система редко пишет, что именно сломалось. Обычно она получает код 500 или SOAP Fault с куском текста. Полную картину дают журналы на стороне 1С.

Журнал регистрации

Платформа сама пишет в журнал регистрации ошибки, возникшие в сеансе сервиса. Откройте Все функции → Стандартные → Журнал регистрации, задайте отбор по пользователю интеграции и по уровню «Ошибка». В колонке «Приложение» видно, что событие пришло из сеанса веб-сервиса, а не от пользователя.

Свои события пишите явно — особенно в блоке Исключение:

Функция ЗаказGET(Запрос)

    Ответ = Новый HTTPСервисОтвет(200);

    Попытка
        НомерЗаказа = Запрос.ПараметрыURL["Номер"];
        ТекстJSON = Интеграция.ДанныеЗаказаJSON(НомерЗаказа);
        Ответ.УстановитьТелоИзСтроки(ТекстJSON, КодировкаТекста.UTF8);
        Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Исключение
        Подробно = ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
        ЗаписьЖурналаРегистрации("Интеграция.ЗаказGET",
            УровеньЖурналаРегистрации.Ошибка, , ,
            "Тело: " + Запрос.ПолучитьТелоКакСтроку() + Символы.ПС + Подробно);
        Ответ = Новый HTTPСервисОтвет(500);
        Ответ.УстановитьТелоИзСтроки("Ошибка обработки запроса, см. журнал регистрации");
    КонецПопытки;

    Возврат Ответ;

КонецФункции

Имя события с префиксом Интеграция. позволяет одним отбором собрать все ошибки обмена. Подробный текст с номером строки модуля остаётся в журнале, а клиент получает короткое сообщение без внутренностей базы.

Технологический журнал

Если ошибка не доходит до кода — падает рабочий процесс, обрывается соединение — нужен технологический журнал. Его включают файлом logcfg.xml в каталоге conf платформы (например, C:\Program Files\1cv8\conf):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\v8logs" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

События EXCP — исключения платформы. history="24" хранит логи 24 часа. Файл подхватывается без перезапуска, через минуту-другую. Уберите его, когда ошибка найдена: техжурнал на нагруженном сервере быстро занимает диск.

Лог веб-сервера

Когда 1С вообще не видит запрос, смотрите лог веб-сервера. У Apache это error.log в каталоге logs, у IIS — %SystemDrive%\inetpub\logs\LogFiles. Там видно, дошёл ли запрос и загрузился ли модуль wsap24.dll (или wsisapi.dll для IIS).

Тестирование веб-сервиса внешними клиентами

Не отлаживайте сервис через ту систему, которая будет его вызывать. У неё свои таймауты, кэш и обработка ошибок. Сначала добейтесь правильного ответа на «чистом» клиенте.

Пример вызова HTTP-сервиса с телом JSON:

curl -i -u Integration:Pass123 -X POST \
  -H "Content-Type: application/json; charset=utf-8" \
  -d "{\"number\":\"125\",\"sum\":1500}" \
  "http://srv01/trade/hs/api/orders"

Для SOAP из другой базы 1С используйте WSОпределения и WSПрокси. Задайте таймаут явно: пятый параметр конструктора WSОпределения — таймаут в секундах. Без него при остановке на точке клиент ждёт и сам может упасть по таймауту раньше, чем вы дойдёте до нужной строки.

Типовые ошибки веб-сервисов 1С и что с ними делать

Как упростить отладку интеграции в будущем

Сервис, который писали с расчётом на отладку, чинится за минуты. Несколько правил:

1. 🧱 Тонкий обработчик. Разбор запроса и ответ — в модуле сервиса, логика — в общем модуле. Так её можно вызвать из обработки и покрыть тестами.
2. 🧾 Единый формат ошибки. Отдавайте клиенту JSON с кодом и коротким текстом, а подробности пишите в журнал регистрации. Внешняя сторона сможет обработать ошибку программно.
3. 🔢 Честные коды HTTP. 400 — неверный запрос клиента, 404 — объект не найден, 500 — сбой на стороне 1С. Не отвечайте 200 с текстом «ошибка» внутри: мониторинг такой сбой не заметит.
4. 🪪 Идентификатор запроса. Принимайте или генерируйте УникальныйИдентификатор и пишите его в каждое событие журнала. По нему находят все записи одного вызова.
5. 🔒 Отладка только в тестовом контуре. Строка debug в публикации и ключ -debug у агента на рабочем сервере не нужны.
6. 📦 Версионирование адреса. Корневой URL вида api/v1 позволяет менять формат, не ломая старых клиентов.

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