Versions Compared

Key

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

...

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

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

Правила

  1. тип: list of objects
  2. може містити: кілька КБВ або fallback-запис
Expand
titleМодель даних beneficiaries
Технічна назваБізнес назва (x-legalName)ТипRead onlyОбовʼязковість (потребує уточнень)Коментар
uk_UAen_US
beneficiaries
Інформація про кінцевого бенефеціарного влсникаInformation about the ultimate beneficial owner
list of objectstruefalse
 

fallback

  objecttruefalseМоже бути тільки один в разі відсутності даних про КБВ
 

systemReason

Системна причина відсутності данихSystemic reason for missing data stringtruefalse
 

excluded

Ознака виключення відомостей про КБВ за вказівкою Міністерства юстиції України  truefalse
 

isMissing

Ознака відсутності КБВ юридичної особи 
truefalse
 

reason

 Причина відсутності КБВ юридичної особи string (multilang)truefalse
 

informationDate

Дата отримання данихDate of informationstring ($dateTime)truetrue
 

beneficiariesGeneralInfo

  objecttruefalse

Може бути декілька.

Якщо хоча б один КБВ невалідний → НЕ записується жоден



beneficialNameПІБ кінцевого бенефеціарного власникаFull name of the ultimate beneficial ownerstring (multilang)truetrueВ запиті Прізвище це відповідь на один запит, Імʼя та По батькові - відповідь на інший запит


addressАдресаAddressmodeltruetrue


beneficiariesType

Тип бенефіціарного володінняType of 

beneficiaries

string (multilang)truetrue


roleРоль КБВ по відношенню до пов’язаного суб’єкта
stringtruetrueВідповідь на запит текстове відображення ролі (roleText)


interest

Відсоток частки статутного капіталу або відсоток права голосу
float truetrue


indirectInterest

Відсоток частки статутного капіталу або відсоток права голосу у разі непрямого впливу
floattruetrue


otherImpact

Інший характер та міру впливу
 




beneficiaryFalse

Ознака можливої недостовірності інформації про КБВ
 


Ключові правила

  1. Інтеграція тригериться тільки при створенні award в модель даних beneficiariesGeneralInfo
  2. Запит асинхронний
  3. Дані записуються тільки якщо валідні
  4. Запис — атомарний (все або нічого):
    1. або записуються всі КБВ (якщо хоча б один КБД не валідний  - не записується жоден)
    2. або записується один fallback - обʼєкт
    3. Основний сценарій:
    4. Створюється award
    5. Перевіряються умови
    6. Виконується авторизація в ЄДР
    7. Виконується запит до ЄДР
    8. Отримується відповідь
    9. Відбувається валідація
    10. Якщо валідно:
      • запис у award.beneficiaries[]
      • оновлення:
        • award.dateModified
        • procedure.dateModified
        • systemDateModified
  5. Retry (до 3 разів) тільки для: 500, 502
    1. retry з exponential backoff
    2. після 3 спроб → fallback де systemReason = "Не вдалось отримати інформацію з сервісу"

Обмеження

  1. Система не повинна виконувати безкінечні повторні запити.
  2. Інтеграція не виконується без умов
  3. Частковий запис даних заборонений

Статуси інтеграції

СтатусОпис
activeЗапити до ЄДР виконуються
payment_requiredОтримано 402, запити зупинено
rate_limit_exceededОтримано 429, запити зупинено
suspendedЗагальний статус призупинення
auth_errorПроблема з токеном
access_denied403
invalid_request400/406

Обробка помилок 

Класифікація помилок 

ТипКоди
Tech500, 502
Auth401
Business402, 429
Access403
Data400, 404, 406

Таблиця зведених правил обробки помилок

...

beneficiariesType

...

beneficiaries

...

interest

...

indirectInterest

...

otherImpact

...

beneficiaryFalse

...

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

HTTP codeТип
HTTP code
RetryЗупинка інтеграціїSlackДія
400
DATA
НіНі (можливо)Такпомилка запиту
401
AUTH
Так (1 раз)НІНіrefresh token
402
BUSINESS
НіТакТакочікування оплати
403
ACCESS
НіНі (можливо)Такперевірка доступу
404
DATA
НіНіНісуб'єкт відсутній
406DATAНіНі (можливо)Такпомилка формату429BUSINESSНІТакТакперевищено ліміт500TECHТак (3 рази)НіНітимчасова помилка502TECHТак (3 рази)НіНісервіс недоступний

