【UiPath】エラーハンドリングの方法

Last updated on 2022年8月9日

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

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

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

本記事では、UiPath Ver 2021.10.4 を使用しています。

例外処理について

ワークフローは実行すると開発した通りに処理を終えるのが普通だと思っていませんか。

実際の現場では実行の前提条件や環境が異なるために動かず止まってしますケースも多々あります。

この止まってしまうような状態を例外といい、これをちゃんと動作するように処理してあげることを例外処理といいます。

例えれば、道路が塞がって通れない箇所に回り道を作って別のルートに移してあげるようなイメージです。

[トライキャッチ] アクティビティの使い方

例外処理で使用するアクティビティとして、[トライキャッチ]アクティビティがあります。

[トライキャッチ]アクティビティは、「Try」「Catch」「Finally」の３つのブロックから構成されておりそれぞれに役割があります。

WordPress Tables Plugin

特に「Catches」ブロックが重要となり、ここに処理する例外の型を設定してあげることでそれに対応した適切な処理を定義、実行することができます。

例外処理をした場合、エラーとはならず後続の「Finally」ブロックへと処理が流れていきます。

[Catch] ブロックの中で実装する処理

キャッチブロックの中で実装する処理として次のようなものが挙げられます。

どれか１つ実装すればいいというわけではなく、可能であればすべて実装するようにします。

• メッセージによる通知
• ログを出力
• キャプチャを採取

メッセージによる通知

キャッチブロックの中でワークフローを実行しているユーザーにも伝わるかたちでメッセージを送ることは例外への対処として有効です。

[メッセージボックス]アクティビティや[メール送信]アクティビティがこの手段として考えられます。

たとえばアプリケーションエラーであれば開発者やシステム担当者に問題解決を依頼しなければなりません。

一方で、ビジネスエラーであれば実行者により解決が可能です。

「誰に」「どのように」「何を」伝えるかエラーごとに整理しておくことで現場での対応もスムーズに行うことができます。

ログを出力

指定した文字列をログメッセージとして書きキャッチした例外のMessageプロパティやDataプロパティはログとして出力しておきましょう。

これによりたとえその場で解決方法がわからなくても、後に修正する際のヒントとなります。

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

また、Orchestratorと接続している場合は、Orchestrator上でもログを確認することができます。

例えば次のようなログが考えられます。

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

キャプチャを採取

ログの取得と並行しエラー時の画面のキャプチャをしておくことで修正の手助けとなります。

キャプチャを取得するには、[スクリーンショットを作成]アクティビティを使用し、続けて
[画像を保存]アクティビティを使用することでそれを任意の場所に保存することができます。

ワークフローを終了/ 例外の再スロー

例外の内容によってはワークフローを終了したい場合もあると思います。

その場合は[ワークフローを終了]アクティビティを使用します。

[トライキャッチ]アクティビティの配置場所

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

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

一方、全くルールなしではそれこそ属人化の塊となり、導入後のケアは大変なものとなるのもまた事実です。

バランスが大事ということですね。

ビジネスロジックとUI操作をワークフロー単位で分けることが前提となりますが、[トライキャッチ]アクティビティは次のように利用することをおすすめします。

• [トライキャッチ]アクティビティはビジネスロジック側のワークフローに実装する
• UI操作のワークフローは[トライキャッチ]アクティビティの中で呼び出す

[トライキャッチ]アクティビティはビジネスロジック側のワークフローに実装する

ビジネスロジックを記述したワークフローについては、詳細処理を記述せずワークフロー呼び出し（Invoke Workflow）を利用し、詳細処理を記述した子のワークフローを呼び出すのみとするのが基本となっています。

つまり、ビジネスロジックを記述したワークフローは自ずと親のワークフローとなるため、ここに[トライキャッチ]アクティビティを配置することでUI操作の処理をまとめてハンドリングすることができるようになります。

UI操作のワークフローは[トライキャッチ]アクティビティの中で呼び出す

[トライキャッチ]アクティビティのTryブロック内で、[ワークフローを呼び出し]アクティビティを配置することでまとめて例外処理を行うことができます。

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

おまけ：AttendedFrameworkというものがある

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

このフレームの存在は知らなかったのですが、実際に使ってみて非常に使いやすかったです。

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

おまけ：グローバル例外ハンドラーというものもある

実は、[トライキャッチ]アクティビティの他に、例外処理そのものを外部のワークフローとして外出しにする「グローバル例外ハンドラー」というものがUiPathにはあります。

グローバル例外ハンドラーは、プロセスの中に１つだけ作成でき、プロセス内で起こった例外をキャッチします。

グローバルハンドラーの実装は次のように行います。

1. Studioでグローバルハンドラーを作成
2. プロパティの設定による実行制御

Studioでグローバルハンドラーを作成

[新しいファイルの作成] から [グローバルハンドラー] を選択することで作成することができます。

作成をするとプロジェクト内に新しいワークフローが一つ作成されているのが確認できると思います。

プロパティの設定による実行制御

グローバルハンドラーにはあらかじめ２つの引数が設定されています。

WordPress Tables Plugin

resultに設定可能な振る舞いは次のようになります。

WordPress Tables Plugin

一見使い勝手のいいように思われるグローバルハンドラーですが、これ単体では例外を正しくは処理できない（綺麗にフローを終了出来ない）ためあまりおすすめはしません。（なので、おまけです）

基本的な例外のハンドリングは呼び出し元の親ワークフローへ[トライキャッチ]アクティビティを配置することをおすすめします。

最後に

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

では。