IF (full version)

Що таке IF
Блок IF — це інструмент для умовної логіки всередині флоу, який дозволяє автоматично обирати різні гілки сценарію залежно від заданих умов. Він перевіряє значення полів, результати попередніх кроків або відповідей API — і вирішує, що робити далі: передати дані, змінити об’єкт, пропустити дію чи запустити альтернативний маршрут.
IF особливо корисний у складних інтеграціях, де потрібно контролювати потік даних: обробляти лише потрібні записи, реагувати на статуси, відсіювати помилки та розгалужувати логіку. Завдяки цьому IF є ключовим інструментом для побудови розгалужень, гнучкої логіки та динамічних сценаріїв поведінки інтеграції.
Коли використовувати
IF — це блок умовної логіки, який дозволяє виконувати різні дії залежно від того, чи є умова 1 (TRUE) або 0 (FALSE)
IF потрібен для:
- перевірки вхідних даних (чи містить поле значення, чи воно дорівнює очікуваному, чи не порожнє);
- фільтрації даних у циклах або масивах (наприклад, пропускати непотрібні записи);
- розгалуження сценаріїв залежно від статусу, типу, події чи значення поля;
- обробки помилок та нестандартних відповідей API (перевірка error, success, null, кодів статусу);
- модифікації або доповнення об’єкта лише тоді, коли виконуються певні умови;
- перевірки числових і логічних параметрів (сума, кількість, довжина масиву, наявність елементів, відповідність діапазону).
Навігація:
- Розташування та використання блоку IF?
- Які доступні оператори та функції?
- Де прописувати умову та побачити Результат Виконання?
- Приклади використання та комбінації з іншими блоками
4.1. Обробка помилок. IF + Error
4.2. Перевірка заповненості полів для формування булевого типу поля. IF + Object Builder
4.3. Якщо масив пустий — не запускати Loop. IF + Loop: Object/List + Object Builder
4.4. Вивести результат запиту в Output в залежності від формату вводу. IF + Object Builder
4.5. Виконання основного запиту залежить від того, чи буде виконана умова. IF + HTTP
4.6. Налаштування валідації акаунту. IF + HTTP + Set Validation Result
Типові помилки (як уникнути)
FAQ
- Де побачити результат виконання?
- Як перевірити, що масив має елементи?
- Як інвертувати умову (щоб True/False помінялися місцями)?
- Чому моя умова не спрацьовує?
- Як працює IF з null?
Розташування та використання блоку IF?
─────────────────────────────────────────────────────────────-
Блок IF можна використовувати в таких флоу:
Input, Main Action, Output, Account Validation, Request Error, Custom.
Для того щоб додати новий блок, натисніть на + та оберіть IF.
Розташування IF в флоу Main Action

Які доступні оператори та функції?
─────────────────────────────────────────────────────────────-
Всі умови пишуться і можуть бути виконані виключно в режимі EXP(expression), це програмне виконання з логікою, функціями та обчисленням.
У режимі EXP завжди з’являється панель операторів і функцій.
Оператори та функції можна застосовувати у будь-якому полі, де активований режим EXP (Expression). Це дозволяє будувати динамічні та логічні вирази для обчислень або перевірок.
Доступні такі логічні оператори:

Функції доступні наступних типів:
- General Functions
- Math Functions
- Text Functions
- Date and Time Functions
- Array Functions



Більш детально ви можете ознайомитись з усіма операторами та функціями на цій сторінці: Functions & Logical Operators
Де прописувати умову та побачити Результат Виконання?
─────────────────────────────────────────────────────────────-
!!! Зверніть увагу !!!
В ApiX-Drive результат умови IF завжди повертається у вигляді 1 (True) або 0 (False), що дозволяє легко перевіряти стан логіки та передавати його в інші блоки або змінні.
Умова для блоку IF прописується у полі Condition. Саме тут ви задаєте логічний вираз, який система виконує в режимі EXP.
Результатом буде 1 (True) або 0 (False), і від цього залежить, по якій гілці — True чи False — продовжиться виконання сценарію.
Під час вказання умови використовується комбінація: змінних, операторів/функцій, статично прописаних даних, результатів з попередніх блоків, логічних виразів.
В даному прикладі ми перевіряємо чи не пусте введене значення в Input зі статусом , а також чи статус дорівнює paid.

