...
Коди помилок та відповідей:
Коди відповідей HTTP
Код | Текст | Пояснення |
|---|---|---|
200 | OK | Запит успішно оброблено і повернуто результат |
400 | Bad Request | Запит має помилку або не може бути оброблений. Відповідне повідомлення з поясненнями додане до відповіді. |
401 | Unauthorized | Параметри авторизації не правильні, або не вказані взагалі. |
402 | PaymentRequired | Для виконання запиту необхідна оплата. |
403 | Forbidden | Запит вірний але в обробці відмовлено. Відповідне повідомлення з поясненнями додано до відповіді. |
404 | Not Found | Адреса не правильна або ресурс до якого йде запит не існує. |
406 | Not Acceptable | Дані передані в запиті мають не зрозумілий формат. |
429 | Many Requests | API повертає таку відповідь коли вичерпано обмеження запитів до ресурсу. |
500 | Internal Server Error | Щось зламалось. |
502 | Bad Gateway | Сервіс вимкнено або проходить оновлення. |
Повідомлення з інформацією про помилку.
...
У відповіді, окрім повідомлення з поясненням, додатково надається код помилки, який можна використовувати для автоматизованої обробки. Протягом часу, текстове повідомлення може модифікуватись, але код залишається незмінним.
Код | Текст | Пояснення |
1 | Could not authenticate you або Authentication credentials were not provided | Помилка аутентифікації. |
2 | Invalid or expired token | Недіючий або некоректний токен. |
3 | Your account is not permitted to access this resource | Відповідь надається разом із HTTP статусом 403. Користувач, з використанням токену якого було виконано аутентифікацію, не має достатніх прав для виконання запиту. |
4 | Sorry, that page does not exist | Відповідь надається разом із HTTP статусом 404. Сторінка до якої виконується запит не знайдена. |
5 | Paiment required | Відповідь надається разом із HTTP статусом 402. Недостатньо коштів для виконання платного запиту. |
6 | Parse Error або `search_date` has wrong format | Відповідь надається разом із HTTP статусом 400. Не правильний формат одного або декількох параметрів запиту. |
9 | Rate limit exceeded | Відповідь надається разом із HTTP статусом 429. Вичерпано кількість запитів, дозволених виконати протягом проміжку часу. |
10 | `code` or `passport` parameter must be provided. | У запиті не надано параметрів необхідних для виконання пошуку. |
11 | `passport` parameter has wrong value. | Один або більше параметрів запиту має невірний формат. |
20 | Internal error | Відповідь надається разом із HTTP статусом 500. |
Технічні вимоги до автоматичного збагачення award даними КБВ з ЄДР
Ключові правила
- Інтеграція тригериться тільки при створенні award в модель даних beneficiariesGeneralInfo
- Запит асинхронний
- Дані записуються тільки якщо валідні
- Запис — атомарний (все або нічого)
- Можливі декілька КБВ
- Retry (3 рази) тільки для:
- 500
- 502
- Slack alert тільки для:
- 400, 402, 403, 409, 429
- Fallback текст при недоступності ЄДР
- У разі отримання першої відповіді від ЄДР з HTTP статусом 402 або 429 ЦБД має призупинити направлення всіх наступних запитів до сервісу ЄДР до моменту ручного або автоматичного відновлення інтеграції після внесення коштів / відновлення ліміту.
- Система повинна обробляти помилки ЄДР:
- технічні помилки (500, 502) → retry (Якщо не вдається отримати відповідь виводимо в поле systemReason текст "Не вдалось отримати інформацію з сервісу")
- авторизаційні (401) → refresh token
- бізнес/доступ (402, 403, 406, 429) → зупинка або alert
- помилки даних (400) → без retry, з логуванням
- помилки даних (404) → без retry (Якщо не вдається отримати відповідь виводимо в поле systemReason текст "Суб'єкт не знайдено в ЄДР")
Система не повинна виконувати безкінечні повторні запити.
Модель даних beneficiaries
...
| title | Модель даних beneficiaries |
|---|
...
fallback
...
systemReason
...
excluded
...
isMissing
...
reason
...
informationDate
...
beneficiariesGeneralInfo
...
Може бути декілька.
Якщо хоча б один КБВ невалідний → НЕ записується жоден
...
Модель даних beneficiaries
Поле в award
beneficiaries: [beneficiariesGeneralInfo ]
Правила
- тип: list of objects
- може містити: кілька КБВ або fallback-запис
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ключові правила
- Інтеграція тригериться тільки при створенні award в модель даних beneficiariesGeneralInfo
- Запит асинхронний
- Дані записуються тільки якщо валідні
- Запис — атомарний (все або нічого):
- або записуються всі КБВ (якщо хоча б один КБД не валідний - не записується жоден)
- або записується один fallback - обʼєкт
- Основний сценарій:
- Створюється award
- Перевіряються умови
- Виконується авторизація в ЄДР
- Виконується запит до ЄДР
- Отримується відповідь
- Відбувається валідація
- Якщо валідно:
- запис у
award.beneficiaries[] - оновлення:
- award.dateModified
- procedure.dateModified
- systemDateModified
- запис у
- Retry (до 3 разів) тільки для: 500, 502
- retry з exponential backoff
- після 3 спроб → fallback де systemReason = "Не вдалось отримати інформацію з сервісу"
Обмеження
- Система не повинна виконувати безкінечні повторні запити.
- Інтеграція не виконується без умов
- Частковий запис даних заборонений
Статуси інтеграції
| Статус | Опис |
|---|---|
active | Запити до ЄДР виконуються |
payment_required | Отримано 402, запити зупинено |
rate_limit_exceeded | Отримано 429, запити зупинено |
suspended | Загальний статус призупинення |
| auth_error | Проблема з токеном |
| access_denied | 403 |
| invalid_request | 400/406 |
Обробка помилок
Класифікація помилок
| Тип | Коди |
|---|---|
| Tech | 500, 502 |
| Auth | 401 |
| Business | 402, 429 |
| Access | 403 |
| Data | 400, 404, 406 |
Таблиця зведених правил обробки помилок
...
beneficiariesType
...
beneficiaries
...
interest
...
indirectInterest
...
otherImpact
...
beneficiaryFalse
...
Правила обробки помилок
| HTTP code |
|---|
| Retry | Зупинка інтеграції | Slack | Дія |
|---|---|---|---|
| 400 |
| Ні | Ні (можливо) | Так | помилка запиту | |
| 401 |
| Так (1 раз) | НІ | Ні | refresh token | |
| 402 |
| Ні | Так | Так | очікування оплати | |
| 403 |
| Ні | Ні (можливо) | Так | перевірка доступу |
| 404 |
| Ні | Ні | Ні | суб'єкт відсутній |
Інтеграція
| 406 | Ні | Ні (можливо) | Так | помилка формату |
| 429 | НІ | Так | Так | перевищено ліміт |
| 500 | Так (3 рази) | Ні | Ні | тимчасова помилка |
| 502 | Так (3 рази) | Ні | Ні | сервіс недоступний |
Правила додаткової обробки помилок
Обробка 401
отримано 401
refresh token
повторити запит (1 раз)
Якщо refresh fail
integration status = auth_error
повідомлення в slack
Обробка 404
- Отримано 404
- запис в поле systemReason = "Суб'єкт не знайдено в ЄДР"
Slack повідомлення
Відправляються для:
- 400
- 402
- 403
- 406
- 429
- auth_error
Зупинка інтеграції
Тригер
Інтеграція зупиняється при:
- першому
402 - першому
429
Поведінка
- всі нові запити НЕ виконуються
- статус інтеграції змінюється
Статуси інтеграції
...
Відновлення інтеграції
Після 402
внесення коштів
ручне відновлення
статус → active
Після 429
відновлення ліміту
- ручне відновлення
- статус → active
| Info | ||
|---|---|---|
| ||
Старі awards НЕ обробляються повторно після відновлення інтеграції. |
Логування
Обовʼязково логувати:
- correlationId
- request/response
- error code
- retry count
Timeout
- timeout = 5-10 секунд
- retry = ексоненційна затримка
...
Сценарії роботи інтеграції з ЄДР
User Story 1. Автоматичне отримання КБВ
| Як | ЦБД Prozorro.Sale |
| я хочу | автоматично отримувати та зберігати інформацію про кінцевих бенефіціарних власників (КБВ) з ЄДР при створенні award |
| щоб | забезпечити актуальність, централізацію та зменшити залежність від ручного введення даних |
...
Назва | Отримання та запис КБВ з ЄДР в award |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| Альтернативний сценарій | Дані невалідні → UC2 Помилка API → UC3/UC11-15 |
| Результат | award містить список валідних КБВ (може бути декілька) |
Acceptance Criteria
1 | Given | Всі умови виконані |
When | Створюється award | |
Then | Відправляється запит до ЄДР | |
2 | Given | ЄДР повернув валідні дані |
When | Дані проходять валідацію | |
Then | Вони Дані про КБВ записуються в award.beneficiaries | |
3 | Given | Дані записані |
Then | оновлюються всі dateModified:
|
...
Назва | Відмова у записі КБВ |
| Актори |
|
| Передумови | Отримано HTTP код: |
| Основний сценарій |
|
| Альтернативний сценарій | Всі КБВ валідні → UC1 |
| Результат | award без змін |
Acceptance Criteria
...
Назва | Повторна спроба отримання даних |
| Актори |
|
| Передумови | Отримано HTTP код: |
| Основний сценарій |
|
| Альтернативний сценарій | після 3 невдалих спроб → fallbackВсі retry невдалі → UC4 |
| Результат |
|
Acceptance Criteria
1 | Given | Отримано 500/502 |
When | Виконується retry | |
Then | Система повторює запит до 3 разів | |
2 | Given | Всі retry невдалі |
Then | Записується повідомлення в поле systemReason: |
...
USE CASE 4 —
...
Fallback
Назва Моніторинг інтеграції з ЄДР | Внесення системної помилки | ||
| Актори | ЦБД (primary)ЄДР API (external(primary) | ||
| ПередумовиОтримано HTTP код: 400, 401, 402, 403, 404, 406, 429 | retry завершився невдачею | ||
| Основний сценарій |
|
| |
| Результат | award містить fallback | Результат | команда отримує alert |
Acceptance Criteria
1 | Given | Отримано помилку зі списку |
When | Обробляється відповідь | |
| Дані не отримані після retry | ||
Then | Записується fallback | |
ANDThen | Відправляється повідомлення в Slack |
...
Назва | Неініціювання запиту до ЄДР |
| Актори | ЦБД (primary)ЄДР API (external(primary) |
| Передумови | Будь-яка з умов НЕ виконується:
|
| Основний сценарій |
|
| Результат | Жодних запитів до ЄДР |
Acceptance Criteria
1 | Given | Умови не виконані |
When | Створюється award | |
Then | запит до ЄДР не виконується |
...
Назва | Запис кількох бенефіціарів |
| Актори |
|
| Передумови |
|
| |
| Передумови |
|
| Основний сценарій |
|
| Альтернативний сценарій | хоча б один невалідний КБВ → UC2 |
| Результат | Збережено всі КБВ |
...
Назва | Автоматичне призупинення інтеграції з ЄДР при помилці 402 Payment Required | ||
| Актори |
| ||
| Передумови |
| ||
| Основний сценарій |
payment_required;або temporarily_disabled. | ||
| Результат | Результат |
|
|
...
Назва | Автоматичне призупинення інтеграції з ЄДР при помилці 429 Many Requests |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| Результат |
|
Acceptance Criteria
1 | Given | ЦБД отримала відповідь 429 |
When | Система обробляє відповідь | |
Then | Направлення нових запитів до ЄДР зупиняється. | |
2 | Given | Інтеграція призупинена через |
When | Створюється новий award | |
Then | ЦБД не направляє запит до ЄДР | |
3 | Given | Отримано 429 |
| When | Система обробляє помилку | |
Then | Повідомлення надсилається в Slack канал. |
...
Назва | Ручне або автоматичне відновлення інтеграції з ЄДР після внесення коштів |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| Результат |
|
Acceptance Criteria
1 | Given | Інтеграція призупинена через 402 |
| And | Кошти внесено | |
When | Адміністратор активує інтеграцію | |
Then | Статус інтеграції змінюється на active. | |
2 | Given | Інтеграція активна після відновлення |
When | Створюється новий award | |
Then | ЦБД направляє запит до ЄДР | |
3 | Given | ЄДР після відновлення повертає 200 |
| When | ЦБД отримує валідні дані | |
Then | Дані записуються в |
...
Назва | Відновлення інтеграції після помилки 429 |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| Результат |
|
...
USE CASE 11 — Обробка 401 (Unauthorized)
Назва | Автоматичне оновлення токена при помилці 401 |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| |
| Альтернативний сценарій | Refresh token |
fail:
| |
| Результат |
|
Acceptance Criteria
1 | Given | Отримано 401 |
When | Токен протермінований | |
Then | Система виконує refresh token | |
2 | Given | Токен оновлено |
Then | Запит повторюється 1 раз | |
3 | Given | повторний запит успішний |
Then | дані записуються в award |
...
USE CASE 12 — Помилка 400 (Bad Request)
Назва | Обробка некоректного запиту до ЄДР |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
| |
| Рішення | Виправлення формату запиту (dev fix) |
| Результат |
|
Acceptance Criteria
1 | Given | Отримано 400 |
When | Обробляється помилка | |
Then | Retry не виконується | |
And | Slack отримує повідомлення |
...
USE CASE 13 — Помилка 403 (Forbidden)
Назва | Обробка відсутності прав доступу |
| Актори |
|
| Передумови |
|
| Основний сценарій |
|
|
|
|
restricted
| |
| Рішення |
|
| Результат | Інтеграція не працює до виправлення |
Acceptance Criteria
1 | Given | Отримано 403 |
Then | Retry не виконується | |
And | Slack отримує повідомлення |
...
USE CASE 14 — Помилка 404 (Not Found)
Назва | Обробка відсутності суб’єкта в ЄДР |
| Актори |
|
| Передумови |
| |
| Основний сценарій |
|
| |
| Результат |
|
Acceptance Criteria
1 | Given | Отримано 404 |
Then | Retry не виконується | |
And | Записує beneficiaries тільки поле reason:
|
...
USE CASE 15 — Помилка 406 (Not Acceptable)
Назва | Обробка помилки формату даних |
| Актори |
|
| Передумови |
| |
| Основний сценарій |
|
| |
| Рішення |
|
| Результат |
|
|
Acceptance Criteria
1 | Given | Отримано 406 |
Then | Retry не виконується | |
And | Slack отримує повідомлення |
...