Post #239

Сделал для вас памятку по ошибкам интеграции: на какие вопросы стоит ответить, чтобы охватить все возможные варианты ошибок. Все ошибки делятся: ➡️ по месту возникновения: - проблемы с клиентом (системой, которая запрашивает или передаёт данные) - проблемы с сервером (система, которая отвечает на запрос) - проблемы со средой передачи (сетью) - проблемы с промежуточными системами (шлюзами, брокерами, преобразователями и т.п.) ➡️ по времени возникновения: - при обращении к серверу - при передаче/преобразовании данных (особенно если у нас длинный или составной запрос) - при получении подтверждения успешного получения от сервера ➡️ по критичности: - ещё не ошибка, но при частом повторении станет ошибкой (например, система слишком долго отвечает) - разовая ошибка, можно продолжать работу - массовая ошибка, невозможно дальше продолжить работу - один из компонентов не отвечает, но система в целом работоспособна и может это выявить - система в целом не работоспособна, выявить может только внешний мониторинг ➡️ по уровню: - технические ошибки (нет связи, таймаут) - ошибки представления: не тот протокол или формат данных (ждали xml, пришел json) - логические или бизнес ошибки (со связью всё в порядке, но сами данные не такие, как требуется: чего-то не хватает или лишнее, но без понимания смысла данных распознать ошибку невозможно) Смотрим на возможные сочетания, принимаем решение: — в нашей системе такое может быть? — кто это может обнаружить? — как системы информируют друг друга, какие есть соглашения о кодах ошибок? — как мы это будем обрабатывать? Заносим каждую ситуацию в таблицу с конкретными данными. Можно таблицу разбить на несколько: по уровням ошибок (технические/бизнесовые) или по компонентам, которые могут ошибки обнаружить / попробовать исправить. Пользуйтесь!