Результат Виконання ви можете побачити в розділі Тест.
Якщо умова виконалась, результат буде 1 і сценарій розгалуження піде по гічці True, якщо умова не виконана, результат буде 0 і піде по гілці False.

Приклади використання та комбінації з іншими блоками
─────────────────────────────────────────────────────────────-
- Обробка помилок. IF + Error
Блок IF дуже активно використовується в окремому флоу Request Error при обробці помилок і комбінується з блоком Error.
Структура відповіді помилкою API від будь якої системи це завжди унікальний випадок, і початок обробки помилок залежить саме від цього. Будь який флоу Request Error починається з блоку IF.
В даному прикладі за допомогою функції ISSET() ми перевіряємо чи існує таке поле як error а також && за допомогою логічного NOT (!) перевіряємо що поле success буде булевим false.
На картинці можна побачити де розташована відповідь від API, Start Error - ARGS_IN - Body

В розділі Тест ви побачите Результат Виконання, в даному випадку у нас умова була виконана і ми отримати 1 (True), тому підемо по гілці True.
Якщо б, наприклад, не існувало поля error і поле success було true , то у нас в результаті був би 0 і ми б пішли по гілці False.

Далі ми перевіряємо чи не пусте !EMPTY() поле error. В даному випадку воно не пусте, тому ми знову ідемо по гілці True. Якщо було б пусте, то пішли б по гілці False і видали помилку, наприклад, "Unknown error API." прописану вручну, тобто це не відповідь від API, це статичний текст який також можна використовувати в Error для різних сценаріїв.

Далі перевіряємо чи не пусте !EMPTY() додаткове поле message з відповіді API. В даному випадку, конкретно в цій відповіді API немає такого поля, тому в Результаті Виконання ми отримаємо 0 і підемо по гілці False.


В блоці Error ми обрали поле error , яке до цього вже перевірили на пустоту в попередніх блоках і точно знаємо що воно не пусте.

В розділі Тест можна побачити як виглядає помилка.

- Перевірка заповненості полів для формування булевого типу поля . IF + Object Builder
Для того щоб в середовищі DEV платформи передавати булеві (true/false) типи даних, необхідно їх конвертувати через функцію TO_BOOL() або через вбудований декоратор.
В нашому прикладі для початку перевіримо чи не пусте !EMPTY() поле absolute_links

В даному випадку воно не пусте, тому ми отримали 1 і йдемо по гілці True. Якщо було б пусте, то пішли б по гілці False до наступних блоків, і нічого не робили.

В блоці Object Builder ми редагуємо існуючу змінну request, застосовуємо дію Set Property і для поля absolute_links ми використовуємо функцію TO_BOOL() для конвертації в булеве значення, а також щоб функція спрацювала, ми перемикаємо режим поля в EXP.

В розділі Тест бачимо Результат Виконання

В запиті HTTP формат цього поля буде виглядати так

- Якщо масив пустий — не запускати Loop.
IF + Loop: Object/List + Object Builder
Припустимо що у нас в Input є множинне поле tags.
Якщо поле множинне, то воно буде масивом.
Нам треба перевірити, якщо масив пустий, то не робити обробку масиву, якщо не пустий, то пройтись циклом по масиву і зафіксувати кожен елемент.(так, ми вирішили застосувати інверсивну логіку, щоб потрапити в гілку False)
Таку перевірку можна зробити різними функціями, наприклад COUNT() або EMPTY() , ми візьмемо для прикладу COUNT() - отримує розмір масиву.
Ми бачимо що в даний момент поле tags містить елементи масиву, а деякі з них навіть порожні.

