レッスン6：回復力のあるワークフローをエンドツーエンドで構築する

imgimgimgimgimg
このレッスンのロックを解除するには、まず「レッスン5：エラー処理戦略とエラートリガー」を完了してください。前のレッスンに戻る

はじめに

このコースのここまでで、IFおよびSwitchノードによる分岐、アイテム分割とバッチ処理によるループ、並列ブランチのマージ、そしてリスクのある操作をエラーハンドリングでラップする方法を学びました。この最後のレッスンは、それらすべてをまとめて、本番の自動化が実際にどのように構築されるかを反映した単一のワークフローにまとめることがテーマです。

目標は新しいノードを導入することではありません。目標は、これらのパターンがどのように組み合わさるかを示すことです——ループがMergeにどうつながるか、エラーハンドラーがループをどうラップするか、分岐ロジックがマージされた結果の次の経路をどう決定するか。ここで構築するワークフローは、あなたの自身のユースケースに合わせて適応できる、実用的なテンプレートです。

シナリオ：外部APIから連絡先リストを読み込み、各連絡先を2つ目のAPI呼び出しでエンリッチし、失敗を適切に処理し、結果をマージし、要約レポートをメールで送信するワークフローです。

エンドツーエンドのワークフロー図は、5つのステージを順に示しています：連絡先取得 → ループ＋エンリッチ（エラーブランチ付き） → 結果マージ → 成功/一部失敗/失敗による分岐 → レポート送信

ステージ1：入力データの取得と分割

ワークフローは、毎朝起動するスケジュールトリガーから始まります。最初のHTTP Requestノードが連絡先APIを呼び出し、連絡先のオブジェクト配列を返します。n8nはデフォルトでこれを単一アイテムにラップするため、ループ処理の前に配列を分割する必要があります。

配列を分割して、ワークフローの残りの部分が一度に1つずつ処理できる個別アイテムにするには、Codeノードを使用します：

javascript
return $input.first().json.contacts.map(contact => ({ json: contact }));

これが基礎となります。ここから下流のすべてのノードが1アイテムにつき1連絡先を受け取るため、SplitInBatchesを使ったループ処理や、アイテム単位の直接HTTP呼び出しが正しく動作します。

ステージ2：エラーハンドリング付きでの各連絡先のエンリッチ

エンリッチステップでは、各連絡先に対してサードパーティAPIを呼び出します。サードパーティAPIは失敗します。レート制限、タイムアウト、予期しない形のレスポンスが発生します。本番環境では、この呼び出しをTry/Catchパターンでラップすることが必須です。

HTTP Requestノード（エンリッチ呼び出し）を、そのノードにスコープされたError Triggerに接続します。成功パスはエンリッチされたデータをアイテムに追加します。エラーパスはfallback構造を追加し、アイテムが暗黙的にドロップされないようにします：

javascript
// On the error branch — Code node that normalizes the failed item
return [{
  json: {
    ...($input.first().json),
    enriched: false,
    enrichmentError: $input.first().json.error?.message ?? 'Unknown error'
  }
}];

成功パスとエラーパスの両方が、同じトップレベル形状のアイテムを生成する必要があります。これは次のマージステップにとって極めて重要です——一方のブランチが異なるキーを持つオブジェクトを返した場合、下流のノードが脆くなります。

HTTP Requestノードが2つのパスに分岐するフローチャート：成功パスはエンリッチデータを追加し、エラーパスはフォールバックフィールドを追加し、両方のパスはMergeノードで合流する

ステージ3：結果のマージと集約

エンリッチステップ（成功ブランチとエラーブランチの両方）の後、AppendモードのMergeノードがすべてのアイテムを単一ストリームに集約します。そこから、Codeノードが結果を集約して要約オブジェクトを作成します：

javascript
const items = $input.all();
const total = items.length;
const succeeded = items.filter(i => i.json.enriched !== false).length;
const failed = items.filter(i => i.json.enriched === false).length;


return [{
  json: {
    total,
    succeeded,
    failed,
    failureRate: (failed / total * 100).toFixed(1) + '%',
    items: items.map(i => i.json)
  }
}];

この集約ノードは、アイテム単位の処理とワークフローレベルのロジックの境界となります。これより前はすべて個別の連絡先を処理します。これより後はすべてバッチ全体を処理します。

ステージ4：結果による分岐

すべての実行が同じ通知を生成するべきではありません。失敗率0%にはクリーンな成功メールが必要です。失敗率100%は即座に誰かにページを送るべきです。一部失敗はその中間に位置します。

失敗率に基づいてルーティングするには、IFまたはSwitchノードを使用します：

javascript
// Switch node — Expression for routing
{{ $json.failed === 0 ? 'success' : $json.succeeded === 0 ? 'critical' : 'partial' }}

各ブランチは異なる通知ノードに接続されます——成功と一部失敗にはメール、致命的（critical）にはSlackやPagerDuty。ここで、以前のレッスンで学んだ分岐とマージが活きてきます：クリーンな単一アイテム要約を生成する能力を、まさにこのSwitchノードがシンプルな評価対象を持てるようにするために構築したのです。

ステージ5：レポートの送信

各通知ブランチは独自のメッセージをフォーマットします。成功ブランチは短い確認を送信します。一部失敗ブランチは失敗した連絡先のリストを含め、誰かが調査できるようにします。criticalブランチは完全なエラー詳細を含む緊急アラートを発火します。

一部失敗ブランチのメールノードは、本文を動的に構築するために式を使用します：

javascript
// Code node before the email — builds the failure list
const failures = $json.items
  .filter(i => i.enriched === false)
  .map(i => `${i.email}: ${i.enrichmentError}`)
  .join('\n');


return [{ json: { ...$json, failureList: failures } }];

この時点でワークフローは完成しています。トリガー、エラーハンドリング付きのアイテム単位処理、結果マージ、結果ベースの分岐、そしてターゲティングされた通知を備えています。

まとめ

本番-readyなワークフローは、正常系をうまく処理するワークフローではありません——データを失うことなく失敗を処理し、ロジックを重複させることなく分岐し、自身の健全性を報告するワークフローです。ここで適用したパターン——ループ前の分割、エラーブランチの正規化、分岐前の集約、結果による分岐——は、n8nで構築するほぼすべての自動化のための反復可能な構成要素です。このワークフローをリファレンステンプレートとして使用し、ステージを自身のデータソース、API、通知チャネルに適応させてください。

レッスンの練習

レッスンのチェックポイント

学んだ内容を復習し、回答へのフィードバックを受けましょう。

0/1
回答済み · 0/1