UiPath エラーハンドリングはこうするべき

Last updated on 2020年12月31日

みなさん、こんにちはエピックです。

UiPathで開発する際、エラー対策について気にしたことはありませんか。

私の場合は、UiPathを知ったばかりで好き勝手開発している頃はあまりエラーハンドリングについて気にしていなかったのですが、実際に社内で運用するようになり大変気を使うようになりました。

今回は、そんな経験も踏まえ開発の際に使っているエラーハンドリングの手法について記事にしてみたいと思います。

【追記】

UiPath Go から、AttendedFrameworkというエラーハンドリング、ログ等がフレームワーク化されたテンプレートをダウンロードすることが可能です。

このフレームの存在を私は知らなかったのですが、実際に使ってみて非常に使いやすく標準化をすすめるうえでたいへん役立つものであると感じました。

詳しくは、下記の記事で書いておりますので、フレームワークにご興味ございましたらご参考にしてください。

エラーハンドリングで利用するアクティビティ

エラーハンドリングの際に利用しているアクティビティを紹介します。

トライキャッチ（Try Catch）

エラーハンドリングとなった際に、必ず利用するであろうアクティビティです。

一見、複雑なアクティビティとなっており、「Try」「Catch」「Finally」の３つのブロックから構成されています。

ブロックにおけるそれぞれの役割は次のとおりです。

トライキャッチはエラーハンドリングの基本のアクティビティであり、多用しがちですが一つのワークフロー内にいくつもトライキャッチ配置してしまうと画面上見づらくなってしまう欠点があります。

これについてはこの記事の後半をご参考いただければと思います。

メッセージをログ（Log Message）

指定した文字列をログメッセージとして書き出します。

ログメッセージの重要度が選択できますが、エラーハンドリングのため、基本「Error」「Fatal」から選択すれば問題ありません。

また、このアクティビティはOrchestratorへ接続した際、Orchestratorのログ上でも確認できるためOrchestratorを導入し展開を検討している場合はワークフロー内に含めると良いと思います。

メール送信

エラーが発生した際に、担当へ通知する手段としてメール送信という手段をとることができます。

UiPathでは、メール送信アクティビティが複数あるため導入環境に応じて選択してください。

最も設定が簡単なのは「Outlook メールメッセージを送信」となります。

エラー時点のでキャプチャを取得し、それを添付なんてことも可能です。

メッセージボックス（待機ボックス）

エラーの原因がユーザの操作に起因する場合（ビジネス例外）の場合、正しい利用方法を通知する手段として利用することができます。

実際、業務部門のあまりITに詳しくないユーザーが実行するような環境で混乱を避ける目的で利用することが多いです。

エラーを考慮したワークフローの作成

RPAは、従来のようなシステムを開発・導入するのと比較し、一般に比較的開発ハードルが低いこと・開発期間が短いことなどがメリットとして挙げられています。

これらのRPAのメリットを考慮した場合、ガチガチのシステム開発のような手法を取るのは、個人的な意見としてナンセンスだと考えています。

他方、全くルールなしではそれこそ属人化の塊となり、導入後のケアは大変なものとなるでしょう。

どれだけ簡素化したルールを策定し、かつ開発者間で共有できるかが肝であると考えます。

その構想のベースとなるのが、基盤となるワークフローにはルールを適応し、その中に作成する子のワークフローの開発は自由に行うというものです。

今回のエラーハンドリングについても、この考え方に基づいて下記に記載をしています。

ルールは次のとおりです。

Mainワークフロー（呼び出し元）には具体的な処理は記述しない

パッケージ化したワークフローは、基本設定を変えない限りMainと命名されたワークフローから実行されます。

UiPathを使用し初めて間もない場合は、この中に業務全体の処理を記述してしまうケースが多いですが、その場合個人の開発手法が表に出てしまい属人化を免れません。

そこで、Mainワークフローについては、詳細処理を記述せずワークフロー呼び出し（Invoke Workflow）を利用し、詳細処理を記述した子のワークフローを呼び出すのみとします。

これにより、Mainワークフローは自動化する業務の処理フロー示した手順書のようになり、具体的な処理はそこから呼び出される別のワークフローを参照するようなかたちとなるはずです。

TrCatchのトライブロックでワークフローを呼び出す

TryCatchはエラーを捉えるアクティビティですが、Tryの中に処理を記述しなければならず、すべての処理についてエラーハンドリングを行おうとすると入れ子となり視覚的に非常に見ずらいワークフローとなってしまいます。

そこで、上述のワークフロー呼び出しと併用することでこれを解決するようにします。

tryブロックの中に、ワークフロー呼び出しを配置することで、可視性を損なわず、呼び出すワークフロー内に記述されているすべての処理のエラーハンドリングを行うことが可能となります。

Catchブロックにエラー時の処理を記述する

エラーが発生した場合の処理をCatchに記述します。

Catchの例外の種類ですが、従来のプログラミングのような厳密さはRPAにはナンセンスだと考えていますので、System.Exception以外の選択は、特別な場合を除きまず必要ありません。

開発するワークフローの参考をのせておきますがあくまでも参考なのでこの辺は導入環境・運用に基づき変更してください。

• メッセージログ
• メール送信/ 待機ボックス
• ワークフローを終了

また、メッセージログの出力、メール送信の本文として次のような設定をするとラーが発生したアクティビティおよびその内容を担当者へ伝え、ワークフローの修正へとつなげることが可能となります。。

"エラーアクティビティ名：" + exception.Sorce + Environment.NewLine + Environment.NewLine +"エラー内容：" + exception.Message

まとめ

今回も最後までお読みいただきありがとうございました。

では。