Диагностика обменов 1С: как искать причину сбоя без шаманства

Фраза “обмен не работает” почти никогда не означает одну конкретную проблему.

Под ней может скрываться что угодно: не выполнилось регламентное задание, документ не попал в отбор, закончился токен, изменился URL, внешний сервис вернул 500, корпоративный VPN оказался выключен, ответ пришёл, но данные не записались в 1С из-за проверки или несовпадения справочников.

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

Обычно всё начинается примерно одинаково:

“Посмотри, пожалуйста, обмен не работает. Ничего не выгрузилось.”

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

Да, часть проверок из этой статьи звучит очевидно. Период, отбор, статус, права, расписание, токен, URL — вроде бы скучные вещи. Но именно их чаще всего и пропускают, когда обмен уже упал, пользователь торопит, а в голове мысль: “сейчас быстро открою код и найду”.

Я чаще сталкивался с HTTP-обменами: сторонние сервисы, Jira, СБИС, Диадок, разные внутренние и внешние системы. В таких обменах много мест, где всё может сломаться. При этом пользователь видит только итог: “не выгрузилось”, “не загрузилось”, “ошибка”, “ничего не произошло”.

Самый плохой старт диагностики выглядит так:

“А давай просто ещё раз нажмём выполнить обмен. Вдруг пройдёт?”

Иногда действительно проходит. Но иногда после такого “вдруг” появляются дубли, повторные отправки документов, лишние записи в регистрах, повторные заявки во внешней системе и странные статусы, которые потом приходится разбирать дольше, чем исходную ошибку.

Поэтому диагностика обмена — это не шаманство с перезапуском. Это последовательная проверка:

данные в 1С → отборы → расписание → регламентное задание → запрос → транспорт → внешний сервис → ответ → запись результата → безопасный повтор.

Задача разработчика — не угадать причину с первого раза. Задача разработчика — быстро сузить зону поиска и понять, где именно сломался процесс.

Почему обмены сложнее обычной ошибки в форме

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

С обменами всё менее приятно.

Во-первых, обмен часто работает не руками пользователя, а по расписанию. Регламентное задание должно было выполниться ночью, утром кто-то заметил, что данных нет. Точного времени никто не помнит. В заявке написано: “сегодня не выгрузилось”. А “сегодня” для диагностики — это примерно как “где-то в базе”.

Во-вторых, обмен состоит из нескольких слоёв. В 1С должны быть подходящие данные. Они должны попасть в отбор. Должно выполниться регламентное задание. Должен сформироваться корректный запрос. Должен быть доступен URL. Должна пройти авторизация. Внешняя система должна принять запрос. Ответ должен быть в ожидаемом формате. Потом результат ещё надо правильно записать обратно в 1С.

В-третьих, ошибка может проявиться не там, где находится причина. Например, в 1С видим “данные не записались”, а первопричина — внешний сервис изменил формат ответа. Или видим HTTP 500, а причина не в том, что “там всё упало”, а в конкретном наборе данных, на котором обработчик не справился.

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

Интуиция полезна. Но лучше, когда есть следы.

 

Главная ошибка — начинать с повторного запуска

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

Представим простой сценарий. 1С отправила документ во внешний сервис. Внешний сервис документ принял, но в 1С при обработке ответа произошла ошибка: не записался статус, не сохранился внешний идентификатор, не прошло сопоставление справочника или упала запись регистра.

С точки зрения пользователя документ “не выгрузился”. С точки зрения внешней системы он уже принят.

Если в этот момент просто нажать “отправить ещё раз”, можно получить дубль. Потом начинается отдельный вид 1С-спорта: найти, какой объект правильный, какой лишний, почему статусы разные, где должен лежать внешний идентификатор и можно ли теперь безопасно отменить повторную запись.

В интеграциях опасны не только ошибки. Иногда опаснее успешный повтор, который создал дубли.

Перед повтором надо понять минимум три вещи:

