Финальная сборка: проверка и экспорт workflow

В предыдущем уроке классификатор научился разбирать текст заявки и направлять её в нужную ветку по смыслу. Теперь всё собрано вместе: нормализация, валидация, классификация, сохранение. Единственный способ убедиться, что цепочка работает как единое целое, а не по частям, — прогнать её на заявках, которые намеренно покрывают каждую из веток.

Четыре типа тестовых заявок и что каждая проверяет

Случайный запуск одной тестовой заявки не даёт никаких гарантий: он проверяет только один путь прохождения данных. Итоговый workflow содержит несколько развилок — узел IF проверяет наличие обязательного поля, Text Classifier разделяет поток на категории, Stop and Error обрывает невалидные заявки. Чтобы убедиться, что каждая из этих веток настроена правильно, нужно осознанно подобрать входные данные под каждый сценарий.

Четыре типа заявок — это не произвольный список, а минимальный набор, при котором каждая ветка цепочки получает хотя бы один прогон.

Обычная заявка — содержит все обязательные поля с корректными значениями, тема не требует срочной обработки. Такая заявка должна пройти нормализацию, успешно пройти валидацию, получить категорию от классификатора и попасть в Data Table. Это базовый «зелёный» путь.

Горячая заявка — тоже валидная, но с текстом, который классификатор должен отнести к приоритетной категории (например, «сервер недоступен уже два часа, клиенты не могут войти»). Проверяет, что ветка «горячих» заявок действительно отделяется от обычных и данные уходят в нужный выход Text Classifier.

Нецелевая заявка — валидная по форме, но тема не входит ни в одну из настроенных категорий (например, запрос о скидке при поддержке по технической части). Проверяет, что классификатор корректно обрабатывает случай «ни одна категория не подошла» и не ломается, а маршрутизирует в ветку по умолчанию или явно помечает заявку.

Некорректная заявка — намеренно содержит пустое или отсутствующее обязательное поле. Проверяет, что узел IF на этапе валидации ловит проблему и передаёт управление в Stop and Error, а не пропускает данные дальше с пустым значением.

Каждый из этих четырёх кейсов нацелен на конкретную развилку. Если пропустить хотя бы один, остаётся непроверенная ветка: она может содержать ошибку в условии, опечатку в имени поля или неподключённый выход — и это выяснится только в продакшене, когда придёт реальная заявка именно этого типа.

Запуск тестов и локализация первого сбойного узла

Когда четыре заявки готовы, их запускают по очереди — каждую отдельным прогоном через «Test workflow». После каждого запуска n8n раскрашивает узлы: зелёный означает успешное выполнение, красный — ошибку или намеренный останов, серый — узел, до которого данные вообще не дошли.

Именно здесь новички делают одну и ту же ошибку: открывают последний узел цепочки, смотрят на пустой Output и начинают разбираться, почему данных нет. Это тупик. Последний узел пуст не потому, что он настроен неверно, — он пуст потому, что предыдущий узел не передал ему ничего.

Правильный рефлекс:

после каждого прогона пробегаем взглядом по цепочке слева направо и ищем первый узел, у которого цвет отличается от зелёного. Именно он — точка входа в диагностику. Всё, что стоит правее и окрашено в серый, серое по одной причине: ошибка выше заблокировала передачу данных.

Важно понимать разницу между красным и серым — они означают разное:

• Красный — узел получил данные и либо столкнулся с ошибкой выполнения, либо намеренно прервал цепочку (как Stop and Error).
• Серый — узел не получил данных вообще: до него просто не дошла очередь.

На практике это выглядит так:

Некорректная заявка с пустым полем. IF вычисляет условие (поле пустое — условие выполнено), успешно направляет item в ветку «невалидно» и остаётся зелёным. Stop and Error получает item и намеренно прерывает выполнение — он окрашивается в красный. Это штатное поведение, не ошибка настройки. Если же Stop and Error оказался серым — значит, IF не передал ему item: проверяем условие в IF и подключение ветки «true»/«false» к нужному выходу.

