Передача данных между шагами

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

Ментальная модель

Правило, которое надо держать в голове, простое: каждый шаг при успехе создаёт ровно один выходной объект, и этот объект остаётся доступен до конца запуска.

Пока исполнитель обходит граф, каждый успешный шаг записывает событие step_completed в журнал запуска вместе с полезной нагрузкой на выходе. Эти события не эфемерны — они сохраняются для каждого запуска, и любой более поздний шаг может прочитать их по node ID. Вам не нужно передавать данные из рук в руки от узла к узлу: то, что однажды произведено, остаётся адресуемым.

Это единственная идея, которая объясняет всё остальное на этой странице. Workflow не передают данные по связи как по конвейерной ленте. Связи управляют порядком выполнения; данные живут в истории запуска, доступные любому последующему шагу.

Шаг за шагом

Представим workflow из трёх шагов:

1. Триггер Inbound Webhook получает:

   { "email": "alice@acme.io", "name": "Alice" }

2. HTTP-шаг вызывает API поиска компании по email и возвращает:

   { "company": "Acme Inc.", "industry": "B2B SaaS" }

3. Шаг Google Sheets добавляет строку, содержащую и контактные данные, и результат обогащения.

Что «видит» каждый шаг при запуске:

• HTTP-шаг. Триггер уже завершился. Выход вебхука (email, name) лежит в журнале под node ID триггера. HTTP-шаг читает его, чтобы собрать запрос.
• Шаг Sheets. И выход триггера, и выход HTTP-шага лежат в журнале. Шаг Sheets может в одной строке взять email и name из триггера, а company и industry — из HTTP-шага; ему не нужно идти через HTTP-шаг, чтобы добраться до данных триггера.

Стрелка Webhook → HTTP → Sheets не значит «Sheets видит только выход HTTP». Она значит «Sheets запускается после того, как HTTP завершится». Выходы всех предков по-прежнему на столе.

Обращение к выходам

Если в двух словах, вы ссылаетесь на выход другого шага, записав выражение-шаблон в любом поле инспектора:

• Триггер использует зарезервированное корневое имя: trigger. Внутренне триггер хранится под node ID вроде trigger_1, но вам это неважно — резолвер найдёт его в любом случае.
• Любой другой шаг адресуется по его node ID, который холст присваивает при добавлении узла. Откройте инспектор узла, чтобы увидеть его ID.

Подборщик сопоставления полей в инспекторе сам пишет эти ссылки, так что вручную их набирать нужно редко. Полный синтаксис — разделители, точечные пути, whole-value vs inline, приведение типов, подводные камни — описан в разделе сопоставление полей.

Несколько родителей

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

Ментальная модель та же. Ветвь, которая реально сработала, добавляет свои выходы в журнал; узел уведомления может сослаться на любой выход предка по node ID. Неважно, сколько хопов до предка и в какой ветви он был — если узел отработал и завершился успешно, его выход адресуем.

Одна оговорка: если ветвь была пропущена (например, Condition направил запуск в другую сторону), узлы пропущенной ветви не производят выхода. Ссылки на них разрешаются в undefined.

Внимание: в ближайшем редизайне системных узлов появится явная семантика Merge, которая формализует, как сходящиеся ветви объединяют свои выходы. Пока обращайтесь к предкам по node ID и защищайтесь от случая пропущенной ветви в своих сопоставлениях полей.

Контекст цикла

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

Точная адресация «текущего элемента цикла» и выходов, производимых внутри тела цикла, сейчас активно перепроектируется в рамках более широкой переработки системных узлов. Текущая практика: используйте переменную элемента из узла Loop внутри тела, а за пределами цикла не полагайтесь на тонкие формы поитерационных выходов до появления новой семантики. Если сомневаетесь, оставляйте работу, требующую поэлементных данных, внутри тела цикла, а при необходимости агрегируйте результаты через Code node.

Смотрите также

• Сопоставление полей — точный синтаксис шаблонов и правила приведения
• Обзор конструктора workflow — модель DAG, узлы, связи
• Отладка запусков — как посмотреть, что действительно произвёл каждый шаг