В Результаті Виконання бачимо 0, ми підемо по гілці False , тому що у нас кількість елементів в масиві більше 0.

В циклі Loop проходимо по множинному полю tags

В блоці Object Builder ми використаємо лайфхак по створенню Глобальної змінної tags через метод редагування існуючого об'єкта. Застосуємо дію Add Value at end if щоб додавати значення в кінець масиву під час проходження циклом при умові (якщо не пусте значення із блоку Loop)

В розділі Тест можете побачити Результат Виконання

Цей патерн дозволяє уникнути помилок і зайвих операцій у флоу, коли API повертає порожній список або коли користувач нічого не заповнив. IF використовується як “захисний бар’єр”: перевіряє, чи є дані для обробки, і лише тоді запускає Loop і подальші дії.
- Вивести результат запиту в Output в залежності від формату вводу. IF + Object Builder
Припустимо у нас є парсер сайту, який у своїй API відповіді видає різну структуру та формат, в залежності від того, що було обрано користувачем в Input. І нам під кожен формат вводу треба прописати окремий сценарій обробки для виводу даних в Output.
Для цього робимо стільки IF скільки форматів в Input, щоб врахувати всі варіанти. Також необхідно буде згенерувати запит з кожним форматом, щоб призначити змінні з відповіді API.
Для прикладу візьмемо 2 різні формати.
Ставимо першу умову, якщо формат вводу == JSON, то ми підемо по гілці True. Якщо формат вводу буде інший, і ми підемо по гілці False, то продовжимо шукати умову яка виконається.

В Object Builder редагуємо існуючу змінну в якій у нас вже містяться інші поля з запиту, і додаємо загальне поле answer для всіх форматів, тому що в даному випадку, за один запит можна вказати лише один формат вводу. Значення цього поля буде змінна з відповіді API , і так як нам треба вивести результат у форматі JSON ми додаємо функцію JSON_ENCODE() , яка кодує об'єкт як JSON, а також щоб функція спрацювала переводимо режим поля в EXP.


В розділі Тест можна побачити Результат Виконання

Ставимо другу умову, якщо
якщо формат вводу == HTML, то ми підемо по гілці True. Якщо формат вводу буде інший, і ми підемо по гілці False, то продовжимо шукати умову яка виконається, як і в попередньому варіанті.

В Object Builder редагуємо існуючу змінну в якій у нас вже містяться інші поля з запиту, і додаємо те саме поле answer для всіх форматів. Значення цього поля буде змінна з відповіді API, яка відповідає цьому формату HTML.
Якщо ви не бачите поля у відповіді під цю умову, згенеруйте дані у Flow Test з необхідним форматом.

В розділі Тест можна побачити Результат Виконання

- Виконання основного запиту залежить від того, чи буде виконана умова. IF + HTTP
В даному прикладі нам треба зробити декілька запитів, де другий запит залежить від результату виконання першого, тому для цього можна скористатись фільтрацією та в блоці IF прописати необхідну умову, яка і буде вирішувати чи виконувати другий запит або ні.
В першому запиті ми отримуємо лімітовану кількість контактів, якщо вони буди знайдені по email, у нас ліміт 1.

Далі в IF ставимо умову, якщо кількість COUNT() контактів в масиві у відповіді API дорівнює 1, тоді ми підемо по гілці True і виконаємо наступний запит на отримання більш детальної інформації про контакт.

З попереднього запиту нам також треба взяти ID знайденого контакта. Далі передаємо необхідну інформацію по знайденому контакту.

