Есть фраза, после которой у разработчика 1С обычно начинается маленькое внутреннее расследование:
“Обмен не работает”.
Что именно не работает — пока неизвестно.
Данные не отправились? Не загрузились? Регламентное задание не запустилось? Внешняя система вернула ошибку? JSON изменился? XML не прошел проверку? Пользователь нажал не ту кнопку? Контрагент не найден? Документ не записался? Повторная обработка создала дубль? Авторизация протухла? Сервер был недоступен? Или всё обработалось, но пользователь смотрит не туда?
На практике “обмен не работает” — это не диагноз. Это только начало диагностики.
В 1С обменами часто называют всё подряд:
- регламентную загрузку файлов из каталога;
- HTTP/API-интеграцию с внешней системой;
- обмен через XML или JSON;
- загрузку документов из личного кабинета, сайта, CRM, склада или внутреннего сервиса;
- синхронизацию между информационными базами;
- обмен через EnterpriseData;
- выгрузку отчетов и статусов;
- передачу заявок, документов, номенклатуры, контрагентов или остатков.
Механизмы разные, но боль часто одна и та же: когда что-то ломается, команда начинает искать причину почти вслепую.
В этой статье разберем, как диагностировать обмены 1С без шаманства: какие уровни проверять, что логировать, какие статусы хранить, как отличать техническую ошибку от бизнес-ошибки и как сделать так, чтобы следующий сбой разбирался быстрее, чем предыдущий.
Почему обмены в 1С сложно диагностировать
Обмен — это цепочка. И если конечный результат не получился, ошибка могла произойти почти в любом звене.
Например, пользователь говорит:
“Документ не загрузился в 1С”.
Но за этой фразой может скрываться много разных ситуаций:
- регламентное задание не запускалось;
- файл не появился в каталоге;
- HTTP-сервис вернул ошибку;
- ответ пришел, но не в том формате;
- данные не прошли бизнес-проверку;
- контрагент не найден;
- номенклатура не сопоставлена;
- документ уже был загружен ранее;
- запись в 1С завершилась ошибкой;
- документ записался, но не попал в нужный статус;
- пользователь смотрит другой период или другую организацию.
Если в обмене нет нормальной диагностики, разработчик вынужден идти по цепочке вручную:
- открыть регламентные задания;
- посмотреть журнал регистрации;
- найти временные файлы;
- проверить запросы;
- посмотреть ответ внешней системы;
- проверить логи;
- разобрать JSON или XML;
- воспроизвести ситуацию на тесте;
- спросить пользователя, что он делал;
- вспомнить, кто вообще писал этот обмен.
Иногда это занимает 15 минут. Иногда — несколько часов. А иногда всё упирается в человека, который “помнит, как оно там устроено”.
Хорошая диагностика обмена нужна не для того, чтобы ошибок никогда не было. Она нужна, чтобы ошибка быстро превращалась в понятную причину и понятное действие.
Плохой обмен и хороший обмен: в чем разница
Плохой обмен может работать годами. До первой нестандартной ситуации.
Пока данные приходят в ожидаемом формате, внешний сервис доступен, пользователи не ошибаются, сеть не моргает, а справочники заполнены правильно — всё выглядит нормально.
Но как только появляется отклонение, выясняется:
- нет статусов обработки;
- нет понятного журнала обмена;
- ошибки пишутся общим текстом;
- повторная загрузка может создать дубли;
- непонятно, что уже обработано, а что нет;
- пользователь видит техническую ошибку вместо нормального сообщения;
- разработчик не может быстро воспроизвести запрос;
- никто не знает, какие данные пришли на вход.
Хороший обмен отличается не тем, что он никогда не падает.
Хороший обмен отличается тем, что по нему можно быстро ответить на вопросы:
- когда обмен запускался;
- что он пытался обработать;
- какой запрос отправил;
- какой ответ получил;
- какие данные распознал;
- на каком этапе возникла ошибка;
- можно ли повторить обработку;
- есть ли риск дублей;
- что должен сделать пользователь;
- что должен сделать разработчик.
То есть хороший обмен — это не только код загрузки или выгрузки. Это еще и диагностика, статусы, логирование, повторяемость и понятные правила обработки ошибок.
Семь уровней диагностики обмена
Когда обмен сломался, удобно проверять его не “как получится”, а по уровням.
Я обычно смотрю на обмен как на цепочку из семи слоев:
- расписание и запуск;
- транспорт;
- авторизация и доступ;
- формат данных;
- бизнес-валидация;
- запись или изменение данных в 1С;
- повторная обработка и итоговый статус.
Если эти уровни явно выделены, диагностика становится намного проще.
Уровень 1. Расписание и запуск
Первый вопрос:
“Обмен вообще запускался?”
Это звучит банально, но часто ошибка находится уже здесь.
Типовые проблемы:
- регламентное задание отключено;
- задание не запускалось после обновления;
- расписание настроено не на то время;
- на копии базы задание случайно активно;
- на рабочей базе задание выключили для диагностики и забыли включить;
- задание завершилось раньше из-за ошибки в начале процедуры;
- задание выполняется дольше, чем период его запуска;
- одновременно запускаются несколько обработчиков одного и того же обмена.
Что стоит логировать:
- дату и время старта;
- дату и время окончания;
- длительность;
- пользователя или контекст запуска;
- параметры запуска;
- количество найденных объектов для обработки;
- общий итог: успешно, частично, ошибка.
Если в журнале обмена нет даже записи о старте, искать ошибку в JSON или правилах сопоставления рано.
Уровень 2. Транспорт
Второй вопрос:
“Мы смогли дойти до источника или получателя данных?”
Для HTTP/API это может быть ошибка соединения, таймаут, недоступность сервера, неверный адрес, ошибка SSL, прокси или блокировка сети.
Для файлового обмена — отсутствие файла, права на каталог, неверный путь, блокировка файла, кодировка или неожиданный архив.
Для обмена между базами — недоступность узла, ошибка подключения, проблема с публикацией, блокировка фоновых процессов.
Что стоит фиксировать:
- адрес ресурса или путь к каталогу, лучше без секретных параметров;
- метод запроса, если это HTTP;
- код ответа;
- краткий текст ошибки;
- таймаут;
- количество попыток;
- время выполнения запроса;
- признак повторяемости ошибки.
Важно: в лог не нужно писать пароли, токены, полные секретные ключи и чувствительные заголовки. Диагностика не должна превращаться в утечку.
Уровень 3. Авторизация и доступ
Третий вопрос:
“Нам разрешили выполнить это действие?”
Ошибки авторизации часто маскируются под общие ошибки обмена.
Например:
- истек срок действия токена;
- изменился пароль сервисного пользователя;
- пользователю не хватает прав;
- сертификат недействителен;
- сессия завершилась;
- доступ ограничен по IP;
- у учетной записи изменили роль;
- внешняя система возвращает “доступ запрещен”, но обработка показывает пользователю “ошибка загрузки”.
Хороший обмен должен отличать:
- ошибку соединения;
- ошибку авторизации;
- ошибку недостаточных прав;
- ошибку бизнес-валидации;
- внутреннюю ошибку записи в 1С.
Для пользователя это разные ситуации. Для разработчика — тем более.
Уровень 4. Формат данных
Четвертый вопрос:
“Мы получили данные в том формате, который ожидали?”
Очень частая проблема: транспорт успешен, ответ пришел, но структура изменилась.
Например:
- поле стало называться иначе;
- число пришло строкой;
- дата пришла в другом формате;
- массив стал объектом;
- обязательное поле отсутствует;
- в XML изменилось пространство имен;
- в JSON появилась вложенность, которую код не ожидал;
- пустой ответ обработался как успешный.
В такой ситуации плохо писать:
“Ошибка обмена”.
Лучше:
“Получен ответ, но не найдено обязательное поле НомерДокумента. Этап: разбор JSON. Идентификатор пакета: 1457”.
Это уже диагностическое сообщение.
Уровень 5. Бизнес-валидация
Пятый вопрос:
“Данные технически прочитались, но можно ли их обработать по правилам нашей базы?”
Тут начинается самая частая зона конфликтов между “технически всё пришло” и “в 1С документ не создался”.
Примеры бизнес-ошибок:
- не найден контрагент;
- не найдена организация;
- не сопоставлена номенклатура;
- не указан договор;
- валюта не поддерживается;
- дата документа вне допустимого периода;
- документ уже существует;
- номер не проходит правила заполнения;
- у пользователя нет прав на запись;
- статус документа не позволяет изменение;
- не заполнены обязательные реквизиты.
Важно отделять бизнес-ошибки от технических.
Техническая ошибка требует разработчика или администратора.
Бизнес-ошибка часто требует пользователя, аналитика или настройки сопоставления.
Если всё складывать в один общий лог “ошибка загрузки”, сопровождение будет каждый раз разбирать одно и то же заново.
Уровень 6. Запись данных в 1С
Шестой вопрос:
“Данные прошли проверки, но смогли ли мы записать результат в 1С?”
На этом уровне могут всплывать:
- ошибки записи объекта;
- ошибки проведения;
- блокировки;
- нарушение уникальности;
- ошибки подписок на события;
- ошибки расширений;
- недостаточные права;
- неожиданные проверки типовой конфигурации;
- ошибки при записи движений;
- ошибки фоновых заданий.
Для диагностики полезно хранить:
- какой объект создавался или изменялся;
- ключ внешнего объекта;
- ссылку на созданный объект, если запись успешна;
- текст ошибки записи;
- этап записи: создание, заполнение, запись, проведение, постобработка;
- признак возможности повторной обработки.
Особенно важно хранить внешний идентификатор, по которому можно понять: этот пакет уже был обработан или нет.
Уровень 7. Повторная обработка и итоговый статус
Седьмой вопрос:
“Что будет, если запустить обмен повторно?”
Это один из самых важных вопросов для надежности.
Если обмен не идемпотентен, повторный запуск может:
- создать дубль документа;
- повторно отправить данные;
- перезаписать ручные изменения;
- создать лишние движения;
- сломать статус;
- сбить связь с исходным объектом.
Поэтому у обмена должны быть статусы и ключи повторной обработки.
Минимальные статусы:
| Статус | Что означает | Что делать |
|---|---|---|
| Новый | Данные получены или подготовлены, но еще не обработаны | Можно запускать обработку |
| В обработке | Пакет сейчас обрабатывается | Не запускать второй раз параллельно |
| Обработан | Данные успешно обработаны | Повторно не обрабатывать без причины |
| Ошибка | Возникла ошибка, требуется разбор | Показать причину и рекомендацию |
| Требует настройки | Технически данные прочитаны, но не хватает сопоставления или реквизитов | Передать пользователю или аналитику |
| Повторить | Ошибка временная, возможна повторная попытка | Запустить повторно по регламенту или вручную |
| Пропущен | Пакет не должен обрабатываться по правилам отбора | Сохранить причину пропуска |
Если статусов нет, обмен превращается в черный ящик: что-то где-то произошло, но непонятно, можно ли повторять и чем это закончится.
Что обязательно логировать в обмене
Хороший журнал обмена не обязан быть сложным.
Но он должен отвечать на базовые вопросы.
| Поле | Зачем нужно |
|---|---|
| Дата и время | Понять, когда произошло событие |
| Направление | Входящий или исходящий поток |
| Источник / получатель | Понять, с какой системой идет обмен |
| Идентификатор пакета | Связать событие с внешним объектом |
| Этап | Запуск, запрос, разбор, проверка, запись, завершение |
| Статус | Успешно, ошибка, предупреждение, пропущено |
| Текст ошибки | Краткое понятное описание |
| Технические детали | Код ответа, фрагмент ответа, стек, имя метода |
| Рекомендация | Что делать дальше |
| Ссылка на объект 1С | Что было создано или изменено |
Отдельно стоит хранить не только ошибки, но и успешные итоги:
- сколько объектов найдено;
- сколько обработано;
- сколько создано;
- сколько обновлено;
- сколько пропущено;
- сколько завершилось ошибкой.
Иначе при вопросе “а обмен вчера работал?” придется снова идти в код, регламентные задания и журнал регистрации.
Техническая ошибка и бизнес-ошибка — это разные вещи
Одна из частых проблем в обменах — все ошибки показываются одинаково.
Например:
“Ошибка загрузки данных”.
Но внутри могут быть совершенно разные причины.
| Тип ошибки | Пример | Кто обычно решает |
|---|---|---|
| Транспортная | Сервер недоступен, таймаут, ошибка соединения | Администратор / разработчик |
| Авторизация | Неверный токен, нет прав, истекла сессия | Администратор / владелец доступа |
| Формат | Не найдено поле, неверный тип данных, изменился JSON/XML | Разработчик / интегратор |
| Бизнес-валидация | Не найден контрагент, договор, номенклатура или организация | Пользователь / аналитик / поддержка |
| Запись в 1С | Ошибка записи, проведения, блокировки, прав | Разработчик / сопровождение |
| Дубли | Объект уже загружен или повторная обработка создала конфликт | Разработчик / аналитик |
Если система сразу классифицирует ошибку, становится понятнее, кому ее передавать.
Это снижает лишние переадресации:
- разработчик не тратит время на настройку справочника;
- пользователь не получает технический стек ошибки;
- аналитик видит, какие сопоставления надо заполнить;
- администратор понимает, где проблема доступа или сети.
Что показывать пользователю
Пользователю не нужен весь технический лог.
Но ему нужно понять:
- обмен выполнился или нет;
- сколько объектов обработано;
- какие строки требуют внимания;
- что можно исправить самостоятельно;
- когда нужно обратиться в поддержку;
- какой идентификатор ошибки передать разработчику.
Плохое сообщение:
“Ошибка при вызове метода контекста”.
Лучше:
“Документ не загружен: не найден контрагент с ИНН ******1234. Проверьте сопоставление контрагента. Код ошибки обмена: EX-2026-000145”.
Плохое сообщение:
“Ошибка HTTP 500”.
Лучше:
“Внешняя система временно вернула ошибку. Повторите загрузку позже или передайте код события EX-2026-000146 в поддержку”.
Техническая детализация должна оставаться в журнале. Пользовательский текст должен помогать действовать.
Что нужно разработчику для нормальной диагностики
Разработчику, наоборот, нужны детали.
Минимальный диагностический набор:
- идентификатор события обмена;
- этап, на котором произошла ошибка;
- метод или процедура;
- параметры запуска без секретов;
- код ответа внешней системы;
- фрагмент входящих данных, если это безопасно;
- ссылка на объект 1С;
- текст исключения;
- время выполнения;
- признак повторной попытки;
- версия обработки или конфигурации.
Хороший подход — разделять лог на два уровня:
- пользовательский журнал — короткие понятные статусы и рекомендации;
- технический журнал — детали для разработчика и сопровождения.
Тогда пользователь не пугается техническими ошибками, а разработчик не остается без информации.
Идемпотентность: страшное слово для простой идеи
Идемпотентность в обменах — это способность повторить операцию без лишних побочных эффектов.
Проще:
Если обмен запустить второй раз, он не должен создать дубль и испортить уже обработанные данные.
Для 1С это особенно важно.
Например, обмен загружает документы. На середине обработки произошла ошибка. Пользователь нажал “Повторить”. Что будет?
- Создадутся дубли документов?
- Старый документ обновится?
- Система поймет, что часть пакета уже обработана?
- Будет пропущена уже загруженная строка?
- Появится понятный статус?
Чтобы повторная обработка была безопасной, нужны:
- внешний идентификатор объекта;
- хранение связи “внешний объект — объект 1С”;
- проверка дублей перед созданием;
- статусы обработки;
- лог попыток;
- понятное правило: обновлять, пропускать или создавать новую версию.
Без этого повторная обработка становится лотереей.
Чек-лист диагностики: что проверить при ошибке обмена
Когда обмен упал, можно использовать простой чек-лист.
| Шаг | Вопрос | Что смотреть |
|---|---|---|
| 1 | Обмен запускался? | Регламентное задание, журнал запуска, время последнего старта |
| 2 | Источник данных доступен? | Каталог, HTTP-ответ, соединение, таймаут, код ответа |
| 3 | Доступ корректный? | Авторизация, права, сессия, сертификат, сервисный пользователь |
| 4 | Данные пришли? | Размер ответа, количество объектов, наличие файла или пакета |
| 5 | Формат ожидаемый? | JSON/XML, обязательные поля, типы данных, кодировка |
| 6 | Бизнес-проверки пройдены? | Контрагенты, договоры, номенклатура, организация, период |
| 7 | Запись в 1С прошла? | Ошибки записи, проведения, блокировки, права |
| 8 | Повтор безопасен? | Внешний идентификатор, дубли, статус обработки |
| 9 | Пользователь понимает, что делать? | Текст ошибки, рекомендация, код события |
| 10 | Нужно ли улучшить обмен? | Повторяемость ошибки, недостающий лог, новый пункт чек-листа |
Такой чек-лист помогает не прыгать сразу в код. Сначала нужно понять уровень проблемы.
Как оформить журнал обмена в 1С
В идеале для серьезного обмена нужен отдельный регистр или служебный объект учета событий.
Но даже если делать простой MVP, полезно разделить данные на несколько сущностей.
1. Сессия обмена
Это один запуск обмена.
Поля:
- дата начала;
- дата окончания;
- направление;
- тип обмена;
- статус;
- количество найдено;
- количество обработано;
- количество ошибок;
- длительность;
- пользователь или регламентное задание;
- общий комментарий.
2. Пакет или объект обмена
Это конкретный внешний объект: документ, строка, файл, сообщение, заявка, пакет.
Поля:
- внешний идентификатор;
- тип объекта;
- номер / дата, если есть;
- статус обработки;
- ссылка на объект 1С;
- текст ошибки;
- рекомендация;
- количество попыток;
- дата последней попытки.
3. Техническое событие
Это детальный лог.
Поля:
- время;
- этап;
- уровень: информация, предупреждение, ошибка;
- метод;
- код ответа;
- технические детали;
- идентификатор связанного пакета;
- фрагмент данных, если можно хранить безопасно.
Не в каждом обмене нужен такой полный учет. Но сама логика полезна: сессия, объект, событие.
Если всё писать одной строкой в общий лог, анализ быстро станет неудобным.
Какие ошибки нельзя просто “проглотить”
В обменах есть опасная привычка:
“Если ошибка не критичная, просто пропустим”.
Иногда это оправдано. Но есть ошибки, которые нельзя молча скрывать.
- не удалось авторизоваться;
- получен неожиданный формат данных;
- не найден обязательный ключевой реквизит;
- создание документа завершилось частично;
- повторная обработка может создать дубль;
- не удалось записать связь с внешним идентификатором;
- ошибка возникла в середине транзакции;
- непонятно, обработан объект или нет;
- ошибка повторяется несколько запусков подряд.
Такие ситуации должны попадать в отдельный список внимания.
Иначе обмен формально “работает”, но внутри копит скрытые проблемы.
Типовые анти-паттерны обменов
Анти-паттерн 1. Один общий текст ошибки
Все проблемы показываются как “ошибка обмена”.
Итог: каждый раз разработчик начинает расследование с нуля.
Анти-паттерн 2. Нет внешнего идентификатора
Если не хранить связь с внешним объектом, сложно защищаться от дублей и безопасно повторять обработку.
Анти-паттерн 3. Лог только в сообщениях пользователю
Пользователь закрыл форму — диагностическая информация исчезла.
Для серьезного обмена нужен сохраняемый журнал.
Анти-паттерн 4. Повторная обработка без правил
Кнопка “Повторить” есть, но никто точно не знает, что произойдет: обновление, дубль, пропуск или ошибка.
Анти-паттерн 5. Технические секреты в логах
В лог пишутся токены, пароли, полные заголовки авторизации, персональные данные или лишние фрагменты ответа.
Диагностика должна помогать сопровождению, а не создавать новую проблему безопасности.
Анти-паттерн 6. Обмен знает только один разработчик
Код работает, пока доступен автор.
Но при ошибке, отпуске, увольнении или передаче проекта выясняется, что документации нет, статусов нет, сценариев проверки нет.
Минимальный стандарт обмена для команды
Чтобы обмены не превращались в набор уникальных загадок, полезно договориться о минимальном стандарте.
Например:
- У каждого обмена есть владелец.
- У каждого обмена есть краткое описание назначения.
- Известно расписание или точка ручного запуска.
- Есть журнал запусков.
- Есть статусы обработки объектов.
- Есть внешний идентификатор для защиты от дублей.
- Ошибки разделяются на технические и бизнес-ошибки.
- Пользователь видит понятную рекомендацию.
- Технические детали доступны разработчику.
- Секреты и чувствительные данные не пишутся в лог открытым текстом.
- Есть сценарий проверки после релиза.
- Есть правило повторной обработки.
Это не бюрократия. Это минимальная страховка.
Команда может писать разные обмены по-разному. Но диагностический каркас должен быть похожим. Тогда сопровождать систему проще.
Как внедрить диагностику в уже существующий обмен
Часто обмен уже написан. Он работает, но плохо диагностируется.
Не обязательно переписывать всё сразу.
Можно двигаться маленькими шагами.
Шаг 1. Добавить журнал запусков
Сначала фиксируем сам факт запуска: старт, окончание, статус, длительность, общий итог.
Шаг 2. Добавить этапы
Разделяем обработку на этапы:
- подготовка;
- получение данных;
- разбор формата;
- валидация;
- запись;
- завершение.
Ошибка должна быть привязана к этапу.
Шаг 3. Добавить внешние идентификаторы
Если обмен работает с внешними объектами, нужно хранить ключ связи.
Это основа защиты от дублей.
Шаг 4. Разделить ошибки по типам
Хотя бы на три группы:
- техническая ошибка;
- ошибка данных;
- ошибка настройки или сопоставления.
Шаг 5. Добавить пользовательскую рекомендацию
Пользователь должен понимать, что делать:
- проверить справочник;
- заполнить сопоставление;
- повторить позже;
- передать код события в поддержку;
- обратиться к ответственному.
Шаг 6. Добавить отчет по ошибкам
Не заставляйте сопровождение искать ошибки по регистрам и журналам вручную.
Нужна форма или отчет:
- только ошибки;
- только повторяющиеся;
- только требующие пользователя;
- только технические;
- по периоду;
- по источнику;
- по типу объекта.
Пример нормального разбора инцидента
Допустим, пользователь сообщил:
“Вчера не загрузились документы”.
Без диагностики разработчик идет в код и начинает искать вручную.
С диагностикой порядок другой:
- Открываем журнал обмена.
- Видим, что регламентное задание запускалось в 02:00.
- Сессия завершилась со статусом “частично”.
- Из 120 объектов обработано 117, 3 — с ошибкой.
- Ошибки относятся к типу “не найдено сопоставление”.
- Видим конкретные внешние идентификаторы и значения.
- Пользователю даем список, что надо сопоставить.
- После настройки запускаем повторную обработку только ошибочных объектов.
- Статус становится “обработан”.
- В чек-лист добавляем проверку нового типа сопоставления.
Это уже не слепой поиск.
Это нормальная эксплуатация обмена.
Что должно быть в техническом паспорте обмена
Для критичных обменов полезно иметь короткий техпаспорт.
Не документ на 50 страниц, а одну-две страницы с главной информацией.
| Раздел | Что указать |
|---|---|
| Назначение | Какие данные и зачем передаются |
| Направление | Входящий, исходящий, двусторонний |
| Запуск | Регламентно, вручную, по событию |
| Источник / получатель | Внешняя система, каталог, база, сервис |
| Формат | JSON, XML, файл, EnterpriseData, другое |
| Ключи связи | Внешние идентификаторы, правила поиска дублей |
| Статусы | Какие состояния есть у объекта обмена |
| Ошибки | Основные типы ошибок и кто их решает |
| Повторная обработка | Можно ли повторять и по каким правилам |
| Проверка после релиза | Минимальный сценарий smoke-проверки |
Такой техпаспорт снижает зависимость от одного разработчика.
Когда обмен ломается, новый человек хотя бы понимает, с чего начать.
Связь диагностики обменов с релизами
Обмены обязательно нужно включать в релизный процесс.
Если релиз затрагивает:
- объекты, которые участвуют в обмене;
- права сервисного пользователя;
- регламентные задания;
- формат данных;
- расширения или подписки, влияющие на запись объектов;
- запросы, которые используются в выгрузке;
- справочники сопоставлений;
значит, обмен должен попасть в чек-лист проверки.
Минимальная smoke-проверка обмена после релиза:
- проверить, что регламентное задание активно;
- выполнить тестовый запуск на безопасном наборе данных;
- убедиться, что журнал запуска заполнился;
- проверить один успешный сценарий;
- проверить одну ожидаемую бизнес-ошибку;
- убедиться, что повторная обработка не создает дубль;
- посмотреть журнал регистрации на критичные ошибки.
Обмены редко ломаются “сами по себе”. Часто их ломают изменения рядом.
Главный вывод
Обмены 1С не должны быть черным ящиком.
Да, интеграции всегда будут давать сюрпризы: изменился формат, не пришел файл, внешний сервис недоступен, пользователь не настроил сопоставление, регламентное задание упало, права изменились, данные оказались нестандартными.
Но зрелость обмена определяется не отсутствием ошибок.
Зрелость обмена определяется тем, насколько быстро команда может понять:
- что произошло;
- где произошло;
- кого это затрагивает;
- можно ли повторить;
- есть ли риск дублей;
- кто должен исправлять;
- что нужно изменить, чтобы ошибка не повторялась.
Если обмен не логирует этапы, не хранит статусы, не различает технические и бизнес-ошибки, не защищается от дублей и не дает понятных рекомендаций, разработчик каждый раз будет искать проблему почти вслепую.
Если же у обмена есть журнал, этапы, статусы, внешние идентификаторы, понятные ошибки и сценарий повторной обработки, сбой перестает быть катастрофой.
Он становится рабочим инцидентом, который можно разобрать, исправить и использовать для улучшения системы.
Хороший обмен — это не тот, который никогда не падает. Хороший обмен — это тот, который при ошибке сам показывает, где болит и что делать дальше.
Именно с этого начинается нормальная эксплуатация интеграций в 1С: не с героических ночных разборов, а с диагностики, которую команда заложила заранее.
Вступайте в нашу телеграмм-группу Инфостарт