Request Error Flow

Глобальна обробка помилок HTTP-запитів

Request Error — це механізм захисту інтеграції від збоїв та некоректної поведінки зовнішніх API. Request Error Flow відповідає за обробку помилок, що виникають під час виконання HTTP Request у будь-якому з основних флоу (Authentication, Input, Main Action, Output).

Навігація

1. Як працює Request Error Flow
2. Як додати та активувати Flow
3. Зв’язок з HTTP Request
4. Доступні дані для аналізу та обробки помилок
5. Обробка нестандартних відповідей (Fake 200)
6. Приклади використання Request Error
7. Ключові принципи роботи
8. FAQ

Як працює Request Error Flow

─────────────────────────────────────────────────────────────-

Цей потік активується автоматично, якщо HTTP-запит завершується невдало. Він діє як «запобіжник», який перехоплює управління у разі виникнення:

• Помилок сервера або клієнта (статуси 4xx, 5xx).
• Технічних збоїв (тайм-аути, розрив з'єднання).
• Логічних помилок API, які ви визначили як критичні.

Головна перевага — ізоляція помилки. Ви можете налаштувати різні сценарії обробки для різних типів запитів, що робить вашу інтеграцію стійкою до зовнішніх збоїв.

Як додати та активувати Flow

─────────────────────────────────────────────────────────────-

Request Error не є частиною основної лінійної схеми, він знаходиться у бічній панелі керування:

1 -> Відкриває бічну панель: основна навігація по всім доступним потокам інтеграції.

2 -> Кнопка Add Flow: дозволяє додати новий потік. Оберіть тип Error зі списку. Ви можете створити кілька таких потоків, якщо для різних запитів потрібна різна логіка обробки помилок.

3 -> Error: назва потоку, що з’являється після додавання. Натисніть на нього, щоб перейти до налаштування блоків.

4 -> Перемикач увімкнення/вимкнення: активує або деактивує цей конкретний потік обробки. Якщо увімкнено, то в HTTP Request в полі Error Flow він буде доступний. Якщо вимкнено, в полі Error Flow ви його не побачите у списку.

Зв’язок з HTTP Request

─────────────────────────────────────────────────────────────-

Request Error Flow не працює сам по собі — він має бути чітко призначений конкретному блоку HTTP Request.

В налаштуваннях блоку HTTP Request у розділі Setiings знаходиться поле Error Flow:

• Оберіть зі списку створений вами Error Flow.
• Якщо поле залишене порожнім, при виникненні помилки сценарій просто зупиниться або видасть технічну помилку без обробки.
• Ви можете використовувати один спільний Error Flow для всіх запитів або створити окремі під специфічні задачі.

Візуалізація в Логах 

Коли Error Flow підключено, у журналі виконання (Log) з'являється окрема гілка структури Request Error. Там можна детально побачити, який саме HTTP Request зламався, який Error Flow був викликаний, як саме відпрацювала логіка обробки помилки та які дані були отримані від API у момент збою.

Доступні дані для аналізу та обробки помилок

─────────────────────────────────────────────────────────────-

Всередині Request Error Flow ви маєте доступ до повного контексту невдалого запиту, що дозволяє гнучко налаштувати логіки.

Головний шлях Start Errors - ARGS_IN:

1 -> HTTP Status Code: цифровий код відповіді (наприклад, 401, 404, 500).

2 -> Response Body: тіло відповіді від сервера (часто містить опис причини помилки у форматі JSON).

3 -> Response Headers: заголовки відповіді сервера (якщо вони були отримані).

Також може міститись технічна інформація про системні збої (timeout, connection error).

Обробка нестандартних відповідей (Fake 200)

─────────────────────────────────────────────────────────────-

Деякі API побудовані так, що вони завжди повертають статус 200 OK, навіть якщо операція не вдалася, а опис помилки передають всередині JSON  (наприклад: { "status": "error", "message": "Invalid token"} ).

Як правильно обробляти такі випадки: Не покладайтеся лише на код статусу відповіді. Використовуйте комбіновані умови з перевіркою інших полів. (Наприклад: Status Code == 200 && ISSET(body.errors) )

Приклад:

Такий підхід дозволяє ідентифікувати реальну помилку, навіть якщо сервер формально відповів «успішно».

Приклади використання Request Error

─────────────────────────────────────────────────────────────-

Проста обробка помилок

З використанням блоків IF та Error, де у відповіді АПІ отримуємо лише текст і можна відразу його відобразити.

Складна обробка помилок

Ви також можете використовувати інші блоки, якщо вам необхідно обробити декілька помилок, якщо відповідь АПІ надіслав масив помилок, наприклад за допомогою блоків Loop: Object/List та Object Builder.

Ключові принципи роботи

─────────────────────────────────────────────────────────────-

• Превентивність: Завжди вказуйте Error Flow для кожного критичного HTTP-запиту.
• Відокремленість: Request Error не змішується з основною логікою.
• Гнучкість: Створюйте різні Request Error для різних задач (наприклад, один для логування помилок авторизації, інший — для обробки помилок створення сутностей).
• Відсутність зупинки: Правильно налаштований Request Error дозволяє інтеграції продовжувати роботу або коректно завершити сесію, не «ламаючи» весь процес.

FAQ

─────────────────────────────────────────────────────────────-

1. Чи можна підключити один Request Error до всіх HTTP-запитів?
Так, це зручно, якщо логіка обробки помилок однакова для всієї інтеграції.

2. Як побачити, що саме пішло не так всередині Request Error?
Використовуйте кнопку Log, там відображається повний шлях виконання запиту, включаючи дані, що потрапили в потік помилок.

3. Чи можна в самому Error Flow користуватись іншими блоками?
Так, ви можете використовувати більшість блоків всередині Error Flow, наприклад, якщо прийшов масив помилок, і вам необхідно циклічно їх обробити.

Що далі?

─────────────────────────────────────────────────────────────-

Ви налаштували Request Error Flow — тепер інтеграція коректно обробляє помилки запитів і повертає зрозумілі повідомлення замість “тихих” збоїв.

Наступний крок налаштування (опціонально):
Custom Flow →
На цьому етапі ви можете додати власні допоміжні сценарії або розширену логіку, специфічну для вашої інтеграції.

Попередній крок:
← Output Flow