Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Також можливий кейс, що АРІ поверне 403 помилку, якщо, наприклад, ЄДР змінить права доступу нашого акаунту.

...

Помилки

Коди помилок та відповідей:

Коди відповідей 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

Сервіс вимкнено або проходить оновлення.

...

{"errors":[{"message":"Invalid or expired token","code":2}]}

Перелік кодів помилок

У відповіді, окрім повідомлення з поясненням, додатково надається код помилки, який можна використовувати для автоматизованої обробки. Протягом часу, текстове повідомлення може модифікуватись, але код залишається незмінним.

Код

Текст

Пояснення

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.

Правила обробки помилок

HTTP codeRetryЗупинка інтеграціїSlackДія
системи
400
Slack alert, дані не записуються401Slack alert, спроба оновити token402Slack alert, дані не записуються403Slack alert, дані не записуються404Slack alert, дані не записуються406Slack alert, дані не записуються429Slack alert, дані не записуються500Retry до 3 разів502Retry до 3 разів

User Story 1

НіНіТакбаг у запиті
401Так (1 раз)НІНіrefresh token
402НіТакТакчекати оплату
403НіМожливоТакперевірити доступ
404НіМожливоНінемає суб'єкта
406НіМожливоТакформат
429НІТакТакліміт
500Так (3 рази)НіНітимчасова помилка
502Так (3 рази)НіНісервіс недоступний

Сценарії роботи інтеграції з ЄДР

User Story 1

ЯкЦБД Prozorro.Sale
я
ЯкЦБД Prozorro.Sale
я хочуавтоматично отримувати та зберігати інформацію про кінцевих бенефіціарних власників (КБВ) з ЄДР при створенні award
щобзабезпечити актуальність, централізацію та зменшити залежність від ручного введення даних

USE CASE 1 — Успішне отримання та збереження КБВ

Назва

Отримання та запис КБВ з ЄДР в award
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Процедура входить в перелік дозволених (LLE, LLD, …, SUD)
  • В процедурі використовується документ x_ultimateBeneficiaryInfo
  • Учасник є юридичною особою
  • award.bidders.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
Основний сценарій
  1. Учасник подає заявку
  2. Майданчик активує заявку
  3. Заявка переходить у кваліфікацію
  4. ЦБД створює award
  5. ЦБД перевіряє умови запуску інтеграції
  6. ЦБД виконує авторизацію в ЄДР (отримує JWT токен)
  7. ЦБД відправляє запит до ЄДР з code = ЄДРПОУ
  8. ЄДР повертає дані КБВ (може бути список)
  9. ЦБД валідовує відповідь
  10. Дані відповідають моделі beneficiariesGeneralInfo
  11. ЦБД записує дані в award.beneficiaries
  12. Оновлює:
  • award.dateModified
  • procedure.dateModified
  • systemDateModified
Результат

award містить список КБВ (може бути декілька)

Acceptance Criteria

1

GivenВсі умови виконані

When

Створюється award

Then

Відправляється запит до ЄДР

2


Given

ЄДР повернув валідні дані

When

Дані проходять валідацію

Then

Вони записуються в award.beneficiaries

3

GivenДані записані

Then

оновлюються всі dateModified:

  • award.dateModified
  • dateModified (procedure)
  • systemDateModified


...

USE CASE 2 — Дані не можуть бути внесені

Назва

Відмова у записі КБВ
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

Отримано HTTP код:
400, 401, 402, 403, 404, 406, 429

Основний сценарій
  1. ЦБД отримує відповідь від ЄДР
  2. Перевіряє структуру
  3. Дані:
    • неповні / некоректні / не мапляться
  4. ЦБД НЕ записує дані
Результат

award без змін

Acceptance Criteria

1

GivenДані не відповідають моделі

When

Виконується валідація

Then

Дані не записуються


...

USE CASE 3 — Retry при помилках 500 / 502

Назва

Повторна спроба отримання даних
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

Отримано HTTP код:
500, 502

