HTTP Tester в 1С: как поймать баг за 10 минут вместо трёх дней ожидания

HTTP Tester — встроенный в конфигуратор 1С инструмент для проверки HTTP-сервисов: он отправляет тестовый запрос к сервису прямо из среды разработки и останавливает выполнение на точке останова в отладчике, без ожидания реального обращения от сайта, маркетплейса или мобильного приложения. До его появления разработчики либо ждали боевой запрос, либо гоняли curl отдельно от отладки — вслепую.

Заявка ушла, а в 1С — тишина

Оптовая компания на 1С:Управление торговлей — около полусотни сотрудников, склад и отдел продаж в одном офисе в Москве — принимает заказы с собственного сайта и с маркетплейса через HTTP-сервис: внешняя система шлёт POST-запрос с составом заказа, 1С создаёт документ и отвечает номером. Схема работала полгода без сбоев, пока в пятницу вечером склад не обнаружил разрыв: три заказа с сайта числятся оплаченными, а в базе их нет. Разработчик открывает журнал регистрации — за последний час запросов от сайта не зафиксировано ни одного, хотя сайт настаивает, что отправил их и получил в ответ код 200.

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

Почему отладчик здесь бессилен

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

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

Три способа проверить сервис — и почему первые два не годятся

До появления штатного инструмента тестирования разработчики использовали внешние программы для отправки HTTP-запросов и пытались вручную синхронизировать это с отладкой в Конфигураторе. На практике выходило вот что.

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

🧪 Как запустить тест из Конфигуратора

В дереве конфигурации откройте раздел HTTP-сервисы, выберите нужный сервис и вызовите команду «Тестировать» — она доступна по правому клику или через меню отладки. Откроется форма, где перед отправкой запроса указывают метод (GET, POST, PUT), URL-шаблон, тело запроса и заголовки — ровно то, что реально присылает сайт или мобильное приложение.

Что заполнять в форме теста

Метод и URL берут из кода модуля: у каждого метода HTTP-сервиса в 1С уже указаны HTTP-метод и шаблон адреса. Например, если сервис описан как POST /hs/orders/{clientID}/create, то {clientID} — параметр URL, который в форме теста подставляют реальным значением, а не оставляют как есть, иначе сервис ответит ошибкой ещё до того, как дойдёт до тела запроса. Само тело — это JSON или XML, который партнёр отправляет в реальности; если формат неизвестен, его можно скопировать из документации интеграции или из лога внешней системы. Перед нажатием кнопки «Выполнить» ставят точку останова в обработчике метода — точно так же, как при обычной отладке кода конфигурации.

Заголовки и авторизация — где тесты чаще всего расходятся с реальностью

HTTP-сервисы в 1С часто требуют Basic-авторизацию или заголовок с токеном партнёра — Конфигуратор не подставляет их автоматически, в отличие от браузера. Забытый заголовок Content-Type: application/json — классическая причина, по которой тест в HTTP Tester проходит, а реальный запрос от системы, которая присылает text/plain или другую кодировку, всё равно падает. Заголовки в тестовой форме заполняют вручную и сверяют с тем, что реально шлёт партнёр, а не с тем, что кажется логичным по умолчанию.

Как воспроизвести запрос конкретного партнёра

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

Результат: от догадок к десяти минутам

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

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

⚠️ Чего HTTP Tester не проверяет

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

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

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

Когда тестирование HTTP-сервисов стоит отдать подрядчику

Встроенный HTTP Tester решает задачу воспроизвести и поймать баг, но написать сам обработчик, разобраться в чужой интеграции или довести сервис до состояния, когда он не падает на пустом артикуле, — отдельная работа. В ukved.ru такие правки делаем как доработку 1С: пишем и переписываем HTTP-сервисы для обмена с сайтами, маркетплейсами и мобильными приложениями и тестируем их тем же встроенным инструментом на копии базы клиента, прежде чем выкатывать изменения на боевой сервер. Диагностика и правка конкретного инцидента — как случай с пустым артикулом — обычно укладывается в разовую заявку на сопровождение по ставке 3 800 ₽/час, и большинство подобных багов закрывают за два-три часа вместе с тестированием. То же самое касается нагрузочных сценариев, которые HTTP Tester не покрывает: если сервис исправно проходит один тест-кейс, но захлёбывается на пятидесяти запросах подряд, разбираемся с этим отдельно — как правило, дело в неоптимальном коде обработчика, а не в самом инструменте тестирования.

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

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

Что такое HTTP Tester в 1С и чем он отличается от Postman?

Это встроенная в Конфигуратор команда «Тестировать» у HTTP-сервиса: она отправляет тестовый запрос и сразу останавливает выполнение на точке останова в отладчике. Postman отправляет запрос, но не связан с отладчиком 1С — увидеть, что происходит внутри обработчика, через него нельзя.

Нужно ли обновлять платформу 1С, чтобы получить доступ к HTTP Tester?

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

Можно ли тестировать HTTP-сервис прямо на рабочей базе?

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

Как поймать точку останова, если запрос присылает конкретный маркетплейс?

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

Сколько стоит найти и исправить ошибку в HTTP-сервисе 1С?

Диагностика и правка конкретного бага обычно оформляются как разовая заявка на сопровождение по ставке 3 800 ₽/час; большинство подобных случаев закрывают за два-три часа вместе с тестированием исправления.