はじめに
この投稿は、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をお願いします。閲覧ありがとうございました。