Основний сценарій
  1. ЦБД відправляє запит
  2. Отримує 500 або 502
  3. Виконує retry
  4. Повторює до 3 разів
Альтернативний сценарій

після 3 невдалих спроб → fallback

Результат
  • якщо успіх → UC1
  • якщо ні → запис тексту помилки
Acceptance Criteria

1

GivenОтримано 500/502

When

Виконується retry

Then

Система повторює запит до 3 разів

2

GivenВсі retry невдалі

Then

Записується повідомлення:
"Не вдалось отримати інформацію з сервісу"


...

USE CASE 4 — Логування помилок в Slack

Назва

Моніторинг інтеграції з ЄДР
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Отримано HTTP код:
    400, 401, 402, 403, 404, 406, 429
Основний сценарій
  1. ЦБД отримує помилку
  2. Формує повідомлення
  3. Відправляє в Slack канал
Результат
  • команда отримує alert
Acceptance Criteria

1

GivenОтримано помилку зі списку

When

Обробляється відповідь

Then

Відправляється повідомлення в Slack


...

USE CASE 5 — Інтеграція не запускається

Назва

Неініціювання запиту до ЄДР
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови

Будь-яка з умов НЕ виконується:

    • процедура не з переліку
    • відсутній x_ultimateBeneficiaryInfo
    • не юрособа
    • не UA-EDR
    • статус award не підходить
Основний сценарій
  1. Створюється award
  2. ЦБД перевіряє умови
  3. Інтеграція НЕ запускається
Результат

Жодних запитів до ЄДР

Acceptance Criteria

1

GivenУмови не виконані

When

Створюється award

Then

запит до ЄДР не виконується


...

USE CASE 6 — Обробка множинних КБВ

Назва

Запис кількох бенефіціарів
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Процедура входить в перелік дозволених (LLE, LLD, …, SUD)
  • В процедурі використовується документ x_ultimateBeneficiaryInfo
  • Учасник є юридичною особою
  • award.bidders.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
Основний сценарій
  1. ЄДР повертає список КБВ
  2. ЦБД мапить кожен запис
  3. Формує list of objects
  4. Записує в award.beneficiaries[]
Результат

Збережено всі КБВ

Acceptance Criteria

1

GivenЄДР повертає кілька КБВ

When

Відбувається запис

Then

Всі КБВ зберігаються в масиві

User Story 2. Зупинка запитів в разі отримання помилок 402 або 429

ЯкЦБД Prozorro.Sale
я хочузупиняти направлення запитів до ЄДР після першого отримання помилки 402 або 429
щобне створювати зайве навантаження на сервіс, не витрачати ліміти та уникати повторних неуспішних запитів до моменту відновлення доступу/поповнення коштів. 
додатковоПісля внесення коштів або відновлення ліміту система має відновити направлення запитів до ЄДР.

USE CASE 7 — Зупинка запитів після отримання 402

Назва

Автоматичне призупинення інтеграції з ЄДР при помилці 402 Payment Required
Актори
  • ЦБД
  • ЄДР
  • Адміністратор/відповідальна команда
  • Slack канал
Передумови
  • Інтеграція з ЄДР активна
  • ЦБД направляє запит до ЄДР для отримання даних КБВ
  • ЄДР повертає HTTP 402
  • У вимогах уже передбачено фіксацію таких помилок у Slack.
Основний сценарій
  1. ЦБД направляє запит до ЄДР.
  2. ЄДР повертає відповідь 402 Payment Required.
  3. ЦБД фіксує факт отримання помилки.
  4. ЦБД змінює внутрішній статус інтеграції з ЄДР на умовний:
    • suspended;
    • або payment_required;
    • або temporarily_disabled.
  5. ЦБД припиняє направлення нових запитів до ЄДР.
  6. ЦБД відправляє повідомлення в Slack канал.
  7. Для нових awards, які підпадають під умови інтеграції, запит до ЄДР не виконується.
  8. У відповідному полі/технічному статусі фіксується причина:
    • Запити до ЄДР тимчасово призупинено через необхідність оплати.
