UiPath Documentation
maestro
latest
false
Maestro Orchestrate ユーザー ガイド
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。 新しいコンテンツの翻訳は、およそ 1 ~ 2 週間で公開されます。

エラー処理

フローのノードごとのエラー ハンドル - ノードの障害を別のパスにルーティングし、変数を通じてエラーの詳細を公開します。

概要​

Error handling in Flow is a per-node mechanism that lets you control what happens when a node fails during execution. By default, a failed node stops the entire process. You can override this by turning on error handling for the node and connecting its error handle to route failures to a separate path where you inspect and respond to the error.

動作のしくみ​

Every node that supports error handling has an Error handling tab in its properties panel. The Enable error handling toggle on that tab adds an error handle to the node: a second output connector labeled Error, below the main output handle, that activates when the node fails. The majority of nodes support error handling.

接続されたエラー ハンドルを持つノードに障害が発生すると、実行はプロセスを停止するのではなく、エラー パスにルーティングされます。エラーの詳細は、下流のノードで読み取ることができる変数として利用可能になります。

接続されているエラー ハンドルがないノードに障害が発生すると、プロセス全体が直ちに失敗します。エラーは、[実行] パネルの [ インシデント ] タブに表示されます。

HTTP 要求のリトライ​

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

Errors from the vendor system​

Connector nodes and HTTP requests that go through Integration Service fail when the vendor system answers with an error status, meaning anything other than 2xx. The error has the code IntSvcVendorRequestFailed (102021) and a message in the form Received failure from vendor system on API - <url>: HTTP Status: <code> - <vendor message>. The error's status is the vendor's status, so you can branch on it on the error path. A 4xx status isn't retried, and other statuses are.

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

Turning on Enable error handling in the Error handling tab of the properties panel adds the error handle to the node. Connecting the Error handle to another node on the canvas wires the error path. A node without an Error handling tab does not support error handling, so any failure stops the process.

エラー オブジェクト​

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

エラーの種類を識別する、機械判読可能なエラー コードです。

Message​

何が問題だったかについて、人間が判読できる説明です。エラー情報をログに記録したり表示したりする場合に使用します。

詳細​

スタック トレースやサービス固有の情報 (利用可能な場合) など、エラーの詳細な技術的な説明。

カテゴリ​

関連するエラーの種類をグループ化したエラー カテゴリ

ステータス​

エラーに関連付けられた HTTP ステータス コード。HTTP 関連の障害 ( 404 や 500など) に対して設定されます。

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

実際の例​

This example uses an HTTP Request node to call an external API, with a Script node on the error path that returns the failure details.

HTTP 要求ノードがキャンバス上に配置され、ターゲット URL が設定されます。そのエラー ハンドルは スクリプト ノードに接続されています。スクリプト ノードは、エラー オブジェクトを次のように読み取ります。

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

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

パターン​

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

Return error details and continue​

This pattern fits non-critical operations where the workflow should continue even if one step fails. The node's error handle connects to a Script node that returns the error message, then rejoins the main path so execution continues.

// Script node on the error path
return {
  message: "Error raised: " + $vars.step1.error.message,
  result: null // downstream nodes handle a null result
};
// Script node on the error path
return {
  message: "Error raised: " + $vars.step1.error.message,
  result: null // downstream nodes handle a null result
};

制限付きのリトライ​

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

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

このパターンは、人間の注意を必要とする回復不可能なエラーに適合します。エラー パスでは、通知が (HTTP 要求または統合ノードを介して) 送信された後、ステータス Failed と などの説明メッセージとともに [強制終了] ノード$vars.step1.error.message送信され、ワークフローが終了します。

フォールバック値​

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

よくある間違い​

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

このページは役に立ちましたか?

接続

ヘルプ リソース サポート(opens in new window)

学習する UiPath アカデミー(opens in new window)

質問する UiPath フォーラム(opens in new window)

最新情報を取得