Узлы n8n и передача заявки

Контракт заявки задаёт ожидаемые поля, но ещё не показывает, где они преобразуются. Разделим обработку P-001 на узлы n8n. Каждый узел получит понятный вход и выдаст результат для следующего шага. К концу урока будет описана минимальная цепочка: ручной старт, учебная заявка, выбор редакционных полей и подготовленная запись.

Мы продолжаем локальный editorial-intake-lab. Схема и JSON-образцы не импортировались в n8n и не исполнялись. Здесь нет Google Sheets, почтовых действий или токенов сервисов. Панель узла изучаем отдельно от внешнего подключения, чтобы параметры доступа не скрывали основную задачу передачи данных.

Собственные файлы этого шага доступны в архиве fixtures и контрактов серии, папка lesson-03. Это приложения к объяснению, а не готовый экспорт workflow.

Ориентир современного интерфейса — n8n 2.42.6 и официальные документы на 11 октября 2026 года. Версия взята из метаданных опубликованного пакета, а не из запущенного экземпляра. Облачное окружение может обновляться отдельно; архивная иллюстрация ниже относится к 2024 году.

Роль узла в цепочке

Узел выполняет определённую операцию в workflow. Trigger отвечает за начало, преобразующий узел меняет данные, условный выбирает направление, интеграционный обращается к внешнему приложению. Такое деление помогает читать схему, но не является обещанием, что каждый узел относится ровно к одному бытовому названию. Нас интересует его конкретное поведение и договор входа.

Начнём с Manual Trigger, потому что учебные предложения заданы заранее. После него поставим узел с синтетическими данными Fixture P-001. Следующий шаг Select editorial fields оставляет только поля, предусмотренные договором. Последний шаг Prepare record добавляет технический статус prepared. Статус обозначает форму результата, а не согласие редактора с содержанием.

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

Узел	Получает	Выдаёт	Чего не делает
Manual Trigger	Ручной старт	Начало обработки	Не принимает веб-запрос
Fixture P-001	Старт	Событие с заявкой	Не читает аккаунт
Select editorial fields	Событие	Явный набор полей	Не одобряет текст
Prepare record	Заявку	Карточку prepared	Не публикует статью

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

Три части панели узла

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

Панель узла n8n: слева вход, в центре параметры, справа результат. Это пример интерфейса из учебной записи 2024 года; данные демонстрационные. Google Sheets на изображении иллюстрирует расположение панелей. В нашем редакционном процессе внешний источник не подключается, а вход содержит собственную заявку ProfessorWeb.

JSON-представление полезно, когда поля вложены друг в друга. Таблица удобна для сравнения нескольких элементов. Представление схемы помогает увидеть названия и форму полей. Переключение отображения не преобразует сами данные: если proposal вложен в body, табличный вид не переносит его автоматически на верхний уровень. Выражение должно учитывать фактическую структуру входа.

При чтении панели проверьте и выбранный элемент. Одно корректное предложение не подтверждает, что остальные имеют те же поля. В нашем примере P-001 использует тему с пробелами, P-002 — уже нормальную строку, P-003 — неизвестное направление. Различия проявятся в следующих уроках, хотя операция выбора полей должна сохранять их идентификаторы одинаково.

Настройка Edit Fields

Для явного набора выходных полей подходит Edit Fields (Set). В режиме Manual Mapping задаём имена и значения полей. Значение может быть фиксированным или выражением, которое читает текущий вход. Настройка включения исходных полей определяет, сохраняется ли остальная входная информация. Документация Edit Fields описывает эти варианты и работу с вложенными именами.

Предполагаем, что адаптер прошлого урока уже выдал событие с proposal на верхнем уровне. Для id выбираем выражение из proposal.id, для статуса — фиксированную строку prepared. Поле approved задаём фиксированным логическим значением false: внешний автор не получает возможности одобрить собственную статью передачей одноимённого параметра.

id       → {{ $json.proposal.id }}
title    → {{ $json.proposal.title }}
topic    → {{ $json.proposal.topic }}
summary  → {{ $json.proposal.summary }}
status   → prepared
approved → false

Это перечень настроек, а не исполнимый листинг. Выражения читают поля текущего элемента, фиксированные значения создаются нами. Если оставить все входные поля без разбора, на выход могут попасть ненужные заголовки HTTP или дополнительные параметры. Если удалить исходные поля и забыть id, подготовленная карточка потеряет связь с предложением. Явный список требует внимательного сопоставления.

Для самостоятельной настройки начните с пустого workflow. Добавьте Manual Trigger, затем Edit Fields, переименуйте его в Fixture P-001. В режиме JSON Output задайте объект события из прошлого урока: schema_version, event и вложенный proposal. Включение исходных полей здесь не требуется. Соедините выход Manual Trigger со входом Fixture P-001. Пока не выбирайте запуск: мы готовим схему и значения.

Добавьте второй Edit Fields с именем Select editorial fields, режимом Manual Mapping. Укажите строковые поля id, title, topic, summary; значения берутся выражениями из одноимённых полей $json.proposal. Выберите вывод только заданных полей. Соедините Fixture P-001 с этим узлом. Третий Edit Fields назовите Prepare record: сохраните все входные поля и добавьте строковый status: prepared, Boolean approved: false. Соедините Select editorial fields с Prepare record. Это точная цепочка для одной заявки, которую в следующем уроке заменим обработкой трёх items.

Параметры и поведение выполнения

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

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

Также не требуется создавать credentials для каждого узла. Синтетические данные и чистое преобразование могут обходиться без доступа к сервисам. Если интеграционный узел позже попросит credential, это будет отдельная граница полномочий. Она не должна маскироваться под обязательный шаг обучения полям. В этом уроке никакие учётные данные не созданы и никому не переданы.

Ожидаемая карточка P-001

Приложение node-contracts.json описывает четыре узла и поля результата. Карточка пока сохраняет пробелы исходного заголовка и темы: нормализацию мы ещё не добавили. Это осмысленное промежуточное состояние. Если сразу показать идеально очищенный выход, читатель не сможет понять, какая операция ответственна за изменение текста.

После полной настройки читатель может выполнить ручной запуск в своём учебном экземпляре. Ожидается одна карточка: идентификатор P-001, исходный заголовок с внешними пробелами, тема WEB, статус prepared и ложное approved. В панели Prepare record сравните вход с выходом: новые поля добавлены, четыре редакционных поля сохранены. Указанный результат — ориентир самостоятельного рассмотрения, а не наблюдение автора курса.

Сопоставьте каждое выходное поле с настройкой выше. Для идентификатора должен существовать входной путь, для prepared — фиксированное значение, для approved — явно ложное состояние. Ожидаемая карточка не содержит ссылки на опубликованную статью и имени назначенного редактора. Следующий урок введёт несколько items и преобразование полей, сохранив эти границы результата.