Отладка SOAP- и HTTP-сервисов 1С: от точки останова до профилирования

Веб-сервис 1С отлаживают тем же отладчиком Конфигуратора, что и обычный код: включите отладку в файле публикации default.vrd, затем в Конфигураторе откройте Отладка → Подключение и в автоматическом подключении отметьте предметы «Web-сервис» и «HTTP-сервис». После этого точка останова в модуле сервиса срабатывает при каждом входящем запросе от Postman, SoapUI или внешней системы.

Частое заблуждение — что код веб-сервиса «невозможно отладить», и единственный способ разобраться в ошибке — писать сообщения в журнал. Журнал и логи нужны, но для другого: чтобы ловить сбои в рабочей базе, где отладчик подключать нельзя. Ниже — инструменты и методы для обоих случаев: на тестовом стенде и в бою.

Подготовка: как включить отладчик для вызовов веб-сервиса

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

1. Отладка в файле публикации

Откройте default.vrd в каталоге публикации и добавьте в корневой элемент point строку:

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

Порт 1550 — порт сервера отладки по умолчанию. Если вы меняли его в параметрах Конфигуратора, укажите свой.

2. Протокол отладки в Конфигураторе

В Конфигураторе: Сервис → Параметры → Отладка — выберите отладку по протоколу HTTP. Протокол в Конфигураторе и в default.vrd должен совпадать, иначе предмет отладки не появится.

3. Сервер 1С в режиме отладки (только клиент-серверная база)

Для файловой базы этого шага нет. В клиент-серверном варианте служба агента сервера должна быть запущена с ключами -debug -http. Ключи дописывают в параметры запуска службы ragent.exe, после чего службу перезапускают.

Перезапуск службы сервера 1С завершает все сеансы пользователей. Включайте отладку сервера на тестовом стенде, а не в рабочем кластере.

4. Автоматическое подключение

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

Журнал регистрации: что видно о вызовах сервиса без правок кода

Журнал регистрации — первый инструмент, когда ошибка случилась в рабочей базе. Каждый вызов сервиса открывает сеанс, и в журнале у него в колонке «Приложение» стоит «Web-сервис» или «HTTP-сервис».

Где открыть журнал:

• в Конфигураторе: Администрирование → Журнал регистрации;
• в типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11): Администрирование → Обслуживание → Журнал регистрации.

Как отфильтровать вызовы:

1. 🔎 Установите отбор по приложению — только веб-сервисы или HTTP-сервисы.
2. 👤 Добавьте отбор по пользователю, под которым ходит внешняя система.
3. 🕒 Сузьте интервал до минут вокруг сбоя — так проще связать ошибку с конкретным запросом.
4. ❗ Включите уровень «Ошибка»: необработанное исключение в модуле сервиса попадает туда с текстом и строкой модуля.

Чего журнал не покажет: тело входящего запроса и сформированный ответ. Для этого нужно логирование в коде или перехват трафика.

Логирование в модуле сервиса: свои записи о каждом запросе

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

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

    ТелоЗапроса = Запрос.ПолучитьТелоКакСтроку();
    ЗаписьЖурналаРегистрации("Интеграция.ВходящийЗаказ",
        УровеньЖурналаРегистрации.Информация, , ,
        ТелоЗапроса);

    Попытка
        Результат = ОбработатьЗаказ(ТелоЗапроса);
        Ответ = Новый HTTPСервисОтвет(200);
        Ответ.УстановитьТелоИзСтроки(Результат);
    Исключение
        ТекстОшибки = ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
        ЗаписьЖурналаРегистрации("Интеграция.ВходящийЗаказ",
            УровеньЖурналаРегистрации.Ошибка, , ,
            ТекстОшибки);
        Ответ = Новый HTTPСервисОтвет(500);
        Ответ.УстановитьТелоИзСтроки("Ошибка обработки заказа. Подробности в журнале регистрации.");
    КонецПопытки;

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

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

Что даёт такая схема:

• ✅ своё имя события — по нему фильтруют журнал за секунды;
• ✅ подробное описание ошибки со стеком остаётся в базе, а не уходит наружу;
• ✅ внешняя система получает понятный код 500, а не «упавший» сеанс.

В SOAP-сервисе исходный XML в обработчик не попадает: платформа сама разбирает его в объекты XDTO. Логируйте значения параметров операции, а сырой конверт смотрите сниффером (следующий раздел).

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

Перехват трафика сниффером: смотрим, что реально летит по сети

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

Как направить исходящие запросы 1С через Fiddler

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

Прокси = Новый ИнтернетПрокси;
Прокси.Установить("http", "127.0.0.1", 8888);
Прокси.Установить("https", "127.0.0.1", 8888);

Соединение = Новый HTTPСоединение("api.example.ru", 443, , , Прокси, 30,
    Новый ЗащищенноеСоединениеOpenSSL());