• сформировался ли исходящий запрос;
• дошёл ли он до внешней стороны;
• приняла ли внешняя сторона объект, даже если 1С не смогла корректно записать результат.

Если ответов нет, повторять обмен надо осторожно. Особенно в боевой базе.

Сначала понять, что должно было произойти

До кода надо задать несколько скучных вопросов. Они не выглядят героически, зато часто экономят час-два работы.

Что именно должно было уйти или прийти? За какой период? По какой организации? Какой вид документа? В каком статусе? Кто запускал обмен? Это ручной запуск или регламентное задание? В какое время заметили ошибку? Есть ли текст ошибки? Был ли повтор?

Если пользователь прислал только “не работает”, это ещё не описание инцидента. Это начало переписки.

Нормальное описание должно отвечать хотя бы на такие вопросы:

• какой обмен проверяем;
• какой объект или документ участвует;
• что ожидали получить;
• что получили фактически;
• когда это произошло;
• есть ли текст ошибки или код HTTP;
• запускали ли обмен повторно;
• что уже проверили.

Без этого можно долго смотреть не туда. Разработчик полезет в обработчик HTTP-ответа, а через полчаса выяснится, что документ вообще не попадал в отбор. Или будет проверять токен, хотя регламентное задание не запускалось с ночи.

 

Мой обычный старт диагностики

Если приходит жалоба “обмен не работает”, я не начинаю сразу с отладки.

Обычно иду так:

1. Смотрю лог обмена, если он реализован.
2. Проверяю журнал регистрации примерно в момент ошибки.
3. Уточняю конкретный объект: документ, период, организацию, направление обмена.
4. Проверяю, есть ли в 1С данные, которые вообще должны попасть в обмен.
5. В тестовой базе пробую выполнить обмен на понятном примере.
6. Если ошибка воспроизводится на конкретных данных — тогда уже иду в отладку.

Почему не сразу отладка? Потому что без конкретного примера отладка превращается в прогулку по коду. Можно открыть общий модуль, посмотреть формирование запроса, пройти несколько процедур и всё равно не понять, почему у пользователя “ничего не выгрузилось”. А причина будет в том, что выбранный документ не подходил по статусу.

Тестовая база здесь очень помогает. В боевой базе обмен может создать документы, отправить данные наружу, изменить статусы или породить дубли. На тестовом примере можно спокойно посмотреть, формируется ли запрос, какие данные попадают в тело, какой URL используется, какой ответ возвращается и где именно падает обработка.

Если в тестовой базе на конкретном объекте ошибка повторилась — отлично. Появился предмет для отладки. Если не повторилась — тоже полезно. Значит, надо смотреть различия сред: настройки подключения, доступы, токен, VPN, права сервисной учётной записи, версию расширения или состояние данных в боевой базе.

 

Где искать следы обмена

Хороший обмен оставляет следы. Плохой обмен молча делает вид, что он обмен.

Идеально, когда в системе есть отдельный лог обмена. Не просто строка “ошибка обмена”, а нормальная техническая история:

• дата и время запуска;
• направление обмена;
• объект или набор объектов;
• этап выполнения;
• статус;
• код HTTP, если был запрос;
• текст ошибки;
• внешний идентификатор;
• признак повторной отправки;
• пользователь или сервисная учётная запись;
• регламентное задание, если обмен запускался по расписанию.

В реальной жизни так бывает не всегда. Иногда лог есть, но в нём только “Ошибка”. Иногда лог не включили. Иногда лог перетёрся. Иногда обмен писался как “быстрая временная доработка”, а потом внезапно стал важной частью процесса.

Если отдельного лога нет, смотрю всё, что может оставить след:

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

В журнале регистрации обычно ищу ошибки около времени запуска: по регламентному заданию, по пользователю, по HTTP-сервису, по общему модулю, по записи объекта. Иногда уже по журналу видно, что обмен даже не дошёл до отправки запроса. А иногда видно, что запрос был, ответ пришёл, но упали уже на записи результата.

