はじめに
この投稿は、RPAツール「UiPath」の 実装ポイントをまとめたものです。
UiPath Adventカレンダーの 4日目 の記事でもあります。
量が多いので、記事を数回に分けます。今回は、後編 として「保守性・信頼性・安全性」について書きます。
前編・中編の記事はこちら
UiPath公式の「品質の良いコード」とは？
UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。
これを以下のように分類し「コーディング規約に書かれている事」と「自分が見聞き、経験、実践している事」をミックスして、紹介します。
ルール仕組み
◆ 一貫性 (命名規則や処理の構造などが複数のワークフローで統一されている)
◆ 可読性 (読みやすく、処理の意図が把握しやすい)
◆ 再利用性 (作成済・テスト済のワークフローをそのままの形で再利用しやすい)
安定効率
◆ 効率性 (少ないリソースで高速に動作する)
◆ 安定性 (安定して動作する)
保守
◆ 保守性 (どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)
◆ 信頼性 (エラーが発生しにくく、また発生した場合でも回復が容易である)
◆ 安全性 (機密情報を不正アクセスから守る)
保守性
⚫ 保守性 (どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)
まず、保守性の話。可読性の話と似てますが「保守することも考えて作ろう」ということです。「保守性」のために出来る、具体策としては以下があげられます。
- 1）処理を別ファイルに切り出し、結合度を減らす（修正の影響を小さくする）
- 2）xamlファイル単位で、単体テストが出来るようにする（テストしながら実装する）
- 3）1プロジェクトで、1業務にする（色々詰め込まない）
- 4）フォルダを整理し、ブロック単位でまとめる（把握しやすくする）
UiPathには「ワークフローとして抽出」という機能があり、簡単に処理をxamlファイルに切り出せます。「コードが長くなってきた」と感じたり「この機能は別フローにしておくとテストがしやすいな」と思ったら、積極的に分割していきます。
xamlファイルに切り出した処理は、単体実行で動くようにして「テストしながら実装」します。テストの方法は、xamlファイルを呼び出すtest.xamlを作成する方法か、処理内で引数を自動で補填するか方法があります。この「細かくテストしながら実装する」という方法は、開発のスピードを出すためにも、品質を高くするためにも、かなり大事なポイントです。
xamlファイルに上手く切り出してはいても、１つのプロジェクト内に処理を詰め込みすぎて、肥大化してしまうこともあります。「詰め込むほうが楽」な事もありますが「モノリシック（巨大な1枚岩）になって手を出せなくなる」前に、折を見て、プロジェクト分割を検討したほうが良いです。
xamlファイルで分割する際に、ファイル名やフォルダ名を工夫すると、見た目で似たような処理が把握できます。同類の処理はプレフィックスを同じにするなど「グルーピング・分類」したいです。
信頼性
⚫ 信頼性 (エラーが発生しにくく、また発生した場合でも回復が容易である)
続いて、信頼性（エラーが起きない＆起きてもすぐ直る）の話。
「信頼性」のために出来る、具体策としては以下があげられます。
- 1）処理の前提条件／初期状態を実行前に保証する
- 2）どこまで何を処理したかをファイルやログに記録し、途中からの再実行を可能にする
- 3）リトライ可能なエラーの場合は、自動リトライしてみる
- 4）エラーは適切にキャッチし、業務エラーとシステムエラーを区別する
まず、処理の実行前に使用アプリの初期化（タスクをキルしておくなど）をしたり、エラーが起きる要素を減らしておきます。登録処理などの場合は、重複処理を避けるために該当データの有無・状態をチェックします。
RPAでは一度の実行で複数のデータを連続して処理することが多く「どこまで処理が終わったか」をエクセルなどに記録しておくと、エラー時に把握がしやすくなります。エラー後の再実行でも、そのエクセルを見て「処理が未実施の箇所から再実行する」ように実装しておくと、リトライが簡単になります。
ただし、何度再実行して良い処理の場合は、エラーでも自動で数回リトライするようにしておきます。UiPathでは「リトライスコープ」という便利なアクティビティがありますが、「エラーの種類で動きを変えることが出来ない」ため、性質上「WEBページの遷移にたまに失敗する時」や「ファイルの移動に、たまに失敗する時」等しか使えるシーンがありません。なので、自分で「トライキャッチ」を規定回数ループさせて、リトライの仕組みを作ります。
エラー発生時には、エラーの理由をしっかり把握する必要があります。UiPathには「ビジネス例外」という概念がありますが、例えば「特定のデータが不完全であるか欠落していることが原因で発生するエラー」などで、処理をスキップ・中断する際にに使用します。データの補正した後で、再実行するデータです。
安全性
⚫ 安全性 (機密情報を不正アクセスから守る)
最後に、安全性の話。「安全性」のために出来る、具体策としては以下があげられます。
- 1）機密情報は適切な場所に安全な形で置く
- 2）ログに機密情報を出力しないさせない
- 3）実行ユーザーには、処理の上で最低限の権限しか与えない
- 4）一時ファイルは処理終了時に削除する
ロボットがログイン名とパスワードを使用する場合、パスワードを暗号化することが推奨されていますが、その方法として、Windows資格情報 を使用するか Orchestratorの アセットを使用する方法があります。
また、ログにパスワードなどの機密情報を出力してしまうと、ログから機密情報が漏れてしまうため、ログを出力する場合は「機密情報を含んでいないか」に注意をする必要があります。
ロボットの実行ログには、アクティビティの引数を記録する機能もありますが、アクティビティの「プライベート」プロパティにチェックをすると「password」等の特定文字を出力されない機能もあります。（この機能を使うプロジェクトは多くはないですが）
RPAの実行ユーザーに、過度にアクセス権限を与えると、予期しない処理をしてしまった時や、万が一、ロボットを乗っ取られた場合に被害が多くなります。アドミニストレーター（管理者）権限での実行などは避けて、必要最低限の権限のみにしたほうが良いでしょう。
ロボットが処理した際に、一時的に作成したファイルなどにも、意図せず機密情報が含まれてしまうことがあります。処理終了時に一時ファイルは消しておくに心がけたいです。
終わりに
いかがでしたでしょうか？今回は後編として「保守性・信頼性・安全性」について書きました。
この記事が参考になったら、 LGTMをお願いします。閲覧ありがとうございました。