Результат
  • Нові запити до ЄДР не направляються.
  • Команда отримала повідомлення про необхідність внесення коштів.
  • Дані КБВ для нових awards тимчасово не збагачуються.
Acceptance Criteria

1

GivenЦБД отримала від ЄДР відповідь 402

When

Система обробляє відповідь

Then

Інтеграція з ЄДР переходить у статус призупинення.

2


Given

Інтеграція має статус призупинення через 402

When

Створюється новий award, який відповідає умовам інтеграції

Then

ЦБД не направляє запит до ЄДР.

3

GivenОтримано 402
WhenСистема фіксує помилку

Then

Повідомлення надсилається в Slack канал.


...

USE CASE 8 — Зупинка запитів після отримання 429

Назва

Автоматичне призупинення інтеграції з ЄДР при помилці 429 Many Requests
Актори
  • ЦБД
  • ЄДР
  • Slack канал
  • Адміністратор/відповідальна команда
Передумови
  • Інтеграція з ЄДР активна
  • ЦБД направляє запит до ЄДР
  • ЄДР повертає HTTP 429
  • 429 означає, що вичерпано обмеження запитів до ресурсу.
Основний сценарій
  1. ЦБД направляє запит до ЄДР.
  2. ЄДР повертає відповідь 429 Many Requests.
  3. ЦБД фіксує помилку.
  4. ЦБД призупиняє направлення нових запитів до ЄДР.
  5. ЦБД відправляє повідомлення в Slack канал.
  6. Нові awards, які підпадають під інтеграцію, не ініціюють запит до ЄДР.
  7. Система фіксує причину призупинення:
    • Перевищено ліміт запитів до ЄДР.
Результат
  • Інтеграція тимчасово зупинена.
  • Нові запити до ЄДР не виконуються.
  • Команда повідомлена про перевищення ліміту.
Acceptance Criteria

1

GivenЦБД отримала відповідь 429

When

Система обробляє відповідь

Then

Направлення нових запитів до ЄДР зупиняється.

2


Given

Інтеграція призупинена через 429

When

Створюється новий award

Then

ЦБД не направляє запит до ЄДР

3

GivenОтримано 429
WhenСистема обробляє помилку

Then

Повідомлення надсилається в Slack канал.


...

USE CASE 9 — Відновлення запитів після внесення коштів

Назва

Ручне або автоматичне відновлення інтеграції з ЄДР після внесення коштів
Актори
  • Адміністратор/відповідальна команда
  • ЦБД
  • ЄДР
Передумови
  • Інтеграція з ЄДР була призупинена через 402
  • Кошти внесено / доступ до сервісу відновлено
Основний сценарій
  1. Відповідальна команда вносить кошти.
  2. Адміністратор ініціює відновлення інтеграції.
  3. ЦБД змінює статус інтеграції з:
    • payment_required / suspended
    • на active.
  4. ЦБД відновлює направлення запитів до ЄДР.
  5. При створенні наступного award ЦБД знову виконує стандартну логіку запиту до ЄДР.
  6. Якщо ЄДР повертає 200, дані КБВ обробляються та записуються в award.
Результат
  • Інтеграція з ЄДР активна.
  • Нові запити знову направляються.
  • Дані КБВ можуть бути отримані та внесені в award.
Acceptance Criteria

1

GivenІнтеграція призупинена через 402
AndКошти внесено

When

Адміністратор активує інтеграцію

Then

Статус інтеграції змінюється на active.

2


Given

Інтеграція активна після відновлення

When

Створюється новий award

Then

ЦБД направляє запит до ЄДР

3

GivenЄДР після відновлення повертає 200
WhenЦБД отримує валідні дані

Then

Дані записуються в award.beneficiaries


...

USE CASE 10 — Відновлення після вичерпання ліміту запитів

Назва

Відновлення інтеграції після помилки 429
Актори
  • Адміністратор/відповідальна команда
  • ЦБД
  • ЄДР
Передумови
  • Інтеграція була призупинена через 429
  • Ліміт запитів поновлено або відповідальна команда підтвердила можливість повторного використання сервісу