Інтеграція

406НіНі (можливо)Такпомилка формату
429НІТакТакперевищено ліміт
500Так (3 рази)НіНітимчасова помилка
502Так (3 рази)НіНісервіс недоступний

Правила додаткової обробки помилок

  1. Обробка 401
    1. отримано 401

    2. refresh token

    3. повторити запит (1 раз)

      1. Якщо refresh fail

        1. integration status = auth_error

        2. повідомлення в slack

  2. Обробка 404
    1. Отримано 404
    2. запис в поле systemReason = "Суб'єкт не знайдено в ЄДР"

Slack повідомлення

Відправляються для:

  • 400
  • 402
  • 403
  • 406
  • 429
  • auth_error

Зупинка інтеграції 

Тригер

Інтеграція зупиняється при:

  • першому 402
  • першому 429

Поведінка

  • всі нові запити НЕ виконуються
  • статус інтеграції змінюється

Статуси інтеграції

...

Відновлення інтеграції

  1. Після 402

    1. внесення коштів

    2. ручне відновлення

    3. статус → active

  2. Після 429

    1. відновлення ліміту

    2. ручне відновлення
    3. статус → active
Info
titleВажливо

Старі awards НЕ обробляються повторно після відновлення інтеграції.
Якщо потрібно це передбачити то це окремий процес

Логування

Обовʼязково логувати:

  • correlationId
  • request/response
  • error code
  • retry count

Timeout

  1. timeout = 5-10 секунд
  2. retry = ексоненційна затримка

...


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

User Story 1. Автоматичне отримання КБВ

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

...

Назва

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

Дані невалідні → UC2

Помилка API → UC3/UC11-15

Результат

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

Acceptance Criteria

1

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

When

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

Then

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

2


Given

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

When

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

Then

Вони Дані про КБВ записуються в award.beneficiaries

3

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

Then

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

  • award.dateModified
  • dateModified (procedure)
  • systemDateModified

...

Назва

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

Отримано HTTP код:
400, 401, 402, 403, 404, 406, 429відповідь ЄДР

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

award без змін

Acceptance Criteria

...

Назва

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

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

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

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

Результат
  • або дані записані
  • або fallback
  • якщо успіх → UC1
  • якщо ні → запис тексту помилки
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 завершився невдачею

Основний сценарій
  1. ЦБД отримує помилку
  2. Формує повідомлення
  3. Відправляє в Slack канал
  1. Формується fallback-об’єкт
  2. Записується в beneficiaries.systemReason
Результат

award містить fallback

Результаткоманда отримує alert

Acceptance Criteria

1

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

When

Обробляється відповідь
Дані не отримані після retry

Then

Записується fallback

ANDThen

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

...

Назва

Неініціювання запиту до ЄДР
Актори

ЦБД

(primary)ЄДР API (external

(primary)

Передумови

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

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

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

Acceptance Criteria

1

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

When

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

Then

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

...

Назва

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

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

...

Назва

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

...

Назва

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

1

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

When

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

Then

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

2


Given

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

When

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

Then

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

3

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

Then

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

...

Назва

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

1

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

When

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

Then

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

2


Given

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

When

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

Then

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

3

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

Then

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

...

Назва

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

...

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

Назва

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

Refresh token

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

fail: 

  • статус → auth_error
  • ЦБД відправляє повідомлення в Slack канал. (Токен невалідний/протермінований після оновлення)
Результат
  • Інтеграція відновлюється без втручання людини
  • або помилка auth
Acceptance Criteria

1

GivenОтримано 401

When

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

Then

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

2


Given

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

Then

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

3

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

Then

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

...

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

Назва

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

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

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

    1


    GivenОтримано 400

    When

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

    Then

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

    And

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

    ...

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

    Назва

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

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

    Acceptance Criteria

    1


    GivenОтримано 403

    Then

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

    And

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

    ...

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

    Назва

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

    1


    GivenОтримано 404

    Then

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

    And

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

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

    ...

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

    Назва

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

    1


    GivenОтримано 406

    Then

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

    And

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

    ...