はじめに

この投稿は、RPAツール「UiPath」の実装ポイントをまとめたものです。
量が多いので、記事を数回に分けます。今回は、中編として「安定性・効率性」について書きます。

UiPath Adventカレンダーの 3日目の記事でもあります。

前編の記事はこちら

UiPath公式の「品質の良いコード」とは？

UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。

これを以下のように分類し「コーディング規約に書かれている事」と「自分が見聞き、経験、実践している事」をミックスして、紹介します。

ルール仕組み
　◆ 一貫性 　(命名規則や処理の構造などが複数のワークフローで統一されている)
　◆ 可読性　 (読みやすく、処理の意図が把握しやすい)
　◆ 再利用性 (作成済・テスト済のワークフローをそのままの形で再利用しやすい)
安定性 効率性
　◆ 効率性 　(少ないリソースで高速に動作する)
　◆ 安定性 　(安定して動作する)
保守
　◆ 保守性 　(どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)
　◆ 信頼性 　(エラーが発生しにくく、また発生した場合でも回復が容易である)
　◆ 安全性 　(機密情報を不正アクセスから守る)

効率性

⚫ 効率性　(少ないリソースで高速に動作する)

最初は「処理の効率性」の話です。実現するには
「効率性」のために出来る、具体策としては以下があげられます。

- 1）処理に時間がかかる部分・リソースを食う処理を把握する
- 2）繰り返しの中では処理を極限まで効率化する
- 3）処理を2段階に分けて実行する（データを絞って読み込むとか）
- 4）並列処理で待機時間を減らす

まず、非効率＝「処理に時間がかかる箇所」または「リソース（CPU／メモリ）」を特定する必要があります。ログ出力を小刻みに入れて、処理に時間がかかっている部分を特定したり、タスクマネージャーで「リソース使用状況」をチェックをしたり。

また、良くあるのが「繰り返し処理」の中で、無駄な処理（例：不要なログ出力／不要な代入など）があり、数十回、数百回のループなら大した事無いのですが、数千、数万回のループだと気になってしまうほど遅くなることがあります。（1回1秒なら、10000回で10000秒＝166分）

大きめの処理で時間がかかっている場合、2つに分けて実行すると効率的になることがあります。例えば、DataTableのSelect条件を複数書くよりも、1つの条件でSelect実行を繰り返すほうが早いこともあります。

UiPathには並列処理のアクティビティがあり、処理のアイドル時間を有効活用することが出来ます。ただし、非同期な処理を行うことは難しく、仮に出来たとしてもメリットが少ない（早くない）事もあるので、事情がない限り、非同期処理は諦めたほうが良さそうです。（チャレンジするのは良いことですが）

安定性

⚫ 安定性　(安定して動作する)

続いて、安定性の話。不安定になりがちなRPAでは、非常に大事な要素です。
実現するには、例えば以下のような具体策があります。

- 1）セレクター認識を安定させる
- 2）リトライをうまく使う
- 3）画像認識を避ける
- 4）環境差異を減らす

セレクター認識を安定させるには、いろいろなアプローチがあります。
UiPathが公式に纏めてくれているテクニックがあるので、ココでの言及は割愛します。

一時的エラーがある処理で、繰り返せば成功する場合は「リトライで自動チャレンジ」する事できますが、エラーをよく分析して、フローを実装する必要があります。大事なことは「繰り返し実行しても良い処理なのか」という事です。登録処理などは「実は成功している」事もありえるので、リトライする前にデータ登録済みかをチェックするなどの考慮が必要になることも。

また、要素の有無をチェックする際に「画像認識」を使うことはオススメできません。
解像度や位置のズレなど、画像認識単体では、安定性を保つのが難しいからです。

開発環境と本番環境の違いは「RPAあるある」ですが「差異を無くす努力」はするとして、本番試験を手厚く行うことが一番有効です。Studioバージョン21.10からは「リモートデバッグ実行」という機能があり、リモート端末でお試し実行もできます。また、スペックなどの情報をログに出力することで、エラー時の初動調査を加速する事も大事です。

終わりに

いかがでしたでしょうか？今回は中編として「安定性・効率性」について書きました。

この記事が参考になったら、 LGTMをお願いします。閲覧ありがとうございました。