Основний сценарій
  1. Відповідальна команда перевіряє, що ліміт запитів відновлено.
  2. Адміністратор активує інтеграцію.
  3. ЦБД змінює статус інтеграції на active.
  4. Наступні awards знову запускають запит до ЄДР.
  5. Якщо ЄДР повертає успішну відповідь — дані обробляються за стандартним сценарієм.
Результат
  • Запити до ЄДР відновлені.
  • Система продовжує автоматичне збагачення awards даними КБВ.
Acceptance Criteria

1

GivenІнтеграція призупинена через 429

When

Ліміт запитів відновлено

And

Адміністратор активує інтеграцію

Then

ЦБД знову направляє запити до ЄДР

2


Given

Інтеграція активована після 429

When

Створюється award

Then

Запит до ЄДР виконується

User Story 3. Обробка помилок інтеграції з ЄДР та забезпечення стабільності системи

ЯкЦБД Prozorro.Sale
я хочукоректно обробляти всі типи помилок від ЄДР (400, 401, 403, 404, 406, 500, 502)
щобзабезпечити стабільну роботу системи, не втрачати дані та мати можливість відновлення інтеграції

USE CASE 11 — Обробка 401 (Unauthorized)

...

Назва

...

  • ЦБД
  • ЄДР
  • Slack

...

  • Запит до ЄДР виконано
  • Отримано 401 Unauthorized

...

  1. ЦБД отримує 401
  2. Визначає, що токен невалідний / протермінований
  3. Виконує запит на оновлення access_token через refresh_token
  4. Отримує новий токен
  5. Повторює запит до ЄДР (1 раз)
  6. Якщо успішно → стандартний сценарій (запис даних)

...

Refresh token невалідний → перейти до помилки критичного рівня

...

Інтеграція відновлюється без втручання людини

типи помилок від ЄДР (400, 401, 403, 404, 406, 500, 502)
щобзабезпечити стабільну роботу системи, не втрачати дані та мати можливість відновлення інтеграції

USE CASE 11 — Обробка 401 (Unauthorized)

Назва

Автоматичне оновлення токена при помилці 401

Acceptance Criteria

...

1

...

When

...

Then

...

2

...

Токен оновлено

...

Then

...

3

...

Then

...

дані записуються в award

USE CASE 12 — Помилка 400 (Bad Request)

...

Назва

...

  • ЦБД
  • ЄДР
  • Slack

...

  • неправильний формат параметрів
  • неправильний code

...

  1. ЦБД отримує 400
  2. Аналізує помилку
  3. Визначає:
    • помилка у формуванні запиту
  4. НЕ виконує retry
  5. Логує помилку
  6. Надсилає повідомлення в Slack

...

Виправлення формату запиту (dev fix)

...

  • запит не повторюється
  • потрібне втручання розробника

Acceptance Criteria

1

...

When

...

Then

...

And

...

USE CASE 13 — Помилка 403 (Forbidden)

Назва

Обробка відсутності прав доступу
Актори
  • ЦБД
  • ЄДР
  • Slack
Передумови
  • Запит до ЄДР виконано
  • Отримано 401 Unauthorized
  • змінились права доступу до API
  • акаунт не має доступу
Основний сценарій
  1. ЦБД отримує 403
  2. Фіксує помилку
  3. НЕ виконує retry
  4. Відправляє alert в Slack
  5. (опційно) переводить інтеграцію в статус restricted
Рішення
  • перевірка прав доступу
  • перевидача ключів / ролей
  1. 401
  2. Визначає, що токен невалідний / протермінований
  3. Виконує запит на оновлення access_token через refresh_token
  4. Отримує новий токен
  5. Повторює запит до ЄДР (1 раз)
  6. Якщо успішно → стандартний сценарій (запис даних)
Альтернативний сценарій

Refresh token невалідний → перейти до помилки критичного рівня

Результат

Інтеграція відновлюється без втручання людини

Результат

Інтеграція не працює до виправлення

Acceptance Criteria

1

GivenОтримано 403

Then