Для SOAP-клиента прокси передают в конструктор WSОпределения и WSПрокси. При перехвате HTTPS платформа увидит сертификат Fiddler вместо сертификата сервера; на тестовом стенде это решают установкой корневого сертификата Fiddler в хранилище Windows и использованием Новый СертификатыУдостоверяющихЦентровWindows() в защищённом соединении.

Не оставляйте прокси и подменённый сертификат в рабочей базе — после расследования уберите их из кода и хранилища.

Входящие запросы

Для входящих вызовов настройте прокси на стороне вызывающей системы. Если это невозможно, смотрите логи веб-сервера: IIS пишет журнал в %SystemDrive%\inetpub\logs\LogFiles, Apache — в access.log и error.log. Там видны адрес, метод, код ответа и время обработки.

Тестирование через HTTP-клиент: SoapUI, Postman, curl

Отлаживать сервис, дожидаясь вызова от партнёра, долго. Поднимите запросы сами.

Адреса для проверки

• SOAP-сервис: http://сервер/имя_публикации/ws/имя_сервиса?wsdl — по этому адресу должен открыться WSDL. Если открылся, публикация и авторизация в порядке.
• HTTP-сервис: http://сервер/имя_публикации/hs/корневой_URL/шаблон.

Инструменты

1. SoapUI — создайте SOAP-проект, укажите адрес WSDL. Программа сама построит шаблоны конвертов для всех операций. Логин и пароль пользователя 1С задаются во вкладке авторизации запроса (Basic).
2. Postman — для HTTP-сервисов. Сохраните запросы в коллекцию, вынесите адрес и учётные данные в переменные окружения: одна коллекция работает и с тестовой, и с рабочей базой.
3. curl — для быстрой проверки и для скриптов:

curl -s -o otvet.json -w "%%{http_code}" -u "integration:Pa55word" ^
  -H "Content-Type: application/json; charset=utf-8" ^
  --data-binary @zakaz.json ^
  http://srv1c/trade/hs/api/orders

Команда сохранит ответ в файл и выведет код ответа. Удвоенный знак процента нужен только внутри bat-файла; в командной строке пишите один.

Автоматизация проверок

Набор таких вызовов превращается в регрессионный тест. Коллекцию Postman прогоняют из командной строки утилитой newman, в SoapUI есть тестовые наборы с проверками (assertions) на содержимое ответа. Запускайте их после каждого обновления конфигурации — сломанный контракт сервиса всплывёт до жалобы партнёра.

Разбор типовых ошибок и исключений веб-сервисов

Первое, на что смотреть, — код ответа. Он сразу говорит, на каком уровне сломалось: веб-сервер, авторизация или ваш код.

Кодировка и формат даты

Частый источник «загадочных» расхождений в интеграциях — кодировка и даты. Для кириллицы явно указывайте charset=utf-8 в заголовке Content-Type, а при чтении тела задавайте кодировку: Запрос.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8). Даты в JSON и XML передавайте в формате ISO 8601 и при разборе приводите к типу Дата, не полагаясь на строковые преобразования.

Профилирование и оптимизация производительности сервиса

Медленный сервис отлаживают иначе: важна не строка с ошибкой, а строка, где уходит время.

Замер производительности

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

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

На рабочем сервере отладчик не подключить, но можно включить технологический журнал. Его настраивают файлом logcfg.xml в каталоге conf платформы. Для разбора сервиса полезны события:

• EXCP — исключения;
• CALL — серверные вызовы с длительностью и памятью;
• DBMSSQL или DBPOSTGRS — запросы к СУБД;
• TLOCK и TTIMEOUT — управляемые блокировки и таймауты на них.

Технологический журнал без фильтров быстро забивает диск. Ограничивайте события длительностью, задавайте history в часах и выключайте журнал после расследования.

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

По умолчанию каждый вызов сервиса открывает новый сеанс: авторизация, инициализация параметров сеанса, модуль сеанса. На частых коротких вызовах это основная доля времени. В default.vrd для веб-сервисов и HTTP-сервисов можно включить пул сеансов атрибутами reuseSessions, sessionMaxAge и poolSize:

<ws pointEnableCommon="true">
  <point name="Orders" alias="orders.1cws" enable="true"
         reuseSessions="autouse" sessionMaxAge="20" poolSize="10"/>
</ws>

Атрибут reuseSessions принимает значения dontuse, use и autouse; sessionMaxAge задаёт время жизни сеанса в секундах, poolSize — размер пула. Учтите: при повторном использовании переменные модуля сеанса живут между вызовами, и код не должен на это закладываться.

Что ещё ускоряет сервис

1. ⚙️ Тяжёлую обработку выносите в фоновое задание, а внешней системе сразу отвечайте «принято» с идентификатором — статус она запросит отдельным методом.
2. 📦 Отдавайте данные постранично: параметры limit и offset в HTTP-сервисе спасают от ответов на десятки мегабайт.
3. 🔒 Проверьте блокировки: если сервис пишет в те же регистры, что и пользователи, ожидание блокировки съедает секунды. Это видно по событиям TLOCK в техжурнале.

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