- Налаштування валідації акаунту. IF + HTTP + Set Validation Result
Для налаштування валідаціонного флоу треба зробити перевірку вхідних даних на відповідність очікуваним вимогам і правилам. Перед тим як запускати сценарій інтеграції, потрібно переконатися, що:
- API-ключ або токен валідний;
- авторизація пройшла успішно;
- сервіс не повертає помилку «Unauthorized», «Invalid Token» тощо.
Навіщо: щоб інтеграція не впала при першому ж запиті.
В даному прикладі ми використовуємо метод Автентифікації - Bearer.
В залежності від метода Автентифікації налаштування можуть бути різними.
Після того як ви заповнили токен та зберегли його, необхідно справа вгорі натиснути на три риски, і додати Account Validation.

Починаємо з умови IF , якщо не пустий !EMPTY токен, то йдемо по гілці True і можемо робити запит до одного з методів сервіса. Якщо значення токена буде пусте, то підемо у гілку False і в блоці Set Validation Result поставимо 0 і валідація не буде пройдена.
Токен знаходиться тут - Global - ACCOUNT - token

Коли отримали успішну/не успішну відповідь від API та бачимо які є дані та структура, можемо далі робити перевірку.
Так, можна робити валідацію при не успішних статусах: 500, 401, тощо.

Якщо у відповіді API існує ISSSET() data , а також && змінна success буде true, то в цьому випадку валідація пройдена і ми підемо по гілці True і поставимо значення блоку
Set Validation Result = 1.
Якщо умова не буде виконана, і ми підемо по гілці False, тоді в блоці Set Validation Result поставимо 0 і валідація не буде пройдена.


Типові помилки (як уникнути)
─────────────────────────────────────────────────────────────-
- Писати умови в TXT замість EXP
Функцію IF можна використовувати не лише в блоці IF, а і в інших блоках, наприклад, Object Builder, HTTP, та інших.
Для того щоб умова виконалась, треба режим поля перевести із TXT в EXP, будь де, де ви плануєте застосувати будь який оператор або функцію, необхідно перемикати режим.

- Неправильна інверсія логіки
Коли умова написана неправильно, True і False “поміняні місцями”. Наприклад, ви хочете, щоб блок виконувався тільки якщо значення порожнє, але умова насправді спрацьовує, коли воно не порожнє.
Наслідок: Сценарій йде по неправильній гілці (True/False), дії виконуються не так, як очікувалось. Це може призвести до пропуску потрібних дій або обробки неправильних даних.
Як уникнути: Використовуйте дужки для складних умов, при сумніві розбийте складну умову на кілька простих IF-блоків, завжди перевіряйте через Flow Test, щоб переконатися, що гілки True/False спрацьовують правильно.
Якщо треба перевірити чи не пусте поле, використовуйте - !EMPTY()
Виконати блок якщо статус дорівнює paid, а також && сума замовлення не порожнє !EMPTY()

- Не тестувати в Flow Test
Завжди робіть тестові запуски через Flow Test, щоб побачити як відпрацює повний процес. Для цього заповнюйте поля правильними, а також некоректними даними, щоб отримати помилкові умови, натискайте Save і Run Test.
Тестування дозволяє бачити результат виконання кожного блоку, включаючи IF (1 / 0) та гілки, по якій піде сценарій.

FAQ
─────────────────────────────────────────────────────────────-
Як інвертувати умову (щоб True/False помінялися місцями)?
Додайте інверсивну логіку NOT перед виразом або змініть умову порівняння !== 0 / != 0
Чому моя умова не спрацьовує?
Часті причини: поле не існує (null), режим TXT замість EXP, неправильний тип даних змінних.
Як працює IF з null?
У DEV-середовищі ApiX-Drive значення обробляється як "відсутнє значення", і в більшості випадків поводиться як порожній тип. Це важливо для будь-яких умов в IF. null
EMPTY(null) - повертає
1 (True)
COUNT(null) - повертає 0 (False)
{{value}} == "" - поверне
1 (True), якщо value = null
Порівняння null з числами (100, >, <) - завжди 0 (False)
ISSET() - спосіб перевірити, чи поле реально існує у відповіді API