IKuznetsov: Новая страница: « = Создание sub-workflow = Sub-workflow — это не отдельный тип Workflow, который вы настраиваете при создании, а роль, которую Workflow принимает на себя, когда другой Workflow ссылается на него с помощью действия '''Запустить Workflow'''. Любой live стандартный Workflow может использоватьс...»

2026-10-14T15:28:15Z

Новая страница: « = Создание sub-workflow = Sub-workflow — это не отдельный тип Workflow, который вы настраиваете при создании, а роль, которую Workflow принимает на себя, когда другой Workflow ссылается на него с помощью действия '''Запустить Workflow'''. Любой live стандартный Workflow может использоватьс...»

Новая страница

= Создание sub-workflow =
Sub-workflow — это не отдельный тип Workflow, который вы настраиваете при создании, а роль, которую Workflow принимает на себя, когда другой Workflow ссылается на него с помощью действия '''Запустить Workflow'''. Любой live стандартный Workflow может использоваться как sub-workflow. Конфигурация входных данных и результатов Workflow определяет интерфейс:

* '''Входные данные Workflow''': определяют, какие данные вызывающий Workflow может передать. Внутри sub-workflow задачи получают доступ к этим данным с помощью выражения <code>input()</code>.
* '''Результат Workflow''': определяет, что задача «Запустить Workflow» возвращает вызывающему Workflow в качестве результата. Простые Workflow не могут выступать в роли sub-workflow. Действие «Запустить Workflow» перечисляет только развёрнутые стандартные Workflow.

== Когда использовать sub-workflow ==

* '''Переиспользуемая логика Workflow''': извлеките набор задач в отдельный Workflow, который могут вызывать несколько родительских Workflow. Вы поддерживаете логику в одном месте. Типичные примеры — Workflow маршрутизации уведомлений или общие шаги поиска сущностей.
* '''Длительные операции''': каждое действие в Ключ-АСТРОМ выполняется в бессерверной среде с ограничением в 120 секунд на действие. Sub-workflow выполняется как отдельное выполнение Workflow с собственным тайм-аутом задачи, настраиваемым до 7 дней. Используйте его для операций, которые занимают больше времени, например опроса внешнего API до завершения асинхронной задачи.

== Подготовка входных данных sub-workflow ==
Перед созданием sub-workflow определите, какие данные ему нужны от вызывающей стороны и что он должен вернуть.

* Откройте или создайте Workflow, который хотите использовать как sub-workflow.
* В редакторе Workflow откройте '''Опции'''.
* В разделе '''Входные данные Workflow''' определите ожидаемые входные данные как объект JSON. Это значения по умолчанию; вызывающий Workflow может переопределить или расширить отдельные поля во время вызова.
* В разделе '''Результат Workflow''' определите выражение Jinja, которое вычисляется в объект JSON. Это то, что задача «Запустить Workflow» возвращает в качестве результата.
* Разверните Workflow, чтобы он появился в списке выбора действия «Запустить Workflow».

== Вызов Workflow как sub-workflow ==

* В вызывающем Workflow добавьте задачу и выберите действие '''Запустить Workflow'''.
* В разделе «Запустить Workflow» выберите целевой Workflow из раскрывающегося списка.
* В разделе «Входные данные» укажите JSON для передачи. Он объединяется с входными данными sub-workflow по умолчанию — вам нужно указать только те поля, которые вы хотите переопределить или у которых нет значений по умолчанию. Полную справку по доступным опциям и ограничениям см. в разделе '''Действие «Запустить Workflow»'''.

== Шаблон «триггер и опрос» ==
Некоторые внешние API следуют асинхронному шаблону: вы отправляете запрос для начала операции, а затем опрашиваете конечную точку статуса до завершения операции. Если опрос длится более 120 секунд, это не поместится в одно выполнение действия. Инкапсулируйте всю операцию — её запуск и опрос до завершения — внутри одного sub-workflow. Вызывающему Workflow нужно знать только параметры операции; двухфазный протокол внешнего API остаётся внутри sub-workflow.

=== Создание sub-workflow «триггер и опрос» ===
Создайте новый стандартный Workflow. Установите его триггер в '''По требованию'''. В разделе '''Входные данные Workflow''' определите запрос или тело запроса, описывающее, что должна делать асинхронная операция, например:<pre>{ "query": "" }</pre>Добавьте первую задачу '''Запустить JavaScript''', которая отправляет запрос к внешнему API. Используйте '''SDK''', чтобы прочитать запрос из входных данных Workflow и вернуть идентификатор задачи для задачи опроса:<pre>import { execution } from '@astromkey-sdk/automation-utils';

const ex = await execution();
const { query } = await ex.input();
const job = await submitQuery(query);
return { jobId: job.id };</pre>Добавьте вторую задачу, которая опрашивает конечную точку результатов. Настройте задачу опроса так, чтобы она завершалась в состоянии ошибки, когда результаты ещё не готовы — именно к этому подключается механизм повторных попыток. В задаче '''Запустить JavaScript''' используйте '''SDK''' <code>@astromkey-sdk/automation-utils</code>, чтобы прочитать идентификатор задачи из результата предыдущей задачи, затем выбрасывайте ошибку, пока задача всё ещё выполняется, и возвращайте полезную нагрузку результата после её завершения:<pre>import { execution } from '@astromkey-sdk/automation-utils';

const ex = await execution();
const { jobId } = await ex.result('submit_query');
const job = await fetchJobResult(jobId);
if (job.status !== 'COMPLETED') throw new Error(`Job not ready: ${job.status}`);
return job.result;</pre>В '''Опциях''' задачи опроса включите '''Повтор при ошибке''' с количеством повторных попыток и задержкой, которые вместе покрывают ожидаемую максимальную длительность операции. Вы также можете включить '''Ожидание перед''', чтобы отложить самую первую попытку опроса, если задаче нужно время для запуска. В разделе '''Результат Workflow''' предоставьте полезную нагрузку результата из задачи опроса, чтобы вызывающие стороны получали данные напрямую:<pre><nowiki>{{ result("fetch_results") | to_json }}</nowiki></pre>Разверните sub-workflow.

=== Настройка основного Workflow ===
Добавьте задачу '''Запустить Workflow''' и выберите sub-workflow «триггер и опрос». В разделе '''Входные данные''' передайте запрос, определяющий асинхронную операцию:<pre>{ "query": "fetch logs | filter ..." }</pre>В '''Опциях''' задачи откройте '''Адаптировать тайм-аут''' и установите тайм-аут, соответствующий максимальной ожидаемой длительности операции. Последующие задачи получают полезную нагрузку результата напрямую через <code><nowiki>{{ result("task_name") }}</nowiki></code> (используя фактическое имя задачи, которое вы задали) — без полей статуса, только данные.

== Мониторинг ==
Выполнения sub-workflow отслеживаются как отдельные выполнения Workflow и связаны со своим родителем в обоих направлениях. Подробности о навигации между выполнениями родительского Workflow и sub-workflow в мониторе выполнений и фильтрации списка выполнений см. в разделе '''Мониторинг выполнений sub-workflow'''.

== Просмотр, где Workflow используется как sub-workflow ==
Редактор отображает подсказку, когда Workflow используется как sub-workflow в другом Workflow.

* Выберите '''Используется как sub-workflow > Показать все затронутые Workflow''', чтобы увидеть подробности. Отображаются только доступные вам Workflow. Приватные Workflow не видны в списке.
* Если вы удалите Workflow, который используется как sub-workflow, вам будет представлен список затронутых вызывающих Workflow, чтобы оценить влияние удаления.

Создание sub-workflow - История изменений