初めに
UiPathの開発者の皆さんは、モダンアクティビティのオブジェクトリポジトリ使っていますか？
私は使ってません(笑)
でも実は結構そんな方いらっしゃるんじゃないでしょうか。
手元のStudioのバージョンアップが容赦なくされていく中で、隠れているクラシックアクティビティを引っ張り出す、そんな毎日を送っている方もいらっしゃるのではないでしょうか。
個人的にはそもそもモダンアクティビティに切り替える必要性が薄いんですよねー
ただそんな私がふとオブジェクトリポジトリを使ってみると、これがめちゃめちゃ便利で驚きましたので、記事にしてみました。
これまで
ワークフローを作っていくときは、人が操作する手順と同じように順番にアクティビティをつなげていくものかと思います。
クリックアクティビティやテキスト入力のアクティビティ等でUI要素を取得していきますが、
ただ、そのままのUI要素はあまり使いたくないので、条件を緩めにして多少の要素の変化に強くしたり、変数を入れて汎用性を持たせたり、(やむを得ずidxを使ったり・・・)、ベストなUI要素の取得を目指して試行錯誤します。
これをすべての要素を必要とするアクティビティを設置する度に行ってきたわけですが、オブジェクトリポジトリを使えば、1か所でまとめてUI要素を管理できるのです。
他の開発案件にも流用できるので、一度要素を取ってしまえば、そのまま流用できてしまいます。
使ってみた
オブジェクトリポジトリはStudio画面の右下の方にタブがあり、
そこをクリックすると、オブジェクトリポジトリのパネルが開きます。
要素を使う必要のあるアクティビティが使う可能性がある要素を取っていきます。
・右上の＋ボタンを押下して、要素を追加のウインドウを開く
・要素を選択する
クリックアクティビティなどと同じように、UI要素を指定します。
すると、要素を編集というウインドウに要素を指定した箇所のスクショが撮れ、記述子を編集を選択すれば、
UI要素の編集ができます。
これを繰り返していけば、ツリー状にUI要素が出来ていきます。
私は階層の方を少し工夫していて、選択した場合に表示されるUI要素をその選択したUI要素の直下に置くようにしています。
例えば、kintoneメニューバーアプリをクリックするとファイル管理というメニューが表示されるので、その直下に置くという具合です。
またメニューだけでなく、要素が出現したかどうかで確認する場合に必要になるUI要素も同じ要領で作っていきます。
これらのUI要素取得の過程で、精度の高い条件を探していきます。
あとは別の開発案件ですでに取得したUI要素が必要になった場合、オブジェクトリポジトリのツリー状になっているUI要素からドラッグアンドドロップで、アクティビティに持ってくれば、再度要素を取得する必要がありません。
慣れている方ならば、予めどのUI要素が必要になりそうかわかると思うので、アクティビティをつなぎ合わせて開発する前に、ぱーっと要素だけ取ってしまってオブジェクトリポジトリに集約しておくことも可能かと思います。
因みに今回の画像の場合だと、結構早い段階でログアウトの要素を取得してしまってます。
ログアウトを使わない開発は基本的に無いからです。
チームで使う
開発チームで共有したい場合は、以下の画像の赤丸の箇所をクリックして、新しいライブラリを作成し、
パブリッシュをして共有できます。
チームで共有しているUI要素がアプリケーションのアップデートなどで変わってしまっても、オブジェクトリポジトリに格納されているUI要素だけ修正すればいいのです。
オブジェクトリポジトリを使う前提の開発となれば、開発ルールから大きく逸れた開発になりにくく、統一感が自然と生まれるかと思います。
プログラミングの世界に「オブジェクト指向」という概念があります。
これは各プログラミング言語や、RPAツールであればRPAツールごとに考え方が若干異なってくるようなので、私には一般的に語ることが困難なのですが、
大まかには「使用頻度が高くなるであろう処理は、今後も別の開発案件でもプログラミング対象になる可能性が高いので、予めその処理を抽象度を高めて部品化してしまって、その部品を使用する前提で開発しよう」という考え方なのだろうと思います。
UiPathにおいては、オブジェクトリポジトリや、引数でその後の処理の仕方を変えられるワークフローの呼び出しを設定する時に、この考え方が大事になってくるのかと思います。
ただ便利な部品化の考え方ですが、開発ルールや環境はしっかり整備する必要が出てきます。
・開発ルールや命名規則を整備する
・共通で使用するフレームワークの選定する
・部品化する単位をどうするか決める(画面が遷移したらその画面はUI要素のどの階層にするか、ならポップアップ画面はどうするか 等)
・部品の管理をしっかり行う
これらができていないと、粒度がバラバラの部品が出来て結局使わないなんてことになりえますので、既に存在するロボットの数やチームの規模、チームリーダーの理解度によっては、個人的には簡単には部品化には踏み出せないです。
最後に
オブジェクトリポジトリ登場以前に既に部品化を進めていた場合や、そもそもクラシックからモダンアクティビティへ変える必要性自体感じていない場合は、
(てか、モダンに合わせてルールや環境など諸々変更する前にAIが来るんじゃね？と思っている場合は)、面倒に感じるかもしれませんが、
オブジェクトリポジトリ自体はこれまでUiPathで開発してきた方にとってはすぐに馴染むもので便利さを感じるものだと思います。
今後は個人で活動する際は利用しますし、また、新しくUiPathを導入する所、企業単位か部署単位かは分かりませんが、ご縁があった場合は是非検討したいと思います。