エラー処理

ノードの障害をノードのエラー ハンドルを介して別のパスにルーティングする方法と、エラーの詳細を変数を介して公開する方法。

エラー処理はノードごとのメカニズムであり、実行中にノードに障害が発生した場合の処理を制御します。既定では、ノードに障害が発生するとワークフロー全体が停止します。ノードのエラー ハンドルを接続すると、エラーは別のパスにルーティングされ、ワークフローはそこでエラーを検査して対応できます。

動作のしくみ

エラー処理をサポートするすべてのノードには、そのプロパティ パネルに [ エラー処理 ] タブがあります。そのタブの [ エラー処理を有効化 ] トグルを選択すると、ノードにエラー出力ハンドルが追加されます。ノードの右側にあるメイン出力ハンドルの下に [ エラー] というラベルの付いた 2 番目の出力コネクタが追加されます。ノードに障害が発生したときにアクティブになります。ほとんどのノードはエラー処理をサポートしています。

接続されているエラー ハンドルがあるノードに障害が発生すると、実行はワークフローを停止するのではなく、エラー パスをたどります。エラーの詳細は、後のノードが読み取ることができる変数として利用可能になります。

接続されたエラー ハンドルのないノードに障害が発生すると、実行はそのノードで停止します。テスト実行では、エラーはキャンバスの下の [ インシデント ] タブに表示されます。デプロイ済みの実行では、「 リトライとキャンセル 」で説明しているように、リトライまたはキャンセルするまで実行は一時停止します。

HTTP 要求のリトライ

HTTP 要求ノードは、構成可能なリトライをサポートします。リトライが設定されている場合、ノードはエラー ハンドルをトリガーする前に、指定された回数だけ要求を試行します。すべてのリトライが失敗し、エラー ハンドルが接続されている場合、実行はエラー パスをたどります。エラー ハンドルが接続されていない場合、ワークフローは失敗します。

エラー ハンドルを設定する

プロパティ パネルの [エラー処理] タブで [エラー処理を有効化] をオンにすると、ノードにエラー ハンドルが追加されます。エラー ハンドルを キャンバス上の別のノードに接続すると、エラー パスが配線されます。エラー ハンドルのないノードはエラー処理をサポートしていないため、エラーが発生するとワークフローは停止します。

エラー オブジェクト

エラー ハンドルが接続されている場合、ノードに障害が発生すると、エラーの詳細が $vars.<nodeName>.errorとして表示されます。オブジェクトには次のフィールドがあります。

• code: エラーの種類を識別する、機械判読可能なコードです。
• message: 何が問題だったかについて人間が判読できる説明です。ログを記録したりユーザーに表示したりするのに適しています。
• detail: スタック トレース (エラーの原因となった呼び出しのリスト) やサービス固有の情報 (利用可能な場合) を含む、エラーの技術的な説明。
• category: 関連するエラーの種類をグループ化したエラー カテゴリです。
• status: エラーに属する HTTP ステータス コードです (例: 404 、 500)。HTTP 関連の障害に対して入力されます。

エラー オブジェクトは、エラー パスでのみ使用できます。成功パスで $vars.<nodeName>.error にアクセスすると、undefined が返されます。

実際の例

この例では、HTTP 要求ノードを使用して外部 API を呼び出し、エラー パス上にスクリプト ノードがログに記録されます。[HTTP 要求] ノードはターゲット URL で構成されます。そのエラー ハンドルは スクリプト ノードに接続されています。スクリプト ノードは、エラー オブジェクトを次のように読み取ります。

const error = $vars.httpRequest1.error;
return {
  failed: true,
  reason: error.message,
  httpStatus: error.status,
  detail: error.detail
};

HTTP 要求が成功した場合、実行は成功パスをたどり、スクリプト ノードはスキップされます。要求が失敗した場合、設定したリトライの後、実行はスクリプト ノードまでのエラー パスをたどり、スクリプト ノードは完全なエラー オブジェクトを受け取ります。

実行に成功すると、成功パスが実行され、エラー パスはスキップされます。

実行に失敗すると、代わりにエラー パスが実行されます。

パターン

これらは、エラーを処理、ログ記録、リトライ、エスカレーションするための一般的なアプローチです。これらはすべて、上記のノードごとのエラー ハンドルに基づいて構築されます。接続されたエラー ハンドルは、失敗を別のパスにルーティングし、エラー オブジェクトは で $vars.<node>.error利用できます。

ログに記録して続行

このパターンは、1 つのステップが失敗してもワークフローを続行する必要がある、重要ではない操作に適しています。ノードのエラー ハンドルは、エラーをログに記録する スクリプト ノードに接続し、その後メイン パスに再結合して実行を続行します。

// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully

制限付きのリトライ

このパターンは、ネットワークのタイムアウト、レート制限、サービスの停止など、一時的なものと考えられる障害に適しています。HTTP 要求ノードでは、組み込みのリトライ カウントにより、エラー ハンドルをトリガーする前に要求が再試行され、最後の失敗のみがエラー パスにルーティングされます。リトライの設定は、べき等操作にのみ属します。

アラートを発注して強制終了

このパターンは、人間の注意を必要とする回復不可能なエラーに適合します。エラー パスでは、HTTP 要求ノードまたは統合ノードを介して通知が送信され、その後 [強制終了 ] ノードによってワークフローが終了し、出力変数には $vars.step1.error.message( など) が表示されます。

フォールバック値

このパターンは、失敗する可能性があるものの、ワークフローを有意義に続行できる安全な既定値を持つ操作に適しています。エラー パスで、 スクリプト ノードは期待される出力を既定値に設定し、操作が成功したかのようにメイン パスに再結合します。

よくある間違い

• エラーをサイレントに飲み込む: ワークフローを続行する場合でも、エラー パス上のエラーを常にログに記録する必要があります。サイレント障害は後で診断するのが困難です。
• 安全に繰り返すことができない操作を再試行する: データの書き込みやメッセージの送信など、副作用のある操作をリトライすると重複が発生する可能性があります。リトライの設定は、重複を作成することなく複数回実行できる操作にのみ属します。
• エラー ハンドルを未接続のままにしておく: エラー ハンドルが接続されていないノードは、エラーでワークフロー全体が失敗します。失敗を過ぎても続行する必要があるワークフローには、接続されたエラー パスが必要です。

次のステップ

• エラーを処理: エラー パスを構築するステップバイステップのタスクです。
• フロー キャンバス: ワークスペース (キャンバスの下のパネルを含む)。
• 変数とデータ フロー: $varsを使用してノード間でデータを渡す方法
• デバッグの基本: デバッグ実行中にエラーを検査するためのヒントです。
• コミュニティ: UiPath フォーラムで質問したり、他のビルダーとワークフローを共有したりできます。