AUT-0299· Управління проєктами
Розбір повідомлень у черзі помилок інтеграції
Необроблене повідомлення отримує причину, відповідального й перевірений результат виправлення або погодженого повтору.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Команда повторно запускає всі повідомлення з черги помилок, дублюючи вже виконані операції або нескінченно повертаючи ту саму помилку.
02 / Результат
Кожне повідомлення має пояснену причину, рішення про подальшу дію та перевірений бізнес-результат без сліпого повтору.
03 / Процес
ТригерПовідомлення інтеграції потрапило до черги помилок або настав погоджений цикл розбору її відкритих записів.
Зафіксувати інтеграцію, чергу, ID повідомлення, ключ бізнес-операції та причину; черга помилок зберігає повідомлення, які не вдалося доставити або обробити.
Створити одну пов’язану задачу розбору для повідомлення; сирі дані й секрети лишити в дозволеному технічному джерелі.
Фахівець розрізняє непридатні дані, тимчасовий збій і помилку підтвердження обробки; наявність у черзі не доводить відсутності виконаної операції.
Звірити актуальний стан бізнес-об’єкта та попередні результати; невизначений запис або платіж залишити на звірці без повторного створення.
Погодити виправлення даних або обробника й придатність повідомлення зараз; застарілу подію не відтворювати поверх новішого стану.
Для дозволеного повтору записати виконавця, вихідний ID, редакцію даних і ключ захисту від дублювання; запуск передати технічному маршруту.
Перевірити результат у цільовій системі; прийняття до основної черги не означає завершення бізнес-операції.
Зафіксувати підтверджений результат або відмову від повтору з поясненням; остаточне прибирання повідомлення виконувати за погодженим порядком зі збереженням історії.
04 / Реалізація1 варіант
Приклад · Розбір з перевіркою бізнес-операції
Обробник створив замовлення, але не підтвердив завершення повідомлення брокеру. Після повторних доставок повідомлення опинилося в черзі помилок. Фахівець знайшов замовлення за бізнес-ключем і не створив друге. Для іншого повідомлення виправили формат даних; прийняття повтору до черги перевірили окремо від фактичного запису в CRM.
Спосіб реалізації
- Проєктна модель PlanFix: задача розбору, технічне джерело, бізнес-ключ, причина, рішення й посилання на докази; адаптер брокера та маршрут повтору проєктують окремо.
Що потрібно для реалізації
- Є черга помилок, доступ до її метаданих і уповноважений технічний фахівець.
- Доступні стабільні ID операцій, стан цільового об’єкта та погоджений маршрут повтору.
- Є читання фактичного стану операції й дозволений порядок повтору.
Обмеження
- Не є звіркою повноти всіх подій джерела: повідомлення, яке не дійшло до черги, потребує іншого контролю.
- Не гарантує одноразової обробки лише через унікальний ID повідомлення; перевіряють захист самої бізнес-операції.
- Повтор, що може створити платіж або надіслати повідомлення клієнту, потребує окремих погоджених правил.
- Поведінка Azure Service Bus не задана універсально для всіх брокерів; доступ, зберігання й підтвердження перевіряють у цільовій системі.
- Не копіює повні повідомлення, ключі доступу або персональні дані у загальні задачі.
- Години попередні; розробка нової інтеграції, повне відновлення історії та витрати брокера не включені.
- Не видаляє всі помилки за фактом запуску повтору.
- Не повторює невизначену фінансову операцію без звірки.
Що потрібно уточнити (2)
- Чи потрібно автоматично отримувати метадані повідомлень із брокера?
Перевірте права читання, стабільні ID та дозволений обсяг даних; автоматичне читання не дає дозволу на повтор.
- Чи потрібен керований запуск погодженого повтору з перевіркою цільового результату?
Погодьте технічний маршрут, захист бізнес-операції від дублів і обробку невизначеного результату.