UiPath公式のフレームワークとして「ReFramework」というものがあります。
ロボットの数が増えてきたときに、どのロボットも同じフレームワークで開発されていると保守が幾分楽になりますし、ロボットの設計/開発もやりやすくなると思います。
今回は前回作成した「交通費検索」ロボットをReFrameworkベースに作り直し、その中でReFrameworkがどのような仕組みになっているのかをまとめてみました。
ロボットの処理概要
交通費検索をするにあたって、ロボットを「キュー登録」と「本処理」の2つに分けます。
交通費検索_キュー登録
Mainページ
プロジェクト構成
1. configファイル読込
Dataフォルダ内に配置されているConfigファイルを読み込み、Directory型の配列に格納し、Mainに返却します。
Configファイルは3つのシート「Settings」「Constants」「Assets」に分かれています。
Settings、ConstantsはConfigファイルで定義した定数、AssetsはOrchestratorで定義した定数です。
Assetsシートに記載された定数に関しては、Orcehstratorのアセットに定義された定数と名前が合致していれば配列に格納します。
2. アップロードフォルダから交通費ファイルを取得し、キューに登録
【UiPath】交通費検索ロボットを作ってみる
と同様、各社員が交通費検索用のファイルを配置するという運用を仮定します。
共有フォルダ（本記事ではローカルフォルダ）に、各社員が自身の社員番号のフォルダに交通費検索用のファイルを配置します。
ロボットはそれらのファイルを社員の数分取得し、内容を読み取り、Orchestratorの「キュー」という場所にデータを格納します。
キューは以下のように登録されます。
今回、「交通費検索ヘッダーキュー」「交通費検索明細キュー」の2つのキューを用意します。
ヘッダーキューには読み込んだファイル、明細キューは読み込んだファイルの内容を登録する仕様とします。
例えば、「10000000_交通費.xlsx」に4ルート記載があった場合は、ヘッダーキューは1件、明細キューは4件登録されます。
明細キューには、出発/到着駅、片道・往復、経路（優先ルートの指定）など、路線検索の詳細も登録します。
交通費検索_本登録
基本的な動作は【UiPath】交通費検索ロボットを作ってみると同じですが、データの取得元が「交通費検索_キュー登録」ロボットで登録したキューになります。
Mainページ
プロジェクト構成
1. Configファイル読込
「交通費検索_キュー登録」ロボットと同じ処理です。
Mainページの「Init」の中で呼び出している「InitAllSettings.xaml」でConfigファイルを読み込みます。
2. 起動しているプロセスを強制終了する
InitAllSettingsの後、「KillAllProcesses.xaml」にて指定したプロセスを強制終了します。
今回はChromeを強制終了するようにします。
3. Chromeブラウザを起動し、Yahoo!路線検索を開く
KillAllProcessesの後、「InitAllapplications.xaml」にてChromeでYahoo!路線検索を開きます。
3. ヘッダーキューからデータ取得
Mainページの「Get Transaction Data」の中のアクティビティ「Get Transaction Item」でヘッダーキューを1件取得します。取得するのはキューステータスが「新規」となっているデータのみです。「完了」となっているキューデータは取得対象外です。
この「Get Transaction Data」と、この後の処理「Process Transaction」はヘッダーキューに登録されたキューデータの件数分ループして実行されます。
つまり、Get Transaction DataとProcess Transactionは1セットで実行されます。
4. 明細キューからデータ取得
Mainページの「Process Transaction」の中で呼び出されている「Process.xaml」にて、ヘッダーキューに紐付く明細キューデータを全件取得します。
ヘッダーキューと明細キューを紐付けるキーは、ヘッダーキューの「参照」とします。
今回の場合、ファイル名がキーとなって、そのファイルに記載された4ルート（＝明細キュー4件）が取得できるようにしています。
5. Yahoo!路線検索で路線検索＆交通費を取得
「交通費記入.xaml」にて明細キュー1件ずつ路線検索を行い、交通費をファイルに記入していきます。
路線検索とファイル記入が正常に完了したら、明細キューのステータスを「成功」に更新します。
6. ヘッダーキューステータス更新
Process Transactionの処理完了後（＝1ファイルに記載された全てのルートの路線検索＆交通費記入が完了した後）、「SetTransactionStatus.xaml」にてヘッダーキューのステータスを「成功」に更新します。
Process Transactionの処理を眺めると分かるのですが、Try~Catch~FinallyのTryの中で「Process.xaml」が呼び出され、Finallyで「SetTransactionStatus.xaml」が呼び出されています。
Process.xamlの処理中に発生したエラーが「BusinessRuleException」としてキャッチされる分類のエラーであれば、キュー定義時に指定したリトライ回数上限まで、再度Get Transaction Dataから処理を実行し直します。
「BusinessRuleException」以外のエラーの場合は、Initから実行し直します。
※このあたりの例外制御については、後日追記します。
7. アプリケーションを閉じる
Mainページの「End Process」の中で呼び出している「CloseAllApplications.xaml」にてアプリケーションを閉じます。
今回は、ChromeをショートカットキーAlt+F4で閉じるという実装を入れます。
まとめ
比較的規模の大きいロボット向けのフレームワークということもあり、Orchestratorの導入が前提の実装となっている印象です。
Orchestratorを利用するメリットは【UiPath】Orchestratorことはじめを読んでいただければと思います。
それ以外のReFrameworkの特徴で注目したいポイントは以下のとおりです。
リトライ処理
Process Transactionで例外発生時、リトライ処理を行なうことも可能となっていますが、リトライを正常に行える状態に戻す処理を工夫する必要があるかもしれません。
例えば、ファイル移動後に例外発生した場合はファイルを戻す処理が必要ですし、キューの状態を戻す処理や操作対象のアプリケーションの再起動などを考慮する必要があります。
テストフレームワーク
RPAは仕様変更/改修が比較的容易にできる半面、デグレを起こしやすいとも言えます。
また、操作対象の基幹システム、Webサイト等に画面改修が入った場合、正常に動作しない可能性が高いです。
なので、テスト効率を上げるというのはRPAにおいてはかなり重要です。テスト品質を落とさず、時短で実施できなければRPA導入のメリットを享受できません。（時間がかかるならシステム改修するわ、ってなってしまう。。。）
まだ詳しく実装を見ていないのですが、うまく活用したい仕組みです。
エラー発生時のスクリーンキャプチャ
RPAの特徴でもあるのですが、エラー発生時に何が原因なのかがわかりづらい場合があります。
例えば、本番環境と検証環境でロボットの挙動に差がある場合もあり、本番環境で何が起きたのかをキャプチャでエビデンスとして保存できるのは助かります。
エラーログからボタン押下に失敗したのか、そもそもブラウザやアプリの起動に失敗しているのか判別できないことも想定されます。（カーナビで目的地周辺で音声案内を終了される感じですねｗ）