Горячая заявка. IF зелёный, но один из выходов Text Classifier серый — данные не дошли до узла после него. Значит, смотрим на настройки самого Text Classifier: правильно ли подключена ветка нужной категории.

Если все четыре прогона завершились без неожиданных красных узлов и серые узлы объясняются штатной логикой веток — можно двигаться к исправлению того, что нашлось, или сразу к экспорту.

Итоговый маршрут заявки по полному workflow.

Пошаговое исправление найденной ошибки

Первый красный узел найден. Теперь задача — понять, что именно пошло не так, и исправить это, не трогая остальную цепочку.

Шаг 1. Открыть панель Input сбойного узла в режиме JSON.

Кликаем на проблемный узел и переключаемся на вкладку Input. В правом верхнем углу панели есть переключатель между табличным видом и JSON — выбираем JSON. Здесь видно, какие именно данные поступили в этот узел: какие ключи есть, какие значения они содержат и какие отсутствуют.

Это критический шаг, потому что большинство ошибок — несоответствие между тем, что пришло, и тем, что узел ожидает. Узел обращается к полю description, а в Input пришло Описание с кириллицей и пробелом — и всё, ключ не найден.

Шаг 2. Сравнить имена ключей в Input с именами в настройках узла.

Открываем настройки узла (кнопка редактирования, карандаш) и смотрим, что там указано: в каком expression, в каком поле Input Field, в каком условии IF фигурирует имя поля. Сравниваем с тем, что видели в JSON на шаге 1. Несоответствие чаще всего одно из трёх:

• опечатка в имени поля — descrption вместо description;
• регистр — Email вместо email;
• лишний пробел в имени ключа, который не виден в таблице, но виден в JSON.

Шаг 3. Исправить несоответствие.

Вносим правку прямо в настройках узла. Если проблема в expression — открываем редактор выражения и корректируем имя ключа. Если проблема в условии IF — исправляем строку сравнения. Если ветка Text Classifier не подключена к нужному узлу — проводим соединение вручную.

Не меняем ничего лишнего. Одна ошибка — одно исправление.

Шаг 4. Перезапустить workflow с той же заявкой.

Важно использовать ту же тестовую заявку, которая вызвала сбой, а не другую. Только так можно убедиться, что исправление сработало именно в этом сценарии.

Запускаем «Test workflow» снова. Если узел стал зелёным и данные прошли дальше по цепочке — исправление верное. Если узел снова красный или следующий узел стал серым — значит, либо в узле несколько проблем, либо ошибка оказалась глубже, и нужно повторить шаги 1–3 для нового проблемного места.

После того как все четыре заявки прошли без красных узлов, workflow считается проверенным и готовым к экспорту.

Экспорт рабочего workflow в JSON

Все четыре заявки прошли без красных узлов — workflow проверен. Осталось сохранить его в файл, чтобы передать коллеге, перенести на другую инстанцию n8n или просто зафиксировать рабочую версию.

Экспорт делается из редактора workflow. В правом верхнем углу находится кнопка с тремя точками («...» или «More options») — нажимаем её и выбираем Download (в некоторых версиях n8n этот пункт называется Export). Браузер сохраняет файл с расширением .json.

Что внутри этого файла: полная конфигурация всех узлов, их настройки, соединения между ними и порядок выполнения. Если вы вручную задавали имена категорий в Text Classifier, expression в Edit Fields и условия в IF — всё это окажется в файле. Credentials туда не попадают: только ссылки на них по идентификатору, но не сами ключи и токены. Это нормальное и безопасное поведение — credentials хранятся отдельно в базе n8n и не экспортируются.

Чтобы развернуть этот workflow на другой инстанции, достаточно открыть n8n, перейти на страницу со списком workflow, нажать Import from file и выбрать сохранённый .json. После импорта нужно будет заново привязать credentials — подключить нужные API-ключи заново, например ключ для chat model или другие credentials, которые использовались в цепочке. Структура цепочки при этом восстановится полностью.

Экспортированный файл удобно держать в репозитории или передавать как артефакт: он содержит ровно то состояние workflow, которое вы только что протестировали на всех четырёх сценариях.