Skip to content
Complete CDP/
/
/
Workflow Trigger
Last updated

ワークフロートリガー

ワークフロートリガーを使うと、あるワークフローが成功した時に別のワークフローを自動的に起動できます。依存関係はワークフロー定義内で宣言します。

ワークフロートリガーを使用するケース

以下の場合にワークフロートリガーを使用します:

  • 多くの後続ワークフローが同じ先行ワークフローに依存しており (ファンアウト)、後続ワークフローの追加や削除のたびに先行ワークフローを編集したくない場合
  • 先行ワークフローの実行時間が変動するため、後続ワークフローに固定の schedule: を設定すると信頼性が低くなる場合

ワークフロートリガーの定義

ワークフロートリガーによって起動させたいワークフローの定義に trigger: ブロックを追加します。プロジェクトを push するとトリガーが有効になります。先行プロジェクトを先に push してください。後続プロジェクトの push 時に先行プロジェクトの存在が検証されるためです (存在しない場合は Dependent project '{project_name}' not found in trigger config というエラーで失敗します)。

post_load.dig (後続ワークフロー):

trigger:
  attempt>:
  dependent_workflow_name: data_load_wf
  dependent_project_name: data_pipeline

+run_after_load:
  echo>: "data_load_wf finished successfully"

上記の例では、data_pipeline プロジェクト内の data_load_wf ワークフローが成功するたびに、post_load ワークフローが起動します。

設定パラメータ

パラメータ説明
attempt>トリガーの種類。先行ワークフローが成功した時に後続ワークフローを起動します。
dependent_workflow_name先行ワークフローの名前。このワークフローが成功すると後続ワークフローが起動します。
dependent_project_name先行ワークフローを含むプロジェクトの名前。同じアカウント内のプロジェクトを指定します。

例: 複数の後続ワークフローへのファンアウト

1つの先行ワークフローが日次の集計テーブルを構築し、その後に2つの後続ワークフロー (エクスポートと品質チェック) が実行されるケースです。各後続ワークフローが自身の依存関係を宣言するため、後続ワークフローを追加しても先行ワークフローの編集は不要です。

build_aggregate.dig (aggregate_project、先行ワークフロー)

timezone: UTC

schedule:
  daily>: 02:00:00

+build_aggregate:
  td>:
  query: "INSERT INTO daily_aggregate SELECT ... FROM events"

export_aggregate.dig (export_project、後続ワークフロー #1)

trigger:
  attempt>:
  dependent_workflow_name: build_aggregate
  dependent_project_name: aggregate_project

+export_to_s3:
  td_table_export>:
  database: my_db
  table: daily_aggregate
  file_format: csv
  s3_bucket: my-export-bucket
  s3_path_prefix: daily/

check_aggregate.dig (quality_project、後続ワークフロー #2)

trigger:
  attempt>:
  dependent_workflow_name: build_aggregate
  dependent_project_name: aggregate_project

+row_count_check:
  td>:
  query: "SELECT COUNT(*) AS row_count FROM daily_aggregate"

3つのプロジェクトを push すると、build_aggregate ワークフローが成功するたびに export_aggregate ワークフローと check_aggregate ワークフローの両方が自動的に起動します。

制限事項

  • 同じ先行ワークフローに依存できる後続ワークフローの最大数については、Treasure ワークフロー の前提条件と制限事項 を参照してください。
  • 循環依存は許可されません。 プロジェクトを push することで循環が発生する場合 (例: ワークフロー A が B をトリガーし、B が A をトリガーする)、push は Circular trigger config detected. というエラーで失敗します。循環を解消してから push をリトライしてください。
  • 成功したアテンプトのみが後続ワークフローを起動します。失敗、キャンセル、または強制終了されたアテンプトでは起動しません。
  • 現時点では、attempt> のみがサポートされています。

以下のケースでは、トリガーが通知なく停止することがあります:

  • 先行プロジェクトが削除された場合: 後続プロジェクト内の既存のトリガーは自動的に削除されません。同じ名前で先行プロジェクトを再作成してもトリガーは復元されません。新しいプロジェクトは削除されたものとは別物として扱われるためです。トリガーを再作成するには、後続プロジェクトを再 push してください。
  • 先行ワークフローの名前変更または削除: トリガーは先行ワークフローを名前で識別するため、先行プロジェクト内で名前変更または削除するとトリガーは停止します。
  • dependent_workflow_name の誤り: push 時に先行プロジェクトの存在は検証されますが、ワークフロー名は検証されません。

いずれかのプロジェクトに変更を加えた後は、トリガーの設定を確認してください。

ワークフロートリガーに関する通知については、ワークフローのメール通知について を参照してください。

Scheduling workflows

Defining variables