Versions Compared

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 де beneficiaries.fallback.systemReason = "Не вдалось отримати інформацію з сервісу"
  6. API_TOKEN зберігається:
    - у захищеному конфігураційному середовищі
    - не логуються
    - не передається у відкритому вигляді
  7. Порожній результат (200 без даних) НЕ є помилкою API, але вимагає fallback
  8. Асинхронність має пріоритет над статусом award — відповідь завжди обробляється
  9. Timeout прирівнюється до технічної помилки (500/502)

Обмеження

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

...

User Story 4. Обробка випадків, коли дані не знайдені або недоступні

ЯкЦБД Prozorro.Sale
я хочуоректно обробляти випадки, коли ЄДР не повертає дані або повертає пустий результат
щобзабезпечити прозору причину відсутності КБВ у системі

USE CASE 16 — Порожній результат (200, але без даних)

Назва

Суб’єкт не знайдений за кодом ЄДРПОУ (порожній результат)

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

1

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

And

Список результатів порожній

When

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

Then

КБВ не заповнюються

2


Given

Пустий результат

Then

записується systemReason = "Суб’єкт не знайдений за кодом ЄДРПОУ"


...

User Story 5. Узгодженість даних при зміні статусу award

ЯкЦБД Prozorro.Sale
я хочузавершувати обробку запиту до ЄДР навіть якщо статус award змінився
щобуникнути втрати даних через асинхронність

USE CASE 17 — Award змінив статус під час запиту

Назва

Обробка відповіді ЄДР після зміни статусу award

Актори
  • ЦБД
  • ЄДР
Передумови
  • Запит до ЄДР вже відправлений
  • Award змінив статус (наприклад:
    • дискваліфіковано
    • cancelled
    • unsuccessful)
Основний сценарій
  1. ЦБД відправляє запит
  2. Award змінює статус
  3. ЦБД отримує відповідь від ЄДР
  4. НЕ перевіряє актуальний статус award
  5. Обробляє відповідь за стандартною логікою:
    • або запис КБВ
    • або fallback
Результат
  • Дані КБВ (або fallback) збережені незалежно від статусу award
Acceptance Criteria

1


GivenЗапит до ЄДР відправлено

And

Award змінив статус

When

Отримано відповідь

Then

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

And

Дані записуються незалежно від поточного статусу award


...

User Story 6. Обробка timeout

ЯкЦБД Prozorro.Sale
я хочукоректно обробляти timeout від ЄДР
щоб

забезпечити стабільність інтеграції

USE CASE 18 — Timeout від ЄДР

Назва

Обробка перевищення часу очікування відповіді

Актори
  • ЦБД
  • ЄДР
Передумови
  • Запит відправлено
  • Відповідь не отримано в межах timeout (5–10 сек)
Основний сценарій
  1. ЦБД очікує відповідь
  2. Timeout перевищено
  3. ЦБД фіксує помилку
  4. Виконує retry (як для 500/502)
  5. До 3 спроб
Альтернативний сценарій
  • retry успішний → UC1
  • retry неуспішний → fallback
Результат
  • або отримані дані
  • або fallback
Acceptance Criteria

2

записується systemReason = "Суб’єкт не знайдений за кодом ЄДРПОУ"

1


GivenПеревищено timeout

When

Система обробляє запит

Then

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

2


GivenRetry неуспішний

Then

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

Пустий результат

Then


...