はじめに
Healing Agent（以下はHAと略称します）は、UI要素が見つからないといったエラーが発生した際に、提案または自動的に修復してくれるUiPathの新機能です。HAに関する紹介は、UiPath AIエージェント活用ガイド ~ Healing Agentの魅力とは？をご参考ください。
本記事は、トライキャッチのスコープに入ったUI操作が発生した際に、どちらが優先的動作するかについて、検証結果を共有したいです。
検証対象のサイトとサンプルコード
検証用のサイト
今回は、RPAChallengeを使います。
RPAChallengeのフォーム入力画面です。
サンプルコード
First Nameを入力した後、Submitをクリックするサンプルコードを作成しました。検証の目標は、「Submit」のセレクターを「提出」に変更した後、トライキャッチとHAはどちらが先に動作するかということです。
まず、サンプルコードの構成を説明します。
①トライスコープの中で、UI操作と「メッセージをログ」を配置します。「メッセージをログ」は、「エラー回復後の処理です」とログします。UI操作のHAモードは、「ジョブの設定を継承」です。
②「Submit」のセレクターエディターを開き、aanameとcheck:textを「Submit」から「提出」に変更します。
③キャッチスコープは、エラーが発生したら、「エラーがキャッチされました」と出力して終了と設定します。
全体の流れは、下図の通りです。
実行方法
実行方法は、Orchestratorによる無人実行です。
検証結果
ケース１：HAの自己修復をONにする
以下はジョブ起動時のHAモード選択画面です。
このHAモードで実行してみました。ログは以下の通りです。
ログを読んだら、「クリック "Submit"」のところでエラーが発生し、その後はHAが動作して自動修復したように見えます。HA修復後、トライの「メッセージをログ」が実行されて終了したため、キャッチスコープに入りませんでしたね。つまり、エラーが発生していなかったとロボは捉えています。
実行期間は、54.511sであり、もちろんデバッグファイルも出力されました。
ケース２：HAを有効化するが、自己修復をOFFにする
以下はジョブ起動時のHAモード選択画面です。
この設定でジョブを実行しました。
実行ログを下図の通りです。「クリック "Submit"」のところでエラーが発生し、その後はHAは回復分析を開始しました。自己修復をオフにしたため、分析はしてくれたものの、回復はしてくれなかったのです。最後に、エラーはキャッチスコープに入り、「エラーがキャッチされました」が出力されました。
次に、HAのタグを確認したら、デバッグファイルが出力されたため、HAは推奨事項を提供してくれたことがわかりました。
なお、実行期間は55.079sでした。UI操作のTimeoutは既定で30sなので、30sが経ったら要素が見つからない場合は、エラーが出てすぐ終了したはずですが、HAが頑張って分析してくれたので、25sほど実行時間は伸びました。
終わりに
HAは、トライキャッチより優先的に実行されることは今回の実験でわかりました。そのため、意図としてエラーをロボにキャッチさせたいなら、エラーの発生を想定したアクティビティで、HAモードを「無効」にすると良いです。