はじめに
- 本記事では、グローバルハンドラーをもちいてエラーが発生した位置情報を取得する方法を紹介します。
- 記事の内容は、個人の見解または確認結果であり、UiPath の公式見解ではありません。
- 製品仕様や参考画像は 23.10 バージョンのもので構成しています。
StudioX のエラーダイアログにある位置情報のコード
StudioX ではグローバルハンドラーが既定でプロジェクトフォルダに組み込まれており、エラーが発生した際に、上図のダイアログが表示されるのは周知のことかとおもいます。
そして、このダイアログのエラーメッセージの末尾にエラーが発生した位置を検索するコードがあるため、Ctrl＋J で問題のアクティビティを検索される方は多いとおもいます。（上図における検索コードは「0100E」）
（例）Ctrl＋J > 「0100E」で検索↓↓
グローバルハンドラーを利用しているプロジェクトでは、エラーが発生した際に 「errorinfo」 というオブジェクトが自動生成されます。
このオブジェクトの 「ActivityInfo」プロパティ に、エラーが発生した位置情報や対象のアクティビティの表示名などが入っています。
Studio でもエラーの発生位置をログしたい
Studio のグローバルハンドラーは、リトライカウントをみてリトライか停止をするだけのシンプルな実装です。
このため、StudioX のハンドラーのエラーダイアログ作成部などを参考に追加実装する必要があります。
以下に、わたしなりに考えた errorinfo.ActivityInfo の有効なログ出力方法を記載します。
まず、errorinfo.ActivityInfo の中身を説明します。
- Id：アクティビティのID
- InstanceId：WF全体の中でアクティビティが出現する位置
- Name：アクティビティの表示名称
- TypeName：アクティビティの正式名称
冒頭に触れたエラー発生位置の検索コードは、次の式でIDの整数部を16進数に読み替えるなどして求めることができます。
String.Join("0", errorInfo.ActivityInfo.Id.Split("."c).[Select](Function(s) Integer.Parse(s).ToString("X2")))
この検索コードだけ出力すれば十分か？
→ 残念ながらNoです
原因は不明ですが、複雑なWFではこの検索コードで必ずしも問題のアクティビティに辿りつける訳ではありません。（※検索コードは取得できるものの、Ctrl＋Jで検索をかけてもヒットしないことがある）
このため、検索コードに加えて 「errorInfo.ActivityInfo.Id」「errorInfo.ActivityInfo.InstanceId」「errorInfo.ActivityInfo.Name」の3つ も出力することをお勧めします。
「Name」はアクティビティの表示名なので、出力した方が良い理由は省略します。
「Id」「InstanceId」の出力を勧める理由
検索コードがなくとも、「Id」と「InstanceId」がわかればおよそ位置を特定できるためです。
手元で動作をみる限り、「Id」をみればシーケンスの深さがわかります。
たとえば、次の場合、「ほげほげアクティビティ」のIdは 1.2 です。（シーケンス1 のIdは 1.1）
シーケンスを増やせば「ほげほげアクティビティ」のIdは 1.3 です。
じゃぁこれはどうなる？ → 「ほげほげアクティビティ」のIdは 1.2 に戻るんです。
このことから、およそネストの深いところにいるのか否かはIdをみればわかります。
InstanceId は、WFの後ろに配置すればするほど番号が上がっていくので、WF全体の中のどの位置にいるのかがわかります。
InstanceId が9番の「テキスト ファイルを読み込み」のエラーを例に説明しますが、Xamlの実装部をEXCELなどにコピーし、DisplayNameでフィルター。インデントとシーケンスのIDをみながらカウントアップしてみていけば、およそ InstanceId の順番ら辺に問題のアクティビティが出現するはずです。
さいごに
いかがでしたでしょうか。無人実行においては、エラー時のリカバリが必要なケースでは TryCatch で括り、例外制御を実装するのがセオリーですが、そういった後処理が不要なロボットであれば、グローバルハンドラーを追加して上で案内した様な検索コードや例外発生位置の情報を出力しておくだけで十分だとおもいます。
例外発生時の情報出力でお悩みの方が居れば是非参考にしていただければとおもいます。
最後までお読みいただきありがとうございますヾ(＠⌒ー⌒＠)ノ