Это важное различие. “Не выгрузилось” — слишком грубо. Для диагностики надо понять этап.

 

Что проверить на стороне 1С до кода

Перед тем как открывать модуль, стоит проверить скучные вещи: период, отбор, статус, права, расписание, настройки подключения.

На стороне 1С я смотрю не абстрактно “всё ли нормально”, а по конкретному сценарию обмена. Если отправляем документы — проверяем документы. Если загружаем статусы — проверяем соответствия и правила записи. Если выгружаем задачи во внешний сервис — проверяем, какие объекты должны попасть в запрос.

Типовые проверки:

• Период. Документ может не попасть в обмен просто потому, что дата не входит в выбранный период.
• Организация. Обмен может быть настроен только для определённых организаций.
• Вид документа. Не все документы участвуют в одном сценарии.
• Статус документа. В обмен часто уходят только утверждённые, подписанные, проведённые или готовые к отправке документы.
• Заполненность реквизитов. Один пустой реквизит может остановить отправку или запись результата.
• Признак выгрузки. Документ может считаться уже отправленным, хотя пользователь ожидает повторной отправки.
• Права. Сервисная учётная запись может не видеть объект или не иметь права на запись результата.
• Расписание. Регламентное задание могло не выполниться, быть отключено или завершиться с ошибкой.
• Настройки подключения. URL, токен, режим тест/бой, сертификат, прокси, VPN.
• Расширения и обновления. После обновления конфигурации или изменения расширения мог измениться обработчик, реквизит, роль или проверка записи.

Ситуация “выгрузилось не всё” часто оказывается не ошибкой, а результатом отбора. Например, выгружаются документы только в определённом статусе, только по одной организации, только за период, только с заполненным внешним идентификатором контрагента или только без признака “уже выгружен”.

Пользователь видит: “часть документов не ушла”. Разработчик должен понять: это сбой или обмен просто отработал по своим правилам.

 

Регламентное задание: обмен мог вообще не стартовать

Один из самых простых сценариев: обмен должен был выполниться по расписанию, но регламентное задание не выполнилось.

Причины бывают обычные:

• задание отключено;
• изменилось расписание;
• задание завершилось с ошибкой;
• сеанс завис;
• не хватило прав сервисной учётной записи;
• параллельно выполнялся другой тяжёлый процесс;
• после обновления изменился обработчик или общий модуль.

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

Я обычно смотрю историю выполнения задания, журнал регистрации, дату последней успешной синхронизации и внутренние статусы обмена. Если задание не запускалось, то проблема не в формировании JSON и не в разборе ответа. Сначала надо разбираться с расписанием, фоновыми заданиями, правами, ошибкой запуска или состоянием сервера.

Это скучная проверка. Но она часто быстрее, чем героическая отладка не того места.

 

HTTP-коды: не диагноз, но направление поиска

В HTTP-обменах коды ответа хорошо помогают сузить зону поиска. Они не дают готовый ответ, но подсказывают, куда смотреть.

401 обычно ведёт в сторону авторизации: логин, пароль, токен, срок действия, права учётной записи.

404 — в сторону URL, пути метода, маршрута HTTP-сервиса, версии API.

500 — в сторону серверной обработки. Но тут важно не делать слишком быстрый вывод. 500 не всегда означает “проблема только у внешней стороны”. Иногда 500 провоцирует конкретный запрос, конкретные данные, изменение формата или ошибка в обработчике на стороне 1С HTTP-сервиса.

Характерный пример: корректный путь HTTP-сервиса возвращает 500, неверный логин даёт 401, неверный путь даёт 404.

Это уже полезная диагностика. Она говорит:

• авторизация в целом отрабатывает, раз неверные учётные данные дают 401;
• маршрутизация в целом живая, раз неверный путь даёт 404;
• 500 возникает уже на корректном маршруте, то есть искать надо ближе к обработчику, инициализации модуля, данным, зависимостям, правам или коду, который выполняется после попадания в нужный путь.

