Versions Compared

Old Version 50

changes.mady.by.user valeriia denysenko

Saved on

compared with

New Version 51

changes.mady.by.user valeriia denysenko

Saved on

Key

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

...

  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 де beneficiaries.fallback.systemReason = "Не вдалось отримати інформацію з сервісу"
  6. API_TOKEN зберігається:
    - у захищеному конфігураційному середовищі
    - не логуються
    - не передається у відкритому вигляді

...

HTTP codeRetryЗупинка інтеграціїSlackДія
400НіНі (можливо)Такпомилка запиту
401НіНІТак / auth_errorТакневалідний tokenабо відкликаний API Token
402НіТакТакочікування оплати
403НіНі (можливо)Такперевірка доступу
404НіНіНісуб'єкт відсутній
406НіНі (можливо)Такпомилка формату
429НІТакТакперевищено ліміт
500Так (3 рази)НіНітимчасова помилка
502Так (3 рази)НіНісервіс недоступний

...

  1. Обробка 401

    1. означає невалідний або відкликаний токен

    2. retry НЕ виконується

    3. надсилається Slack alert

    4. статус інтеграції → auth_error

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

...

Назва

Отримання та запис КБВ з ЄДР в award
Актори
  • ЦБД (primary)
  • ЄДР API (external)
Передумови
  • Процедура входить в перелік дозволених (LLE, LLD, …, SUD)
  • Учасник є юридичною особою
    • award.buyers.identifier.scheme = UA-EDR
  • award.status ∈ {pending_waiting, pending_admission, pending}
  • інтеграція має статус active
Основний сценарійАльтернативний сценарій

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

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

  1. Учасник подає заявку
  2. Майданчик активує заявку
  3. Заявка переходить у кваліфікацію
  4. ЦБД створює award
  5. ЦБД перевіряє умови запуску інтеграції
  6. ЦБД виконує авторизацію в ЄДР (отримує JWT токен)формує запит до ЄДР із заголовками:
    1. Authorization: Token {API_TOKEN}
    2. Accept: application/json
  7. ЦБД відправляє запит до ЄДР з code = ЄДРПОУ
  8. ЄДР повертає дані КБВ (може бути список)
  9. ЦБД валідовує відповідь
  10. Дані відповідають моделі beneficiariesGeneralInfo
  11. ЦБД записує дані в award.beneficiaries
  12. Оновлює:
  • award.dateModified
  • procedure.dateModified
  • systemDateModified
Результат

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

...

Назва

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

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

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

Всі retry невдалі → UC4

Результат

1

GivenОтримано
  • або дані записаніабо fallback
Acceptance Criteria
  • 500/502: Slack alert не відправляється на кожну помилку, але відправляється після 3 невдалих retry.
Acceptance Criteria

1

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

When

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

Then

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

2

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

Then

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

...

Назва

Внесення системної помилки
Актори

ЦБД (primary)

Передумови

retry завершився невдачею

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

award містить fallback

...

Назва

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

ЦБД (primary)

Передумови

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

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

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

...

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

USE CASE 11 — Обробка 401

...

Unauthorized

...

при невалідному API Token

Назва

Автоматичне оновлення токена при помилці 401
Актори
  • ЦБД
  • ЄДР
  • Slack
Передумови
  • Запит до ЄДР виконано
  • Отримано 401 Unauthorized
Основний сценарій
  1. ЦБД отримує 401
  2. Визначає, що токен невалідний
  3. НЕ виконує retry
  4. Надсилає Slack alert
  5. Статус інтеграції → auth_error
Результат
  • Інтеграція відновлюється без втручання людини
  • або помилка auth
Acceptance Criteria

1

GivenОтримано 401

When

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

Then

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

2


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

Отримано 401

When

Система фіксує помилку

Then

Запит повторюється 1 раз		Статус інтеграції змінюється на auth_error

3

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

When

Система фіксує помилку

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

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

4



Given

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

When

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

Then

Запит до ЄДР не виконується до заміни/актуалізації API Token


...

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

Назва

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

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

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

...

Назва

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

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

...

Назва

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

1


GivenОтримано 404

Then

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

And

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

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

...

Назва

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

...