ワークフロー
ワークフローはプロダクトがあなたの代わりに走らせる自動化です: トリガー、ステップのグラフ、イベントの到着とともに進む実行。下書きと公開は別なので、トラフィックが実行するのは常に誰かが意図して出したバージョンです。
At a glance
- Shape
- A trigger, a graph of steps, published versions
- Triggers
- Manual fire, or a cohort signal
- Operate
fireWorkflow,signalWorkflow,cancelWorkflow- Live updates
workflow.runon the project room- Auth
- Access token; runs execute server-side
- トリガーは手動発火かコホートシグナルです。つまり「誰に」はコホートであり、手書きの条件ではありません。
- ステップはアクション、遅延、分岐、ガード付きジャンプを持ちます。エンジンが拒む グラフは公開前に名指しされます。
- すべての実行は理由を保ちます。待機はシグナルの名を告げ、失敗はエラーを携えます。
仕組み
A definition holds a draft graph and its published versions. The draft is edited freely and saved as it changes; publishing validates the graph and makes that version the one runs execute, so an edit in progress can never leak into traffic. A run advances node by node: actions do work, delays hold, branches choose a case or the otherwise, and a waiting node parks the run until its named signal arrives, from the product or by hand. Runs, their steps and their errors are all kept, which is what the console's runs tab and the Home screen's Needs you list read.
アクセス先
| Surface | Operation |
|---|---|
| REST | None: workflows are authored and operated, not ingested |
| GraphQL | workflowDefinitions, workflowRuns queries · publishWorkflowVersion, fireWorkflow, signalWorkflow, cancelWorkflow mutations |
| Realtime | workflow.run on the project room, as a run advances |
| MCP | prodantix.workflows.list |
例
Bash
curl "https://api.prodantix.com/graphql" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"query": "mutation ($p: String!, $d: String!) { fireWorkflow(projectId: $p, definitionId: $d) { runId } }",
"variables": { "p": "'$PROJECT_ID'", "d": "'$DEFINITION_ID'" }
}'