Мы ещё не нашли причину, но уже перестали гадать между “не тот URL”, “не тот логин” и “вообще не опубликован сервис”. Зона поиска стала меньше.

Таблица: симптом и где искать

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

 

Симптом	Где искать в первую очередь	Что проверить
Ничего не выгрузилось	Расписание, регламентное задание, лог обмена, журнал регистрации	Запускался ли обмен, были ли подходящие данные, не было ли ошибки задания
Выгрузилась только часть документов	Отборы, период, организация, вид документа, статус	Попадают ли “пропавшие” документы под правила обмена
Ошибка 401	Авторизация	Логин, пароль, токен, срок действия токена, права сервисной учётной записи
Ошибка 404	URL и маршрут	Адрес сервиса, путь метода, версия API, маршрут HTTP-сервиса
Ошибка 500	Серверная обработка	Данные запроса, обработчик, инициализация модуля, изменение API, исключение на внешней стороне
Ответ пришёл, но данные не записались	Запись результата в 1С	Проверки записи, права, транзакция, сопоставление справочников, заполненность реквизитов
Создались дубли	Механизм повторной отправки и соответствия	Внешний идентификатор, идемпотентность, история отправки, проверка существующих объектов
В тестовой базе работает, в рабочей нет	Различия сред	Настройки подключения, токен, VPN, сертификаты, права, версии расширений, сетевой доступ

 

Внешняя сторона: URL, токен, формат ответа и доступ из нужной среды

Когда на стороне 1С всё выглядит нормально, надо смотреть наружу.

Внешняя сторона — это не только “работает сайт или нет”. Там тоже хватает мест, где можно споткнуться:

• правильный ли URL;
• не изменилась ли версия API;
• актуален ли токен;
• есть ли права у сервисной учётной записи;
• не нужен ли сертификат;
• доступен ли сервис именно из той среды, где выполняется обмен;
• не включились ли лимиты;
• не идут ли технические работы;
• не изменился ли формат ответа;
• не требуется ли корпоративный VPN.

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

Такие проблемы неприятны тем, что в одной среде всё работает, а в другой — нет. Разработчик проверяет код, сравнивает настройки, смотрит обработчики, а причина оказывается не в 1С, а в маршруте до внешнего сервиса.

Поэтому вопрос “откуда реально выполняется обмен” не формальность. Локальный компьютер разработчика, тестовая база, рабочий сервер 1С, сервер клиента — это могут быть разные сетевые условия.

 

Изменение API: в 1С ничего не трогали, но обмен сломался

Отдельная история — изменение API внешней системы.

Вчера метод возвращал один формат, сегодня добавили поле, убрали поле, поменяли тип, изменили обязательность параметра или стали иначе обрабатывать пустые значения. Например, раньше дата приходила одной строкой в привычном формате, а потом внешний сервис начал возвращать другой формат даты или вложенную структуру. В 1С код не менялся. Рука сама тянется открыть конфигуратор и искать, что мы сломали. А по факту изменилась внешняя сторона.

В таких случаях помогает не спорить, а сравнивать факты:

• какой запрос отправляли раньше;
• какой запрос отправляется сейчас;
• какой ответ приходил раньше;
• какой ответ приходит сейчас;
• не менялась ли документация API;
• не было ли уведомлений от внешней стороны;
• на каких данных ошибка воспроизводится.

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

 

Ответ пришёл, но в 1С ничего не записалось

Есть отдельный класс проблем: внешний сервис ответил успешно, но в 1С результат не появился.

Это уже не транспорт. Запрос ушёл, ответ пришёл, HTTP-код хороший, но дальше начинается внутренняя обработка 1С.

Что может пойти не так:

• не найдено соответствие внешнего идентификатора и объекта 1С;
• не найден контрагент, организация, договор, номенклатура или пользователь;
• не заполнен обязательный реквизит;
• не проходит проверка записи;
• не хватает прав у сервисной учётной записи;
• объект находится в статусе, где изменение запрещено;
• запись выполняется в транзакции и откатывается из-за ошибки ниже по цепочке;
• после обновления изменилась логика проверки или состав реквизитов.

Снаружи это выглядит просто: “данные не загрузились”. Но технически обмен мог пройти почти весь путь. Ошибка произошла на последнем участке — при записи результата в 1С.

Поэтому в логах полезно разделять этапы: запрос сформирован, запрос отправлен, ответ получен, ответ разобран, результат записан. Если в логе одна строка “ошибка обмена”, понять этап сложнее.

 

Таблица: что проверить до кода

Эта таблица нужна не для того, чтобы заменить отладку. Она нужна, чтобы не открывать отладчик раньше времени и не искать ошибку в коде, когда объект просто не должен был попадать в обмен.

 

Что проверить	Зачем
Период	Документы могут не попадать в обмен из-за даты
Отборы	Часть данных может быть исключена правилами обмена
Организация	Обмен может быть настроен не для всех организаций
Статус документа	В обмен часто уходят только документы в определённом состоянии
Заполненность реквизитов	Пустой обязательный реквизит может остановить отправку или запись
Признак выгрузки	Объект может считаться уже отправленным
Расписание регламентного задания	Обмен мог не стартовать
Настройки подключения	URL, режим тест/бой, токен, сертификат или прокси могут быть неверными
Доступность внешнего сервиса	Проблема может быть не в 1С, а в доступе до внешней стороны
Права сервисной учётной записи	Сервисная учётная запись может не видеть или не записывать данные
VPN или сетевой доступ	В среде клиента обмен может зависеть от корпоративной сети

 

Дубли: ошибка, которую лучше предотвратить заранее

При реализации обмена вопрос дублей надо отрабатывать сразу. Не после первой аварии, а в самой логике обмена.

Для этого обычно нужны:

• внешний идентификатор объекта;
• таблица или регистр соответствий;
• проверка перед созданием нового объекта;
• история отправки;
• статус обработки;
• понятное поведение при повторном запросе;
• логика безопасного повтора.

Хороший обмен должен понимать разницу между “создать новый объект” и “обновить уже созданный”. Если каждый повтор запроса создаёт новый объект, это не обмен, а генератор будущей ручной чистки.

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

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

В реальной практике дубли часто появляются не потому, что кто-то специально написал плохой код. Чаще не учли все сценарии: ошибка после отправки, таймаут, повторный запуск пользователем, изменение статуса, частичная запись результата, сбой на внешней стороне.

После первого такого случая начинаешь спокойнее относиться к фразе “да там просто отправить документ по API”. В интеграциях “просто отправить” — это только половина задачи. Вторая половина — понять, что делать, если что-то пошло не так.

Безопасный повтор обмена

Перед повтором обмена надо ответить на несколько вопросов.

1. Есть ли внешний идентификатор у объекта?
2. Есть ли запись в истории отправки?
3. Был ли сформирован запрос?
4. Получала ли внешняя сторона этот запрос?
5. Есть ли во внешней системе объект, который соответствует нашему документу?
6. Что произойдёт при повторе: создание, обновление, пропуск или ошибка?
7. Можно ли повторить в тестовой среде?

Иногда повторять можно сразу. Например, ошибка возникла до отправки: запрос не сформировался, внешнего идентификатора нет, записи об отправке нет, внешняя сторона точно ничего не получила.

Иногда повторять нельзя без проверки. Например, был таймаут после отправки запроса. В 1С кажется, что обмен завершился ошибкой. Но таймаут не доказывает, что внешняя сторона ничего не получила. Она могла принять документ, обработать его, но не успеть вернуть ответ.

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

Правило простое: если не знаешь, приняла ли внешняя сторона запрос, не делай вид, что она точно не приняла.

 

Чек-лист первичной диагностики обмена

