Валідація даних у n8n: вправа перед записом даних компаній
Практикуйте валідацію даних у n8n на синтетичних записах компаній: виявляйте відсутні, порожні й некоректні поля, зберігайте причини відхилення та перевіряйте обидві гілки.

Перевірено за наведеними джерелами .
Завдання з валідації даних у n8n та його межі
У цій редакційній вправі вам пропонується побудувати валідацію даних у n8n, яка спрямовує прийняті записи компаній до межі запису й залишає відхилені записи доступними для виправлення. Використовуйте синтетичні вхідні дані, зберігайте кожен початковий запис і пояснюйте кожне відхилення. Запропонований робочий процес та очікувані результати не були виконані чи перевірені.
Вам потрібні середовище n8n із підтримкою JavaScript у вузлі Code, базові знання JavaScript і доступ до вихідних даних вузлів. Документація n8n описує власні кроки JavaScript і типовий режим Run Once for All Items; надана документація не визначає конкретної редакції чи версії. Якщо ви використовуєте старішу інсталяцію, перевірте підтримку Object.hasOwn() у своєму середовищі виконання.
Зупиніться на контрольній точці, що представляє заплановану межу запису. Налаштування цільової системи та фактичні операції створення чи оновлення виходять за межі вправи. На нашу думку, можливість переглянути причини відхилення така ж важлива, як і формування прийнятих даних.
Sources: n8n-docs/docs/reusable-content/.gitbook/includes/integrations/builtin/core-nodes/code-node.md at main · n8n-io/n8n-docs · GitHub, Object.hasOwn() - JavaScript | MDN
Визначте контракт і синтетичні вхідні дані

Використовуйте такий редакційний контракт: companyName і contactEmail мають існувати, містити рядки, що не дорівнюють null, і залишатися непорожніми після обрізання пробілів на початку та в кінці. contactEmail також має проходити задокументовану в n8n перевірку формату isEmail(). Це правила вправи, а не універсальні вимоги до записів компаній. Перевірка електронної адреси не підтверджує існування поштової скриньки, належність адреси чи можливість доставки; у наданому джерелі не визначено, які саме формати вона приймає.
Підготуйте наведені нижче випадки для валідації даних у n8n. Кожен запис має зазначений caseId; для полів без окремих змін використовуйте companyName = Acme і contactEmail = hello@example.com. Лапки позначають рядкові значення, а null, числа й булеві значення — відповідні типи. Рішення та причини є запропонованими очікуваннями.
| caseId | Зміна відносно базового запису | Рішення | Очікувані причини |
|---|---|---|---|
| C01 | Без змін | Прийняти | Немає |
| C02 | Не додавати companyName | Відхилити | companyName: missing |
| C03 | companyName = null | Відхилити | companyName: empty |
| C04 | companyName = "" | Відхилити | companyName: empty |
| C05 | companyName = " " | Відхилити | companyName: empty |
| C06 | companyName = 42 | Відхилити | companyName: invalid_type |
| C07 | contactEmail = false | Відхилити | contactEmail: invalid_type |
| C08 | contactEmail = "hello" | Відхилити | contactEmail: invalid_email |
| C09 | companyName = " "; contactEmail = "hello" | Відхилити | companyName: empty; contactEmail: invalid_email |
| C10 | companyName = " Acme " | Прийняти | Немає |
| C11 | companyName = 0 | Відхилити | companyName: invalid_type |
Пропонований розв’язок: перевіряйте поля та зберігайте причини
У цій вправі валідація даних у вузлах n8n відокремлює перевірку полів від маршрутизації. Почніть із вузла Code з JavaScript у режимі Run Once for All Items. Прочитайте $input.all() і обробіть кожен елемент, звичайні дані якого містяться в json. Для кожного вхідного елемента поверніть один результат, обгорнутий у json, із полями caseId, original, normalized, validationErrors та isValid; зберігайте метадані валідації поза початковим записом.
Виконуйте запропонований алгоритм для кожного обов’язкового поля. Object.hasOwn() відрізняє відсутню властивість від наявної, зокрема такої, що містить null або undefined. Перевіряйте null окремо, оскільки JavaScript typeof визначає його як об’єкт. Перевіряйте тип рядка перед trim(), який повертає новий рядок, не змінюючи початкового.
- Якщо поле не є власною властивістю об’єкта, додайте для нього причину missing і припиніть перевірку цього поля.
- Якщо його значення дорівнює null або undefined, додайте empty і припиніть перевірку цього поля.
- Якщо його тип не string, додайте invalid_type і припиніть перевірку цього поля.
- Обріжте пробіли на початку та в кінці рядка й збережіть його в normalized; якщо він порожній, додайте empty.
- Перейдіть до іншого обов’язкового поля, щоб одночасні помилки залишалися видимими.
Перевіряйте формат електронної адреси окремим виразом n8n normalized.contactEmail.isEmail(), до якого виконання доходить лише для непорожнього рядка. Передайте результат у завершальний крок JavaScript, який додає contactEmail: invalid_email, якщо результат дорівнює false, а потім визначає isValid за виразом validationErrors.length === 0. Так ви не припускатимете, що допоміжні функції виразів n8n є звичайними методами JavaScript.
Посібник n8n 2026 Production AI Playbook ілюструє використання validationErrors і прапорця isValid для результатів ШІ; ця вправа адаптує такий підхід до записів компаній. На нашу думку, одна точна причина для кожного поля, яке не пройшло перевірку, тут корисніша за каскад із кількох помилок через одне відсутнє значення.
Sources: n8n-docs/docs/reusable-content/.gitbook/includes/integrations/builtin/core-nodes/code-node.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/README.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/understand-n8ns-data-structure.md at main · n8n-io/n8n-docs · GitHub, Object.hasOwn() - JavaScript | MDN, typeof - JavaScript | MDN, String.prototype.trim() - JavaScript | MDN, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/string.md at main · n8n-io/n8n-docs · GitHub, Production AI Playbook: Deterministic Steps & AI Steps – n8n Blog
Маршрутизуйте записи та перевірте завершення
Використовуйте вузол If, щоб порівняти isValid із булевим значенням true. Документація n8n описує умовне розгалуження за допомогою операцій порівняння. Під’єднайте гілку true до контрольної точки, а гілку false — до перегляду; не під’єднуйте перегляд назад до шляху запису. Наведений нижче контрольний список визначає запропоновані критерії завершення вправи з валідації даних у n8n.
Перегляньте вихідні дані обох гілок та історію виконань. Стаття n8n API Contract Testing за 2026 рік рекомендує зберігати історію виконань як доказ перевірки. Цей пробний запуск демонструє лише маршрутизацію; щоб встановити, що до зовнішньої цільової системи нічого не було записано, потрібна окрема перевірка з цільовою системою в тестовому середовищі.
Якщо рішення неочікувані, перевірте написання назв полів, обробку null, перевірки типів перед trim(), порівняння булевих і рядкових значень, збереження caseId та з’єднання гілок. Питання для роздумів: чому наявне значення null відрізняється від відсутнього ключа та які докази обґрунтували б зміну одного з правил відхилення?
Sources: Object.hasOwn() - JavaScript | MDN, typeof - JavaScript | MDN, String.prototype.trim() - JavaScript | MDN, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.if.md at main · n8n-io/n8n-docs · GitHub, API Contract Testing: Prevent Downstream Failures — n8n Blog – n8n Blog


