みなさん、UiPathでの開発の際エラーハンドリングについて気にしたことはあるでしょうか？
私の場合は、UiPathを知ったばかりで好き勝手開発している頃はあまりエラーハンドリングについて気にしていなかったのですが、実際に社内で運用するようになり大変気を使うようになりました。
今回は、そんな経験も踏まえ開発の際に使っているエラーハンドリングの手法について記事にしてみたいと思います。
【追記】
UiPath Go から、AttendedFrameworkというエラーハンドリング、ログ等がフレームワーク化されたテンプレートをダウンロードすることが可能です。
このフレームの存在を私は知らなかったのですが、実際に使ってみて非常に使いやすく標準化をすすめるうえでたいへん役立つものであると感じました。
詳しくは、下記の記事で書いておりますので、フレームワークにご興味ございましたらご参考にしてください。
エラーハンドリングで利用するアクティビティ
エラーハンドリングの際に利用しているアクティビティを紹介します。
トライキャッチ（Try Catch）
エラーハンドリングとなった際に、必ず利用するであろうアクティビティです。
一見、複雑なアクティビティとなっており、「Try」「Catch」「Finally」の３つのブロックから構成されています。
ブロックにおけるそれぞれの役割は次のとおりです。
| ブロック名 | 用途 |
| try | 基本処理（行いたい処理）をこの中に記述をします。 |
| catch | try内の記述した処理の実行中にエラーが発生した場合、このCatchブロックに記述した処理へ移ります。 例外（Exception）の種類を選択する必要がありますが、"System.Exception”を選択することで実行上発生するすべてのエラーをカバーすることができます。 |
| finally | エラーの発生有無に関わらず、最終的に実行したい処理を記述します。 開発上、特別な場合を除きこの処理の記述は不要です。 |
メッセージログ（Log Message）
指定した文字列をログメッセージとして書き出します。
ログメッセージの重要度が選択できますが、エラーハンドリングのため、基本「Error」「Fatal」から選択すれば問題ありません。
また、このアクティビティはOrchestratorへ接続した際、Orchestratorのログで確認することができるため、エラーハンドリングの際は必ず利用するようにします。
メール送信
エラーが発生した際に、担当へ通知する手段として、メール送信を採用しています。
UiPathでは、メール送信アクティビティが複数あるため導入環境に応じて選択してください。
最も設定が簡単なのは「Outlook メール送信」となります。
待機ボックス
エラーの原因がユーザの操作に起因する場合（ビジネス例外）の場合、正しい利用方法を通知する手段として利用することがあります。
業務部門のあまりITに詳しくないユーザーが実行する場合の混乱を避ける目的で利用ています。（結局対応は、IT部門が行うことが多い。。。）
ワークフローを終了（Terminate Workflow）
トライキャッチアクティビティを利用した場合、エラーが発生した場合も処理が中断されず継続されます。
これを良しとするかどうかで判断が異なりますが、基本的に止めてしまうほうがその後の不具合を経験できると思います。
その際にこのアクティビティを利用することで処理を止めることができます。
とはいえ、一つのワークフロー内にいくつもトライキャッチを行うのは、RPAの特性に反している部分もあるように感じるため一つにまとめてしまう開発を行うことをおすすめします。
エラーを考慮したワークフローの作成
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エンジニア方とこのような開発手法について議論する機会がないのでもしこっちのほうがよい等ありましたら、コメントいただけると嬉しいです。
では。