• Зафиксировать точное время ошибки.
• Понять, какой обмен проверяем.
• Понять, какой объект должен был уйти или прийти.
• Проверить период.
• Проверить отборы.
• Проверить статус объекта.
• Проверить заполненность ключевых реквизитов.
• Проверить регламентное задание.
• Открыть лог обмена.
• Посмотреть журнал регистрации.
• Проверить код и текст HTTP-ответа.
• Сохранить тело ошибки или безопасный фрагмент ответа.
• Понять, был ли повтор.
• Проверить риск дублей.
• Проверить URL, токен и формат ответа.
• Проверить доступность внешнего сервиса из нужной среды.
• Определить владельца следующего шага: 1С, внешняя система, администратор, сеть, пользователь.

Чек-лист не делает диагностику волшебной, но хотя бы не даёт бегать по базе кругами. Вместо “посмотрю где-нибудь” появляется маршрут.

 

Как описывать инцидент по обмену

Хорошее описание инцидента экономит время всем: разработчику, сопровождению, администратору, внешней стороне и пользователю.

Плохое описание:

“Не работает обмен. Посмотрите.”

Нормальное описание:

“Обмен с внешним сервисом по документу за 18.06.2026. Ожидали отправку документа, фактически статус не изменился. Ошибка появилась примерно в 10:35. В логе обмена HTTP 401. Повторно не запускали. Проверили период и статус документа. Скриншот и текст ошибки приложены.”

Разница огромная. В первом случае разработчик начинает добывать факты. Во втором — уже можно диагностировать.

 

Шаблон описания инцидента

 

Поле	Что указать
Какой обмен	Название обмена или направление: выгрузка, загрузка, синхронизация статусов
Период	За какой период ожидались данные
Объект или документ	Номер, дата, тип объекта, безопасный идентификатор без лишних персональных данных
Что ожидали	Какой результат должен был быть
Что получили	Что произошло фактически
Время ошибки	Точное или примерное время
Пользователь или сервисная учётная запись	Кто запускал обмен или от чьего имени он выполнялся
Текст ошибки	Полный текст без токенов, URL и персональных данных
HTTP-код	401, 404, 500 или другой код, если есть
Был ли повтор	Запускали ли обмен повторно и сколько раз
Где смотрели	Лог обмена, журнал регистрации, регламентное задание, внешняя система
Что уже проверили	Период, отбор, статус, права, URL, токен, доступность сервиса
Вложения	Скриншот, лог, тело ответа, идентификатор документа, безопасный фрагмент запроса

 

 

Логи: не роскошь, а нормальный инструмент сопровождения

Все проблемы обменов не решаются логированием. Если логировать всё подряд, обмен лучше не станет. Но без логов многие проблемы превращаются в гадание.

Лог не обязан хранить всё подряд. Более того, хранить всё подряд опасно: токены, пароли, персональные данные, внутренние URL, полные тела документов и лишние реквизиты лучше не складывать в открытые журналы.

Но лог должен помогать ответить на базовые вопросы:

• когда обмен стартовал;
• кто или что его запустило;
• какие объекты участвовали;
• какой этап выполнялся;
• какой статус получен;
• какой HTTP-код вернулся;
• какая ошибка возникла;
• есть ли внешний идентификатор;
• можно ли безопасно повторить операцию.

Я бы разделял технический лог и пользовательский статус. Пользователю не нужен полный стек исключения и JSON-ответ на несколько экранов. А разработчику не хватает фразы “ошибка обмена”.

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

 

Когда всё-таки идти в отладку

Отладка нужна. Просто не всегда она должна быть первым шагом.

Я иду в отладку, когда уже есть конкретный воспроизводимый пример: документ, период, настройки, ожидаемый результат, фактическая ошибка. Лучше — в тестовой базе, чтобы не бояться последствий.

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

Хороший вопрос перед отладкой:

“На каком конкретном объекте я сейчас воспроизвожу проблему?”

