RPAでの大量データ自動化処理の実践開発
フレームワークの利用
ここからは、UiPathでキュー処理を実行するフレームワークを利用して、キューを利用した処理を実装していきます。フレームワークは、UiPath Studioに同梱されている「Robotic Enterprise Framework」です。このフレームワークが提供する便利な点として、下記の項目が挙げられます。
- フレームワークによるブロジェクト・ワークフローの管理・メンテナンス性
- キュー操作提供
- ビジネスロジックの分離
- ログの均一化
- 単体テストのフレームワーク
それでは実際の手順に入ります。まずUiPath Studioのスタート画面より、「Robotic Enterprise Framework」をクリックします。
「名前」に適当なプロジェクトの名称を入れ、「作成」ボタンをクリックして新規のRobotic Enterprise Frameworkを開始します。
次の通り、Robotic Enterprise Frameworkのワークフロー画面が表示されます。
「Main.xaml」は、一見すると複雑なようですが、開発時に意識する必要があるものは、右下の「Process」のみです。
「Process」以外に一点、キュー機能を利用するための設定として、プロジェクトフォルダ内のDataフォルダに格納されているコンフィグファイル（Config.xlsx）を編集します。ここでは「Settings」シートの「OrchestratorQueueName」に、今回作成したキューである「MyQueue」を指定します。下の通りコンフィグファイルを編集して、ファイルを保存します。
この設定により、フレームワークでは、「MyQueue」より未処理のキューを取得し、キューに登録された値を基に、開発者は必要となる自動化処理を、「Process.xaml」に実装可能となります。
Process内での実装
それでは、Process.xamlを編集していきます。
このProcess内で発生する（発生させる）例外を適切に処理・実装することで、フレームワーク側にて、適宜トランザクションのリトライ処理や処理の中断を行ってくれます。
| 例外 | 挙動 |
|---|---|
| ビジネス（Business Rule） | トランザクションを中断、スキップする…業務上のエラーで、例えば入力値に許容しないマイナスが入力された場合、当該例外を発生させます。後続処理ができないと判断し、この場合フレームワークでは「失敗」と判断しリトライ処理は行いません |
| アプリケーション（Application、上記以外の例外） | トランザクションをリトライする…ビジネス以外の例外（一時的なネットワーク遮断など）は、リトライにて自動化の成功が見込まれると判断し、フレームワークは、最初の処理からトランザクションのリトライを試みます。なお、リトライ回数はOrchestrator側のキューの設定で指定可能です |
それでは、作成済みのワークフロー「InputExpense.xaml」を、「ワークフローファイルを呼び出し」アクティビティにて呼び出します。
この時、「InputExpense.xaml」には、キューアイテムの値を引数として受け渡すことで、キューアイテムの内容が、経費デモサイトへそのまま登録されるよう仕掛けます。
まず、「ワークフローファイルを呼び出し」アクティビティ上の「引数をインポート」します。
そして、値の箇所を下記の通り、Queueの値を受け渡せるよう更新します。
キューアイテムは、「in_TransactionItem」というProcessワークフローの引数、キューアイテムの値は「in_TransactionItem.SpecificContent(“Title”)」などとして参照できます。
なお例外処理として、引数のAmountがマイナスの場合ビジネスルール例外が発生するよう、「InputExpense.xaml」に「条件」のアクティビティを追加しておきます。
またアプリケーション例外発生のテストとして、引数のdescが「Exception」と一致した場合、Exceptionを発生させる「条件」のアクティビティも追加しておきます。
テストのCSVファイルには、それぞれの例外に該当するデータが1件ごとに含まれております。
フレームワークの実行結果
テストの10件のデータが、キューアイテムとして全て処理されていることを確認します。今回のテストデータは10件の内、2件がエラーとなるデータですので、8件の正常処理が確認できれば良いものとなります。
例外処理の確認として、引数の「Amount」がマイナスの場合、ビジネスルール例外が発生していることをキューアイテムの処理結果より確認できます。
同様に、テストで発生したアプリケーション例外が発生していることをキューアイテムの処理結果より確認できます。
なお、1,000件のデータで実行した場合の実行時間は、キューの登録が5分、1台のロボットでのキューに基づく経費デモサイトの自動化（キューの消し込み）が2時間弱という結果でした。
キューの消し込みにかかる時間を短縮したい場合、ロボットを複数台並行稼働させることにより、稼働時間を短縮できます。例えば、2台並行で実施した場合、1時間での処理完了が見込まれます。複数台でのロボットの自動化処理の実行に関しては、Orchestratorにて管理・割り当てが簡易に行えます。これにより、非稼動のロボットを有効稼働させ、自動化処理をスケールアウトさせることが簡単にできます。トランザクションはキューアイテムとしてきちんと管理されていますので、同一キューアイテムの重複登録の心配はありません。
Orchestratorのコンソール画面には下のように、キュー処理のリアルタイムのモニタリング機能も用意されています。
まとめ
今回、キュー機能とフレームワークの連携において、大量データの処理もトラッキング可能な形で自動化できることが確認できました。実装時間に関しては、フレームワークを利用することにより自動化処理の実装に専念でき、短時間での開発が可能であることを実感いただけたかと思います。
仮に、キュー管理やフレームワークを使用しなかった場合、トランザクション管理やエラーハンドリングの設計や実装に多くの時間を割き、また試行錯誤を繰り返すものとなります。
今回利用した「Robotic Enterprise Framework」は、キュー機能との連携に最適化されたフレームワークです。ぜひ、Processの中身を自身の業務自動化に置き換え、処理単位をトランザクション化してキュー登録し、実際のRPAの開発や運用に役立てて下さい。
