【UiPath】品質の高いコードとは（後編）

# はじめに

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

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

https://qiita.com/advent-calendar/2021/uipath

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

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

https://qiita.com/miya_gis/items/3b4ca91ed5ad4bd50503

https://qiita.com/miya_gis/items/28f08496f68157a1d69e


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

UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/e2d35812-460e-66b3-9429-623ce23785d9.png)

https://www.uipath.com/ja/blog/corporate/uipath-coding-standard

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

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

 保守性

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

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

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

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

https://dekiru.net/article/17708/

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

https://qiita.com/miya_gis/items/48150c2a41dda31da57f

xamlファイルに上手く切り出してはいても、１つのプロジェクト内に処理を詰め込みすぎて、肥大化してしまうこともあります。「詰め込むほうが楽」な事もありますが「モノリシック（巨大な1枚岩）になって手を出せなくなる」前に、折を見て、プロジェクト分割を検討したほうが良いです。
<img src="https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQMchvtKxpbEMwWvwU05BYfblw9jbNUJtnu9Q&usqp=CAU" width="400">

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

# 信頼性

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

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

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

まず、処理の実行前に使用アプリの初期化（タスクをキルしておくなど）をしたり、エラーが起きる要素を減らしておきます。登録処理などの場合は、重複処理を避けるために該当データの有無・状態をチェックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/7b564532-a498-43ca-281c-8a97b8adfaf2.png)

RPAでは一度の実行で複数のデータを連続して処理することが多く「どこまで処理が終わったか」をエクセルなどに記録しておくと、エラー時に把握がしやすくなります。エラー後の再実行でも、そのエクセルを見て「処理が未実施の箇所から再実行する」ように実装しておくと、リトライが簡単になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/fed2ae28-8481-fc02-da98-0c07d99f7025.png)

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

https://qiita.com/Davoi/items/a503aa8b444b98fb698b

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

https://docs.uipath.com/orchestrator/lang-ja/docs/business-exception-vs-application-exception


# 安全性

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

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

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

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

https://www.uipath.com/ja/resources/knowledge-base/%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E3%81%AE%E6%9A%97%E5%8F%B7%E5%8C%96%E6%96%B9%E6%B3%95

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

https://docs.uipath.com/installation-and-upgrade/lang-ja/v2020.10/docs/studio-protecting-sensitive-information

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

https://kn.itmedia.co.jp/kn/articles/1912/24/news010.html

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

# 終わりに

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

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