Тестовый запуск

Тестовый запуск помогает проверить текущий сценарий до публикации. Он может использовать несохраненные изменения из визуального редактора и не делает их опубликованной версией.

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

• Откройте автоматизацию в визуальном редакторе.
• Исправьте блокирующие ошибки проверки, если они есть.
• Подготовьте пример входных данных, если сценарий их требует.
• Если сценарий использует {{ variables.ИМЯ }}, создайте ключ в разделе Переменные именно для выбранного окружения.

1. Откройте панель тестовых данных.
2. Укажите пример входных данных или используйте сгенерированный пример.
3. Нажмите запуск.
4. Следите за статусами узлов на схеме.
5. Выберите узел, чтобы увидеть его параметры, доступные входные данные и вывод последнего теста.
6. Чтобы проверить только путь до выбранного узла, запустите его из детального просмотра. Будут выполнены сам узел и только связанные шаги, от которых он зависит; шаги после него не запустятся.
7. В параметрах узла нажмите fx или перетащите источник из раздела Данные, чтобы вставить доступное поле. Поиск источника находит шаги и их поля.
8. Сохраните черновик и запустите проверку.
9. Если проверка прошла успешно, опубликуйте автоматизацию или откройте общий вывод и логи, если нужно сравнить несколько шагов.

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

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

Вставка данных показывает только доступные источники для выбранного узла. Узлы, которые выполняются позже или не связаны с текущей веткой, не предлагаются. Значения секретов и подключений не раскрываются: редактор показывает безопасные ссылки и скрывает чувствительные preview-значения.

В группе Переменные редактор показывает имена ключей из выбранного окружения и ключи, созданные предыдущими узлами Задать переменные. Значения project Variables в браузер не передаются: {{ variables.TELEGRAM_CHAT_ID }} будет вычислено на сервере только во время запуска. Если ключа нет в выбранном окружении, поле подсветится как ошибочное. Переменная из предыдущего узла с тем же именем имеет приоритет.

Фрагменты формул внутри {{ ... }} подсвечиваются прямо в текстовых, JSON-полях, условиях Switch и чате агента. Обычный текст остаётся нейтральным, а некорректное выражение в парных скобках получает предупреждающий цвет; подсветка не меняет сохранённое значение. Под полем показан короткий предпросмотр. Раскройте его, если нужен большой редактор и подробности ссылки.

Если выражение в поле ссылается на неизвестный источник данных или старый формат вставки, проверка покажет предупреждение или ошибку до публикации. Выберите источник через Данные заново или замените выражение на подсказанное редактором.

payload хранит исходные данные запуска на протяжении всего сценария. input содержит результат предыдущего шага и меняется при переходе: после HTTP-запроса это ответ сервиса, после условия — результат проверки и выбранная ветка. Чтобы сохранить номер заявки после этих шагов, используйте {{ payload.leadId }}, если поле запуска называется leadId. Проверка отклоняет обращение к полю, которого нет в известном результате непосредственно предыдущего шага.

Если значение состоит только из ссылки, например {{ payload.amount }}, оно сохраняет исходный тип данных: число остаётся числом, а логическое false выбирает ветку «Нет» в условии. Если добавить обычный текст вокруг ссылки, например Сумма: {{ payload.amount }}, результат будет строкой. Узел «Шаблон» всегда формирует текст.

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

HTTP-шаги обращаются только к публичным сервисам. Локальные адреса, внутренняя сеть и служебные адреса инфраструктуры недоступны. HTTP-шаг не следует перенаправлениям автоматически; укажите конечный публичный адрес сервиса.

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

В шаге «Сохранить данные» выберите операцию. «Создать запись» используется по умолчанию и добавляет новую строку. Если ключ уже занят, исправьте входные данные или выберите обновление.

Для операции «Обновить запись» укажите таблицу, первичный ключ существующей строки и значения изменяемых полей. Первичный ключ — объект; для составного ключа нужны все его поля. Не включайте поля ключа в «Значения». Этот режим не создаёт новую строку, если нужной записи нет.

Если приложение передаёт обновление после согласования, в конфигурации узла можно указать expectedRevision из исходной записи Data. Например, expectedRevision: "{{input.originalRevision}}" использует версию, сохранённую сервером до согласования. Проверка выполняется при записи: изменённая или удалённая строка вызовет конфликт, сохранив чужие правки. Для создания записи и произвольных запросов эта настройка не применяется.

Создание и обновление могут запускать автоматизации по изменению данных. Если сценарий обновляет строку, за которой сам следит, добавьте условие в начале: поле «Обработано» ещё не отмечено. В том же обновлении измените статус и отметьте «Обработано». Следующее событие завершится без повторной записи. Проверьте это в Dev по результату строки и истории запусков.

Выберите GET, POST, PUT, PATCH, DELETE, HEAD или OPTIONS. Добавьте параметры URL и обычные заголовки как JSON-объекты; значения можно связать с данными предыдущих шагов через редактор выражений. Авторизацию задайте сохранённым подключением HTTP API, а не секретом в параметрах ноды.

Для POST выберите формат тела: входные данные, JSON, текст или форма с кодированием URL. «Без тела» отключает отправку данных; GET и HEAD всегда отправляются без тела. Таймаут по умолчанию — 30000 мс, допустимо 100–120000 мс. Максимальный размер запроса и ответа — 2 МиБ. Перенаправления не выполняются.

Новая нода считает ответы вне 2xx ошибкой. Эту настройку можно выключить, чтобы самостоятельно обработать HTTP-статус в следующих шагах. У ранее созданных нод сохраняется прежняя обработка всех статусов до изменения этой настройки. Ответ содержит status, headers и data; секреты и чувствительные заголовки маскируются перед сохранением результата. Для кода ответа используйте выражение steps.<имя шага>.output.status. Поля statusCode на этом уровне нет: проверка графа покажет ошибку и подскажет правильное поле. Если запрос завершился ошибкой и вы настроили её обработку, полученный HTTP-код доступен в steps.<имя шага>.output.error.status; при сетевом сбое кода может не быть.

Настроенные повторы применяются к таймаутам и временным сетевым сбоям. Если ответы вне 2xx считаются ошибкой, также повторяются 408, 429 и 5xx. Ошибки 400/401/403 и неверные параметры не повторяются; отдельный список исключений задавать не нужно. Для POST с повторными попытками включите «Отправлять ключ идемпотентности», если ваш API поддерживает заголовок Idempotency-Key: ключ будет одинаковым для попыток одного шага. Сам сервер должен использовать его для защиты от повторной отправки напоминания.

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

Чтобы ошибка AI или проверки переводила обращение на ручную обработку, включите обработку ошибок у обоих шагов и соедините их выходы «Ошибка» с этой веткой. Одна связь без включённой обработки не выполняется: проверка графа покажет ошибку до создания автоматизации агентом или её публикации. Сначала проверьте правильный ответ, повреждённый JSON и недоступность AI; каждый запуск должен создавать только одну запись в выбранной ветке.