Что было нужно сделать и почему это не закрывалось штатными средствами.
Задача и сложность
Данные между CRM и внешними системами расходились: часть статусов приходила с задержкой, часть операций падала, а ручная сверка занимала время.
Главная проблема была не просто вызвать API, а сделать обмен сопровождаемым: видеть ошибки, повторять безопасно и понимать, на каком этапе застряла сущность.
Главная проблема была не просто вызвать API, а сделать обмен сопровождаемым: видеть ошибки, повторять безопасно и понимать, на каком этапе застряла сущность.
Какие технические блоки были собраны и как они связаны между собой.
Контур решения
Сделан интеграционный слой с сопоставлением сущностей, очередью задач, cron-обработкой, логом событий и повторной отправкой после ошибок.
Для нестабильных операций добавлены статусы, backoff/retry и диагностические представления, чтобы поддержка могла отличить сетевую ошибку от ошибки данных.
Для нестабильных операций добавлены статусы, backoff/retry и диагностические представления, чтобы поддержка могла отличить сетевую ошибку от ошибки данных.
Какой практический результат получил бизнес или команда.
Что получилось
Интеграция стала не чёрным ящиком, а контролируемым контуром. Ошибки можно разбирать по событиям, а не искать вручную в CRM и внешней системе.
Подход: сначала диагностика и границы изменений, потом минимальный рабочий контур, затем проверка на данных и отдельные repair/monitoring-инструменты там, где это нужно.
← Все кейсы