Створіть і налагодьте свій перший робочий процес від тригера до дії в n8n
Посібник для початківців зі створення робочого процесу Manual Trigger → HTTP Request → Edit Fields, зіставлення заголовка з JSON і послідовного пошуку причин неправильного результату у вузлах.
Перевірено за наведеними джерелами .
Мета, передумови й очікуваний результат
У цьому посібнику ви створите невеликий робочий процес із трьох з’єднаних вузлів: Manual Trigger, HTTP Request і Edit Fields. Робочий процес запитає допис 1 у JSONPlaceholder, отримає об’єкт JSON і скопіює його заголовок у вихідні дані кінцевого вузла. Вправа навмисно компактна, щоб ви могли зосередитися на тому, як дані переміщуються між вузлами.
Вам потрібен доступ до середовища n8n. Офіційні матеріали для початківців рекомендують новим користувачам n8n Cloud і зазначають, що доступний безплатний пробний період, хоча ви можете скористатися іншим середовищем, яке вже маєте. Назви елементів інтерфейсу можуть відрізнятися залежно від версії, тому елемент, названий тут Execute Workflow або Test workflow, у вашій інсталяції може мати дещо іншу назву.
Очікуваний кінцевий результат — елемент, створений Edit Fields, який містить поле title, зіставлене з HTTP-відповіді. Не очікуйте в цьому полі конкретного речення: наведений приклад JSONPlaceholder підтверджує структуру відповіді, але скорочує сам заголовок. Перевірте фактичне значення, показане у ваших даних виконання.
Крок 1. Створіть робочий процес і додайте Manual Trigger
У робочому просторі n8n виберіть Start from Scratch, щоб створити робочий процес. За бажанням дайте йому описову назву, наприклад Post title mapping practice. Зрозуміла назва стане в пригоді, коли ви згодом повернетеся, щоб порівняти тестові виконання, але вона не впливає на роботу процесу.
Додайте Manual Trigger як перший вузол. Цей тригер призначений для інтерактивного виконання: вибір Execute Workflow запускає робочий процес вручну. Це зручно для навчальної вправи, оскільки ви контролюєте початок кожного тесту й можете переглянути отримані дані перед зміною наступного вузла. Використовуйте в цьому робочому процесі лише один Manual Trigger.
На цьому етапі виконайте тригер один раз, якщо ваша версія це дозволяє. Тригер може створити небагато корисних даних — це нормально. Тут його завдання полягає в тому, щоб бути свідомо визначеною початковою точкою для наступного запиту.
Крок 2. Налаштуйте запит допису
Додайте вузол HTTP Request після Manual Trigger і переконайтеся, що ці два вузли з’єднані. У параметрах HTTP Request виберіть GET як метод. Вузол має і засіб вибору методу, і поле URL для кінцевої точки.
У полі URL введіть захищений хост JSONPlaceholder — jsonplaceholder.typicode.com, а після нього шлях /posts/1. Корисно розділяти метод і адресу у своєму контрольному списку: GET описує потрібну операцію, а URL вказує на допис 1.
Запустіть вузол HTTP Request разом із попереднім тригером. Залежно від версії n8n ви можете виконати вузол, виконати весь робочий процес або скористатися тестовим елементом із подібною назвою. Важливий результат — свіжі дані виконання запиту, а не точний напис на кнопці.
Крок 3. Перегляньте поточні дані JSON
Перш ніж додавати зіставлення, відкрийте вихідні дані вузла HTTP Request. У документації JSONPlaceholder відповідь для допису 1 описана як об’єкт із полями id, title, body і userId. Переконайтеся, що поточний елемент у ваших вихідних даних містить поле title. Ця перевірка є частиною створення робочого процесу, а не лише фінальним контролем.
Зверніть увагу на різницю між назвами та значеннями полів. Назвою поля має бути title, а його значенням — текст, повернутий під час цього виконання. Оскільки в задокументованому прикладі це значення скорочене, вважайте поточні вихідні дані вузла джерелом істини для вправи зі зіставлення.
Якщо очікуваного об’єкта немає, зупиніться на цьому етапі й не створюйте вираз із пам’яті. Переконайтеся, що Manual Trigger спрацював, вузол HTTP Request також виконався, а ви переглядаєте його поточні вихідні дані. Розв’язати проблему в попередньому вузлі зараз простіше, ніж пізніше діагностувати порожнє зіставлення.
Крок 4. Зіставте заголовок за допомогою Edit Fields
Додайте вузол Edit Fields після HTTP Request. Виберіть режим Manual Mapping, а потім створіть поле для встановлення значення й назвіть його title. Та сама назва у вихідних даних, що й у вхідній властивості, спрощує розуміння цього першого перетворення.
На панелі INPUT знайдіть title в елементі, створеному HTTP Request, і перетягніть його в елемент керування значенням нового поля title. У документації n8n зазначено, що перетягування вхідних даних у параметр створює вираз із посиланням на ці дані. Це краще, ніж вгадувати вираз, адже використовуються дані, які зараз доступні вузлу.
Перегляньте створений вираз перед запуском вузла. Він має посилатися на вхідне значення title, а не на фіксований зразок тексту чи іншу властивість, як-от id або body. Якщо панель INPUT порожня, знову виконайте Manual Trigger і HTTP Request, а потім поверніться до Edit Fields, коли актуальні дані попередніх вузлів стануть доступними.
Крок 5. Виконайте й перевірте весь робочий процес
Запустіть увесь робочий процес із Manual Trigger. Простежте шлях виконання зліва направо: тригер починає запуск, HTTP Request отримує об’єкт допису, а Edit Fields обчислює зіставлення на основі вхідного елемента.
Відкрийте кінцеві вихідні дані Edit Fields і переконайтеся, що вони містять поле title. Порівняйте його значення із заголовком у вихідних даних попереднього вузла HTTP Request. Ці два значення мають відповідати одне одному, оскільки кінцеве поле зіставлене з цією вхідною властивістю.
Ця перевірка підтверджує конкретну мету посібника: дані, отримані через HTTP-відповідь, потрапили до навмисно сформованих кінцевих вихідних даних. Вона не охоплює всі можливі аспекти промислового використання. Робочий процес залишається цілеспрямованим практичним прикладом запитів, перегляду вхідних даних, виразів і зіставлення полів.
Усунення несправностей: перевіряйте кожен вузол послідовно
Якщо кінцевий результат відсутній або неправильний, перевіряйте робочий процес у порядку виконання. Спочатку переконайтеся, що Manual Trigger запустив поточний тест. Потім відкрийте HTTP Request і перевірте, що він успішно виконався, а його поточний елемент JSON містить title. Нарешті відкрийте Edit Fields і перевірте як його вхідні дані INPUT, так і створений вираз.
Якщо HTTP Request не має корисних вихідних даних, перевірте вибраний метод і відтворіть адресу з хосту JSONPlaceholder та шляху /posts/1. Якщо відповідь є, але title відсутній, перегляньте фактичний об’єкт замість припущення, що в цьому конкретному запуску з’явилася задокументована структура.
Якщо HTTP Request містить title, але Edit Fields — ні, перевірте вираз в Expression Editor і переконайтеся, що він посилається на вхідне поле title. Видаліть фіксоване значення-заповнювач і за потреби знову перетягніть title із INPUT. Якщо самі дані INPUT недоступні, повторно запустіть робочий процес або попередні вузли, перш ніж редагувати зіставлення.
Цей послідовний метод звужує місце виникнення проблеми, не припускаючи її причини. Офіційні рекомендації щодо відсутніх даних так само радять проводити ручне тестування, перевіряти виконання попередніх вузлів і контролювати вирази. Назви кнопок можуть відрізнятися у вашій інстальованій версії, але діагностична послідовність залишається незмінною: тригер, дані запиту, вхідні дані зіставлення, вираз і кінцеві вихідні дані.
Наступне практичне завдання
Коли цей робочий процес запрацює, спробуйте повторити вправу з однією із запропонованих варіацій: зіставте і title, і userId, перейменуйте одне вихідне поле або навмисно зверніться до неправильної властивості, а потім діагностуйте результат, перевіряючи кожен вузол. Це редакційні пропозиції для практики, а не перевірені завдання для оцінювання.
Ту саму послідовність можна застосувати й до іншого навчального завдання: запустити робочий процес тригером, отримати структуровані дані, переглянути поточний елемент, перетворити вибрані поля та перевірити кінцеві вихідні дані. Змінюйте по одному елементу за раз, щоб визначити, яка саме зміна вплинула на дані.
