Last updated on 2022年8月9日
UiPathでの開発ですが、自由度が高くどう開発するのがよいか迷った経験はないでしょうか。
プログラミングでもコーディング規約があるように、UiPath社からも同種のものが発行されています。
今回はそれをもとに私のほうで少しアレンジしてバグの少ない開発方法について書いてみたいと思います。
少しアレンジ版となっているのでご了承を。
本記事では、UiPath Ver 2021.10.4 を使用しています。
Contents
開発のポイント
開発のポイントは大きく６つになります。
- ビジネスロジックとUI操作を分離する
- 適切な名前をつける・重複はさける
- 不要な要素をは削除する
- 注釈をつける
- 適度にログを出力する
個人的に重要だと思うものから上位に記載しました。
それぞれ順番位解説していきたいと思います。
（１）ビジネスロジックとUI操作を分離する
主に開発の前、設計のタイミングで行う必要がありますがワークフローをビジネスロジックとUi操作で分離するとワークフロー単体で見た場合の機能が明確になりバグが少なくなります。
ここでビジネスロジックと言っているものは業務の流れであり、Ui操作は実際のクリックなどの操作をいいます。
イメージは次の図のようになります。
ビジネスロジックではフローチャートが用い、Ui操作ではシーケンスを用いると可視性や修正効率が向上するのでおすすめです。
またビジネスロジックからUI操作のワークフロー呼び出しには[ワークフローを呼び出し]アクティビティを利用します。
こちらにまとめているの参考にしてみてください。
そういえば昔教えてもらったのを思い出したニャ
（２）要素に適切な名前をつける・重複はさける
UiPathでは、色々な要素に名前をつけることができます。
プロジェクトやワークフローを構成する各要素に適切な名前を付けておくと、関係者間で前提知識や開発の文脈を共有できバグを減らすことにつながります。
後々名前を変えることはできますが大きな手間となるため、あらかじめ命名規則を定めておくとよいです。
また、同じ名前の重複利用は混乱もととなりバグに直結するのでやめましょう。
名前をつけることができる要素の一例として次のようなものがあります。
- プロジェクト
- ワークフローファイル
- 変数
- 引数
- アクティビティ
記法には「キャメルケース」「スネークケース」「ケバブケース」などがありますが、個人的にはスネーク記法をおすすめしています。
（３）不要な要素をは削除する
使っていない変数や引数、またアクティビティについては削除するようにします。
直接バグのもととなることはありませんが、後日保守をするとなった際に用途不明な要素が存在するとその妨げとなります。
どうしても残しておかないといけない場合を除き削除するようにしましょう。
削除については、Studioの上部パネルより行うことができます。
開発がひと段落したところで一通りクリックしておくとよいと思います。
（４）注釈をつける
UiPathでは、個々のアクティビティおよび変数に注釈というコメントを追加することができます。
複雑な処理を行う際にこの注釈機能を活用することで保守性を高めることができます。
追加方法は、対象のアクティビティを選択した状態で右クリック [注釈]→[注釈の追加] から行うことができます。
フローチャートやシーケンスのようなコンテナアクティビティ、また変数や引数にも追加することができます。
フローチャートに追加した場合のサンプルです。
また、変数に注釈を追加した場合は次のようになります。
注釈なんて知らなかったニャ
次から利用してみるニャ
（５）適度にログを出力する
適度なログ出力も意図した通りに動作しているか確認できるという点でバグを減らすことにつながります。
ログの出力には[メッセージをログ]アクティビティを利用します。
とはいえ、ひたすらログを出力すればいいというわけではありません。
ログの出力を増やしすぎると開発画面の可視性が低下するとともに、ログの確認も大変となってしまいますので適度を心がけます。
Orchestratorを導入しているケースでは遠隔からの監視ができるというメリットもあります。
ログレベルを意識することで監視・保守が効率化するので理解しておくと良いと思います。
最後に
RPAは、非常に簡単に開発を行うことができ短時間で業務の効率化を行うことができます。そのメリット故に開発後に発生する保守や運用のことをおろそかになりがちかなと思います。RPAだからと安易に考えるのではなくバグの少ない、保守性の高いワークフローを開発するようにしましょう。
最後までお読みいただきありがとうございます。
では。
