OneSniffer: заказ в магазине есть, в 1С нет. Как мы ловим HTTP без ЖР

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

Почему возникает слепая зона при HTTP-сбоях в 1С 🔍

Интернет-магазин отправляет заказы в 1С:Управление торговлей через HTTP-сервис. В понедельник менеджер звонит программисту: клиент оплатил заказ, а в базе его нет. Программист открывает журнал регистрации (ЖР) и находит строку с ошибкой и временем. Что именно прислал магазин, с какими заголовками и в какой кодировке, из неё не понять. Магазин уверен, что отправил всё правильно, в 1С виден только отказ, поэтому разговор сводится к «это у вас» и «нет, у вас».

Причина в устройстве журнала. ЖР записывает события платформы и то, что разработчик записал сам вызовом ЗаписьЖурналаРегистрации. Тел и заголовков HTTP-запросов в нём нет, пока кто-то не написал для них отдельное логирование. А писать его приходится в каждом месте, где есть вызов, и обычно уже после того, как ошибка случилась на рабочей базе.

Другие инструменты тоже подводят. Технологический журнал включается на сервере кластера, быстро разрастается и показывает вызовы платформы, но не готовый диалог с внешним сервисом. Wireshark видит HTTPS как шифрованный поток. Fiddler ставят на рабочий компьютер, а запрос уходит с сервера 1С.

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

Как исправить: поставить прокси между 1С и сервисом 🛠

Мы устали от этого цикла и написали OneSniffer. Это прокси: в настройках HTTP-соединения 1С вместо прямого адреса сервиса указан адрес сниффера, он пересылает запрос дальше и по пути сохраняет всё. Метод, адрес, заголовки, тело запроса, код ответа, тело ответа и время, которое сервис думал над ответом.

Как подключить к 1С

У объекта HTTPСоединение есть параметр прокси (ИнтернетПрокси). Мы задаём в нём адрес сниффера, и код обмена остаётся прежним: меняется одна настройка. Для HTTPS сниффер подставляет свой сертификат, поэтому на сервере 1С его нужно добавить в доверенные. Это ваш собственный трафик на вашем сервере, но сертификат мы ставим только на время отладки и убираем после.

Что находим чаще всего

Типичные причины, которые журнал регистрации не показывает:

• ✓В начале JSON лежит невидимый символ BOM, и сервис отвечает «невалидный JSON», хотя в отладчике строка выглядит нормально.
• ✓Content-Type уходит без указания кодировки, и кириллица в наименованиях превращается в вопросительные знаки.
• ✓Сервис отвечает редиректом 301 на https-адрес, в теле пусто, а код обмена ждёт JSON и падает на разборе.
• ✓Сервис возвращает код 200, но в теле лежит текст ошибки, и 1С считает обмен успешным.

Что видно в каждом способе

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

Вернёмся к заказу из понедельника. В сниффере видно, что магазин отправил позицию с пустым артикулом, 1С не нашла номенклатуру и ответила кодом 400 с текстом ошибки в теле. Магазин этот ответ не читал и считал заказ доставленным. Программист кладёт рядом оба сообщения, спор заканчивается, а магазин добавляет обработку кода 400. Так выглядит типичная развязка.

Что делать, если ошибка повторяется 🔁

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

1. ✓Оставьте сниффер включённым на несколько дней, а не на один тест. Плавающая ошибка появляется, когда ей удобно.
2. ✓Найдите пару: успешный и упавший запрос одной и той же операции. Сравните заголовки и тело построчно. Разницу ищите в полях: пустой артикул, кавычка в наименовании, слишком длинный комментарий.
3. ✓Если запросы одинаковые, а ответы разные, причина на стороне сервиса. Отправьте партнёру сырой запрос с временем из сниффера: по времени его техподдержка найдёт вызов в своих логах.
4. ✓Если сервис отвечает дольше, чем ждёт 1С, смотрите таймаут. Сниффер показывает, сколько сервис думал над каждым ответом, а таймаут задаётся в HTTP-соединении.
5. ✓Если сломанный запрос формирует ваш код, это задача для доработки 1С: правка формирования тела или обработки ответа.

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

Как предотвратить сбой обмена, а не разбирать его потом 🛡

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

• ✓Перед обновлением конфигурации прогоняйте обмены на тестовой копии через сниффер и сохраняйте эталонные запросы. После обновления сравнивайте.
• ✓Фиксируйте с партнёром письменно формат запроса, коды ошибок и допустимое время ответа. Когда обмен сломается, у вас будет документ, с которым сверять пойманный запрос.
• ✓Ограничьте срок хранения пойманных запросов. В них лежат ФИО, телефоны и адреса покупателей, а значит, на такие логи распространяется 152-ФЗ. Маскируйте токены и номера, доступ давайте только тем, кто разбирает обмен.
• ✓Встройте проверку ответа в сам обмен: код 200 с текстом ошибки в теле должен считаться ошибкой, а не успехом.

Сколько стоит разбор интеграции и как это устроено у нас 💬

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

Разбор идёт по ставке сопровождения 1С: 3800 руб/час, она же действует для услуг системного администратора. Сколько часов понадобится, зависит от интеграции, поэтому оценку мы называем после первых пойманных запросов, а не до них. Если причина в коде, исправление оформляется отдельной задачей.

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

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

Чем журнал регистрации 1С не подходит для отладки HTTP-запросов?

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

Можно ли поймать HTTPS-запросы 1С сниффером?

Да. Сниффер работает как прокси, а для HTTPS подставляет собственный сертификат, который добавляют в доверенные на сервере 1С. Без этого шага тело запроса остаётся зашифрованным. Сертификат ставят только на время отладки на том сервере, где идёт разбор, и после завершения убирают.

Нужно ли переписывать код интеграции, чтобы подключить сниффер?

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

Сколько стоит разбор HTTP-интеграции 1С?

Разбор идёт по ставке сопровождения 1С: 3800 руб/час, она же действует для услуг системного администратора. Сколько часов понадобится, зависит от интеграции. Оценку мы называем после первых пойманных запросов, когда видно, где ломается обмен: в коде, в типовой конфигурации или на стороне партнёра.

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

Тела запросов содержат ФИО, телефоны и адреса покупателей, а это персональные данные по 152-ФЗ. Ограничьте срок хранения логов, маскируйте токены и номера карт, откройте доступ только тем, кто разбирает обмен. После закрытия инцидента удаляйте записи, которые больше не нужны для разбора.