LoginSignup
2

More than 1 year has passed since last update.

【UiPath】品質の高いコードとは(後編)

Last updated at Posted at 2021-12-04

はじめに

この投稿は、RPAツール「UiPath」の 実装ポイントをまとめたものです。

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

量が多いので、記事を数回に分けます。今回は、後編 として「保守性・信頼性・安全性」について書きます。

前編・中編の記事はこちら

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

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

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

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

保守性

⚫ 保守性  (どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)

まず、保守性の話。可読性の話と似てますが「保守することも考えて作ろう」ということです。「保守性」のために出来る、具体策としては以下があげられます。

- 1)処理を別ファイルに切り出し、結合度を減らす(修正の影響を小さくする)
- 2)xamlファイル単位で、単体テストが出来るようにする(テストしながら実装する)
- 3)1プロジェクトで、1業務にする(色々詰め込まない)
- 4)フォルダを整理し、ブロック単位でまとめる(把握しやすくする)

UiPathには「ワークフローとして抽出」という機能があり、簡単に処理をxamlファイルに切り出せます。「コードが長くなってきた」と感じたり「この機能は別フローにしておくとテストがしやすいな」と思ったら、積極的に分割していきます。

xamlファイルに切り出した処理は、単体実行で動くようにして「テストしながら実装」します。テストの方法は、xamlファイルを呼び出すtest.xamlを作成する方法か、処理内で引数を自動で補填するか方法があります。この「細かくテストしながら実装する」という方法は、開発のスピードを出すためにも、品質を高くするためにも、かなり大事なポイントです。

xamlファイルに上手く切り出してはいても、1つのプロジェクト内に処理を詰め込みすぎて、肥大化してしまうこともあります。「詰め込むほうが楽」な事もありますが「モノリシック(巨大な1枚岩)になって手を出せなくなる」前に、折を見て、プロジェクト分割を検討したほうが良いです。

xamlファイルで分割する際に、ファイル名やフォルダ名を工夫すると、見た目で似たような処理が把握できます。同類の処理はプレフィックスを同じにするなど「グルーピング・分類」したいです。

信頼性

⚫ 信頼性  (エラーが発生しにくく、また発生した場合でも回復が容易である)

続いて、信頼性(エラーが起きない&起きてもすぐ直る)の話。
「信頼性」のために出来る、具体策としては以下があげられます。

- 1)処理の前提条件/初期状態を実行前に保証する
- 2)どこまで何を処理したかをファイルやログに記録し、途中からの再実行を可能にする
- 3)リトライ可能なエラーの場合は、自動リトライしてみる
- 4)エラーは適切にキャッチし、業務エラーとシステムエラーを区別する

まず、処理の実行前に使用アプリの初期化(タスクをキルしておくなど)をしたり、エラーが起きる要素を減らしておきます。登録処理などの場合は、重複処理を避けるために該当データの有無・状態をチェックします。
image.png

RPAでは一度の実行で複数のデータを連続して処理することが多く「どこまで処理が終わったか」をエクセルなどに記録しておくと、エラー時に把握がしやすくなります。エラー後の再実行でも、そのエクセルを見て「処理が未実施の箇所から再実行する」ように実装しておくと、リトライが簡単になります。
image.png

ただし、何度再実行して良い処理の場合は、エラーでも自動で数回リトライするようにしておきます。UiPathでは「リトライスコープ」という便利なアクティビティがありますが、「エラーの種類で動きを変えることが出来ない」ため、性質上「WEBページの遷移にたまに失敗する時」や「ファイルの移動に、たまに失敗する時」等しか使えるシーンがありません。なので、自分で「トライキャッチ」を規定回数ループさせて、リトライの仕組みを作ります。

エラー発生時には、エラーの理由をしっかり把握する必要があります。UiPathには「ビジネス例外」という概念がありますが、例えば「特定のデータが不完全であるか欠落していることが原因で発生するエラー」などで、処理をスキップ・中断する際にに使用します。データの補正した後で、再実行するデータです。

安全性

⚫ 安全性  (機密情報を不正アクセスから守る)

最後に、安全性の話。「安全性」のために出来る、具体策としては以下があげられます。

- 1)機密情報は適切な場所に安全な形で置く
- 2)ログに機密情報を出力しないさせない
- 3)実行ユーザーには、処理の上で最低限の権限しか与えない
- 4)一時ファイルは処理終了時に削除する

ロボットがログイン名とパスワードを使用する場合、パスワードを暗号化することが推奨されていますが、その方法として、Windows資格情報 を使用するか Orchestratorの アセットを使用する方法があります。

また、ログにパスワードなどの機密情報を出力してしまうと、ログから機密情報が漏れてしまうため、ログを出力する場合は「機密情報を含んでいないか」に注意をする必要があります。
ロボットの実行ログには、アクティビティの引数を記録する機能もありますが、アクティビティの「プライベート」プロパティにチェックをすると「password」等の特定文字を出力されない機能もあります。(この機能を使うプロジェクトは多くはないですが)

RPAの実行ユーザーに、過度にアクセス権限を与えると、予期しない処理をしてしまった時や、万が一、ロボットを乗っ取られた場合に被害が多くなります。アドミニストレーター(管理者)権限での実行などは避けて、必要最低限の権限のみにしたほうが良いでしょう。

ロボットが処理した際に、一時的に作成したファイルなどにも、意図せず機密情報が含まれてしまうことがあります。処理終了時に一時ファイルは消しておくに心がけたいです。

終わりに

いかがでしたでしょうか?今回は後編として「保守性・信頼性・安全性」について書きました。

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2