Если ответа нет, сначала надо собрать факты.

 

Кейс 1. API изменилось, а в 1С никто ничего не менял

Типовой сценарий: обмен работал, потом внезапно перестал. В 1С релиза не было, разработчик код не менял, настройки вроде те же.

Первое желание — искать ошибку у себя. Но если обмен завязан на внешнее API, надо проверять и внешнюю сторону.

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

Что помогает:

• сравнить старый и новый ответ;
• проверить документацию API;
• посмотреть уведомления внешнего сервиса;
• проверить, не поменялась ли обязательность полей;
• проверить, не изменился ли формат даты, статуса или идентификатора;
• воспроизвести запрос на тестовых данных.

В таких случаях особенно видно, зачем нужны сохранённые примеры запросов и ответов. Без них приходится ловить проблему заново.

 

Кейс 2. Не учли сценарий — получили дубли

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

И внезапно создаются дубли.

Причина обычно не в одной строке кода, а в том, что при реализации не до конца продумали повторяемость операции. Что будет, если запрос отправился, а ответ не записался? Что будет, если пользователь нажмёт повтор? Что будет, если внешний сервис уже принял документ, но 1С об этом не знает?

Если в регистре соответствий нет внешнего идентификатора, повторная отправка для кода может выглядеть как новая операция. А для внешней системы — как второй такой же документ.

Вот почему при обменах важно заранее продумывать статусы, историю отправки, внешние идентификаторы и поведение при повторе. Не ради красоты архитектуры, а чтобы потом не чистить руками то, что можно было не создать.

 

Кейс 3. Без VPN обмен не добирается до данных

Бывает, что обмен развёрнут в среде клиента, а доступ к нужному ресурсу возможен только при включенном корпоративном VPN.

На локальной машине разработчика всё может работать. В одной среде тоже. А в другой обмен падает или не получает данные. Код тот же, настройки похожие, логика не менялась.

Сначала это может выглядеть как ошибка запроса или авторизации. Проверяешь URL, токен, обработчик, формат ответа. А потом выясняется, что проверяли с компьютера разработчика, а реально обмен выполняется с сервера 1С. И именно сервер без VPN до нужного ресурса не достучится.

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

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

 

Рабочая последовательность диагностики

Если собрать маршрут в одну последовательность, получится так:

1. Понять, что должно было произойти.
2. Зафиксировать объект, период и время.
3. Проверить, запускался ли обмен.
4. Посмотреть лог обмена.
5. Посмотреть журнал регистрации.
6. Проверить данные в 1С.
7. Проверить отборы, статусы и права.
8. Проверить настройки подключения.
9. Проверить URL, токен, VPN, сертификаты.
10. Проверить HTTP-код и тело ответа.
11. Проверить, записался ли результат в 1С.
12. Оценить риск дублей перед повтором.
13. Воспроизвести на тестовых данных.
14. После сужения зоны поиска идти в отладку.

Что не надо делать

• Не начинать с повторного запуска, если не понятно, ушёл ли предыдущий запрос.
• Не закрывать окно с ошибкой, не сохранив текст.
• Не диагностировать обмен без объекта, периода и времени.
• Не считать, что HTTP 500 всегда означает “проблема только у внешней стороны”.
• Не считать, что если в 1С ошибка, то внешний сервис точно ничего не получил.
• Не хранить в логах токены, пароли, персональные данные и внутренние URL без необходимости.
• Не делать вид, что лог “ошибка обмена” достаточно информативен.
• Не забывать про различия сред: тест, бой, сервер 1С, локальный компьютер, VPN.

 

Финальный вывод

Диагностика обмена — это не поиск волшебной строки в коде. Это последовательное сужение зоны поиска.

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

Чем лучше зафиксированы следы обмена, тем меньше времени уходит на “посмотреть, почему ничего не работает”.

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

Обмен — это цепочка. Задача диагностики — понять, на каком звене она оборвалась.