Таблиця відповідностей n8n: вправа з перевірки даних для API
Створіть таблицю відповідностей n8n, що зберігає дублікати, перевіряє коди й строки дії та спрямовує запропоновані дані для API на перевірку.
Перевірено за наведеними джерелами .
Ваша вправа з таблицею відповідностей n8n
Створіть таблицю відповідностей n8n, яка готує дані для надсилання лише тоді, коли вхідна мітка має рівно один довідковий рядок, дозволений код і відповідність із чинним строком дії. Це редакційна вправа, заснована на задокументованих можливостях: її тестові дані, алгоритм та очікувані результати запропоновані як приклад, без підтвердження виконання чи перевірки.
Використовуйте синтетичні дані у власному середовищі n8n. Вам потрібні Data Tables, дозвіл на створення таблиці та знайомство з JavaScript у вузлах Code і розгалуженням IF. Документація n8n описує Data Tables для пошуку відповідностей у робочих процесах та імпорту CSV, але надана документація не встановлює мінімальної версії чи тарифного плану; перевірте, чи доступна ця функція у вашому середовищі. Таблиці належать до окремих проєктів і призначені для зберігання невеликих та помірних обсягів даних.
Завершіть процес окремими виходами для придатних до надсилання даних і записів на перевірку. Налаштування HTTP, автентифікація, фактичний запис і забезпечення перевірок на стороні призначення виходять за межі вправи. Критерій завершення: кожен вхідний ідентифікатор з’являється рівно один раз з очікуваним результатом, наведеним нижче.
Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub
Підготуйте довідкові рядки та вхідні записи
Створіть CSV із заголовками label, apiCode та expiresAt, точно використовуючи наведені нижче редакційні тестові дані, а потім імпортуйте його в Data Table з назвою reference_codes. Поле apiCode для Blank порожнє; Unknown не має довідкового рядка. Вважайте EXP, ECO, EC2, LEG і BRK набором дозволених кодів цієї вправи; ці вигадані коди нічого не визначають щодо зовнішнього API. Зафіксуйте час оцінювання як 2026-10-22T00:00:00Z.
label,apiCode,expiresAt Express,EXP,2027-01-01T00:00:00Z Economy,ECO,2027-01-01T00:00:00Z Economy,EC2,2027-01-01T00:00:00Z Legacy,LEG,2026-01-01T00:00:00Z Broken,BRK,not-a-date Blank,,2027-01-01T00:00:00Z Boundary,EXP,2026-10-22T00:00:00Z
Використовуйте наведені нижче вхідні записи для вправи з таблицею відповідностей n8n. Зіставляйте мітки точно, з урахуванням регістру та пробілів.
| Ідентифікатор | Мітка |
|---|---|
| r1 | Express |
| r2 | Economy |
| r3 | Legacy |
| r4 | Broken |
| r5 | Unknown |
| r6 | Blank |
| r7 | Boundary |
Отримайте таблицю за допомогою операції Get вузла Data Table з увімкненим Return All. Не змінюйте її протягом отримання: n8n документує можливі неузгодженості, якщо під час посторінкового отримання вносяться зміни. У цьому варіанті передайте отримані вихідні дані робочого процесу до Code.
Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub
Пропоноване рішення: збережіть неоднозначність перед перевіркою строку дії
Використайте таку пропоновану послідовність: Incoming records → Get reference rows → Build index → Evaluate. Зробіть Incoming records вузлом Code, який повертає один елемент із масивом records у json, що містить усі сім об’єктів з ідентифікатором і міткою. Get reference rows отримує всі рядки з непорожньою міткою та ввімкненим Return All. Настанови n8n щодо Code підтримують поєднання довідкових даних з іншим набором даних і повернення елементів робочого процесу як масиву об’єктів { json: ... }.
Запускайте Build index один раз для всіх елементів. Згрупуйте рядки $input.all() за точною міткою в JavaScript Map з назвою index, зберігаючи масиви повних довідкових рядків, і поверніть [{ json: { byLabel: Object.fromEntries(index) } }]. Масив Economy має містити обидва рядки. Запускайте Evaluate один раз для всіх елементів: зчитайте індекс із $input.first().json.byLabel, а початкові записи — з $('Incoming records').first().json.records. Для кожного запису отримуйте кандидатів через byLabel[record.label] ?? []. Перебирайте саме масив records, а не довідкові рядки, щоб Unknown також отримав результат. Ці розібрані приклади показують запропоновані елементи робочого процесу.
| Вхідні дані | Оцінювання | Елемент результату |
|---|---|---|
| r1: Express | Один збіг; EXP дозволений; строк дії спливає після часу оцінювання | {"json":{"identifier":"r1","label":"Express","eligibility":true,"reason":"eligible","payload":{"identifier":"r1","apiCode":"EXP"}}} |
| r2: Economy | Два збіги; відхилити до перевірки коду чи строку дії | {"json":{"identifier":"r2","label":"Economy","eligibility":false,"reason":"ambiguous"}} |
Щодо дат n8n документує, що значення передаються між вузлами як рядки й потребують розбору. У JavaScript використовуйте Luxon DateTime.fromISO з явно заданою часовою зоною UTC, перевіряйте isValid і порівнюйте значення toMillis(). Документація Luxon 3.7.2 описує перевірку коректності та перетворення на часову позначку; вона не встановлює версії, що входить до вашої інсталяції. Явні часові позначки UTC дають змогу не покладатися на інтерпретацію часового поясу робочого процесу.
Ми вважаємо, що неоднозначність заслуговує на окрему причину відхилення: вибір зручного рядка приховує рішення, яке учаснику потрібно розглянути. Дотримуйтеся запропонованого порядку перевірок.
- Згрупуйте довідкові рядки за точною міткою в масиви, зберігаючи кожен дублікат. JavaScript Map може зберігати кожну мітку та її масив.
- Для кожного вхідного запису отримайте відповідні збіги. Поверніть missing, якщо збігів немає, і ambiguous, якщо їх більше одного; припиніть оцінювання цього запису.
- Для єдиного збігу вимагайте, щоб apiCode був рядком, значення якого після видалення крайніх пробілів непорожнє, а початкове значення належить до оголошеного набору дозволених кодів. Інакше поверніть invalid_code.
- Розберіть expiresAt. Поверніть invalid_expiry, якщо розбір некоректний; інакше поверніть expired, якщо його часова позначка менша за часову позначку оцінювання або дорівнює їй.
- Поверніть один елемент { json: result } на кожен вхідний запис. Збережіть його identifier і label, eligibility та reason. Додайте payload з ідентифікатором і зіставленим apiCode лише для придатного запису; інакше не включайте payload та apiCode.
Sources: skills/skills/n8n-code-nodes-official/SKILL.md at main · n8n-io/skills · GitHub, n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon 3.7.2 | Documentation
Спрямуйте результати та перевірте завершення
Налаштуйте IF так, щоб записи з eligibility, що дорівнює true, надходили на вихід даних для надсилання, а всі інші — на перевірку. Комерційний посібник із впровадження Suyash Raj за 2026 рік описує розгалуження IF для коректних і некоректних записів. Для помилок вузлів установіть Stop Workflow — за документацією n8n, це зупиняє виконання. Відхилення за бізнес-правилами все одно потребують явних правил, наведених вище.
Використовуйте Execute step, щоб окремо переглянути результати пошуку відповідностей і валідації. Порівняйте результати з цими редакційними критеріями приймання.
Sources: n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, n8n Data Validation & Cleaning Workflows | Suyash Raj
Поміркуйте над рішенням про відповідність
Якщо результати відрізняються, перевірте кількість отриманих рядків, групування дублікатів, точне написання міток і розібрані значення строку дії. Не додавайте нормалізацію, якщо явно не застосовуєте однакове правило до обох наборів даних.
Поясніть, що станеться, якщо строк дії одного рядка Economy спливе, а інший залишиться чинним. За правилами цієї вправи спочатку підраховуються дублікати, тому відповідність залишається неоднозначною. Потім поясніть, чому вибір першого збігу або підставляння типового коду порушить умови.
На нашу думку, таблиця відповідностей n8n має виявляти невирішені питання до того, як дані пройдуть перевірку перед надсиланням. Ця вправа не забезпечує атомарності з подальшим записом через API та не захищає від змін довідкових даних після пошуку відповідності.