Retry не виконується

And

Slack отримує повідомлення

...

401

When

Токен протермінований

Then

Система виконує refresh token

2


Given

Токен оновлено

Then

Запит повторюється 1 раз

3

Givenповторний запит успішний

Then

дані записуються в award


...

USE CASE 12 — Помилка 400 (Bad Request)

Назва

Обробка відсутності суб’єкта в некоректного запиту до ЄДР
Актори
  • ЦБД
  • ЄДР
  • Slack
ПередумовиЄДРПОУ не знайдено
  • неправильний формат параметрів
  • неправильний code
Основний сценарій
  1. ЦБД отримує 404 400
  2. Аналізує помилку
  3. Визначає:
    • помилка у формуванні запиту
    Визначає, що суб'єкт відсутній
  4. НЕ виконує retry
  5. Записує beneficiaries тільки поле reason:
    • "Суб'єкт не знайдено в ЄДР"
  6. Логує помилку
  7. Надсилає повідомлення в Slack
Рішення

Виправлення формату запиту (dev fix)

Результат
  • запит не повторюється
  • потрібне втручання розробника
Результат
  • award без КБВ
Acceptance Criteria

1


GivenОтримано 404400

When

Обробляється помилка

Then

Retry не виконується

And

Записує beneficiaries тільки поле reason:

    • "Суб'єкт не знайдено в ЄДР"

...

Slack отримує повідомлення


...

USE CASE 13 — Помилка 403 (Forbidden)

Назва

Обробка помилки формату данихвідсутності прав доступу
Актори
  • ЦБД
  • ЄДР
  • Slack
Передумови

Некоректний формат request/response

Передумови
  • змінились права доступу до API
  • акаунт не має доступу
Основний сценарій
  1. ЦБД отримує 406 403
  2. Фіксує помилку
  3. НЕ виконує retry
  4. Відправляє alert в Slack
  5. (опційно) переводить інтеграцію в статус restricted
Рішення
  • перевірка контракту APIправ доступу
  • перевидача ключів / ролейвиправлення формату
Результатінтеграція потребує доопрацювання

Інтеграція не працює до виправлення

Acceptance Criteria

1


GivenОтримано 406403

Then

Retry не виконується

And

Slack отримує повідомлення

ЗВЕДЕНА ТАБЛИЦЯ


...

USE CASE 14 — Помилка 404 (Not Found)

Назва

Обробка відсутності суб’єкта в ЄДР
Актори
  • ЦБД
  • ЄДР
КодRetryЗупинка інтеграції
  • Slack
Дія
Передумови
400НіНіТакбаг у запиті401Так (1 раз)НІНіrefresh token402НіТакТакчекати оплату403НіМожливоТакперевірити доступ404НіМожливоНінемає суб'єкта406НіМожливоТакформат429НІТакТакліміт500Так (3 рази)НіНітимчасова помилка502Так (3 рази)НіНі

ЄДРПОУ не знайдено

Основний сценарій
  1. ЦБД отримує 404
  2. Визначає, що суб'єкт відсутній
  3. НЕ виконує retry
  4. Записує beneficiaries тільки поле reason:
    • "Суб'єкт не знайдено в ЄДР"
Результат
  • award без КБВ
Acceptance Criteria

1


GivenОтримано 404

Then

Retry не виконується

And

Записує beneficiaries тільки поле reason:

    • "Суб'єкт не знайдено в ЄДР"


...

USE CASE 15 — Помилка 406 (Not Acceptable)

Назва

Обробка помилки формату даних
Актори
  • ЦБД
  • ЄДР
  • Slack
Передумови

Некоректний формат request/response

Основний сценарій
  1. ЦБД отримує 406
  2. Фіксує помилку
  3. НЕ виконує retry
  4. Відправляє alert в Slack
Рішення
  • перевірка контракту API
  • виправлення формату
Результат
  • інтеграція потребує доопрацювання
Acceptance Criteria

1


GivenОтримано 406

Then

Retry не виконується

And

Slack отримує повідомлення
сервіс недоступний