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

Last updated on 2020年6月20日

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

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

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

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

【追記】

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

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

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

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

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

トライキャッチ（Try Catch）

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

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

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

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

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

メッセージログ（Log Message）

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

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

また、このアクティビティはOrchestratorへ接続した際、Orchestratorのログで確認することができるため、エラーハンドリングの際は必ず利用するようにします。

メール送信

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

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

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

待機ボックス

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

業務部門のあまりITに詳しくないユーザーが実行する場合の混乱を避ける目的で利用しています。（結局修正対応は、IT部門が行うことが多い。。。）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発するワークフローにおけるCatchブロックは次のような順番となります。

あくまでも参考なので、この辺は導入環境・運用に基づき変更しております。

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

また、メッセージログの出力、メール送信の本文として次のような設定をします。

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

これにより、エラーが発生したアクティビティおよびその内容を担当者へ伝え、ワークフローの修正へとつなげることが可能となります。

まとめ

今回は、僕が行こなっている開発手法の一部およびエラーハンドリングの方法の共有記事でした。

あまり、社外のUiPathエンジニア方とこのような開発手法について議論する機会がないのでもしこっちのほうがよい等ありましたら、コメントいただけると嬉しいです。

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

では。