StudioXでの「疑似ライブラリ化」について
2/23にRPA communityのイベントで開催されたこちらのイベントで登壇した内容をnoteでも共有させて頂きます！
RPAの保守運用～UiPath Talk～
まず私hawkはUiPath支部として関わらせて頂いたイベントとしては2回目になりまして、登壇としては今回が初めてのイベントとなりました！
ネタはしっかり決まってましたし、スライドもしっかり準備することは出来ましたが、UiPath支部での初ということで割かし緊張しながらの発表でした
一度RPA communityの通常LT会で発表した経験がありましたので、発表自体は抵抗なくできましたが、今回は技術的な側面が強いという事で、なるべく初心者の方やこれからUiPathを触れていく方にもわかりやすい内容を意識してスライドや発表内容をまとめたつもりです
そういった方向けに参考になると良いなと思ってこのnoteを書かせて頂いております
では早速発表内容に移ります
今回のイベントのテーマが「保守運用」ということでしたので、それに関連する内容を選んでの発表をさせて頂きました
タイトルは
StudioXでの「疑似ライブラリ化」について
です
最初にUiPathにおける編集ツールについての説明です。
UiPathの編集ツールは大きく分けて「Studio」と「StudioX」の二つが存在します。
※スライドのスペルがフォントの関係で表記が全て大文字になってしまっていますが、今後表記する正しいスペルは「Studio」と「StudioX」が正式な表記となっております
Studioは出来ることがかなり豊富で多機能となっていますので、主にはエンジニアの方が開発することを想定した作りこみがされているツールとなっております。
その一方でStudioXは出来ることがシンプルで一部に使える機能に制限がある事から市民開発者向けと言われています
※市民開発者とはエンジニアではないけど自動化を試みたいといった非エンジニアの方を差します。
UiPathやRPA界隈全般的に市民開発者の方も増やそうという目論見があると思われますので、そういった方が参入しやすくかつ使いやすいツールにする為にもツールを分けていると思われます
今回はこの内StudioXについてピックアップして話を進めていこうと思います。
まず始めになぜStudioXを使うかという事についてですが、これにはいくつか
の理由があります
1つ目にライセンスの問題です
Studioは企業で導入するとなるとライセンス費用が当然の事ながら発生してきます。ライセンスの費用が具体的にいくらかになるかはここでは割愛しますが、それなりのコストがかかる為、たくさんのライセンスを使用するとなった場合、企業にはそれなりの負担がかかることになります。
組織でライセンスを取得した場合、その組織に紐づいてStudioXが使用できるライセンスが25ライセンス分付与されます。
ですので
・とりあえずRPAツールを何か使ってみたい
・エンジニア程のプログラミングなどの知識はないけどUiPathを利用してみたい
・UiPathの運用だけ使用したい
などの用途として企業で導入したい場合、これだけたくさんのライセンス数を確保できるのでStudioXを使用する理由としてはこれが一番大きいかなと思います。
2つ目に野良ロボット対策についてです。
野良ロボットとは、いわゆる「勝手に動作している野放しになっているようなロボット」の事を差します。
想定されるパターンとしては、前任者がいなくなったりしてどう動いているか分からなかったり、自動化で今まで動いていたけど作成した事が忘れられて勝手に動いてしまっているような困ったロボットなどが挙げられます。
UiPathにはOrchestratorという大元の管理者が全てのロボットを管理出来るツールがあります。上記のような野良ロボットが無いよう常に監視・管理することが出来るのでこちらもメリットとなると思います。
3つ目に、出来ることを制限することで逆に開発をしやすくするという目的があります。
Studioは高機能ですが、始めて開発を行う人にとっては全ての機能や使い方を習得するのかかなりハードルが高いです。
そこで機能を絞ってシンプルな振る舞いでロボットを作ることが出来るStudioXを使うことで市民開発者にとって逆に使いやすくしているという側面があると考えます。
ここで少し話を変えまして今回の主題であるライブラリについての説明です。
ライブラリというのは、特定の機能のまとまりや頻繁に使用するコードを共通部品として切り出して、コードの使いまわしをしやすくする為の仕組みを差します。
一般的なプログラミング言語でいうところの関数化やメソッド化と言われるものに非常に近いかと思われます。
UiPathではこの部品単位での扱い方をライブラリという呼び方で機能が搭載されているのでそれを活用することが出来ます。
このライブラリは一度作ってしまえば、同じ部署などのチーム内で共有して使うことも出来るので、非常に強力な機能の一つと言えます。
次になぜライブラリ化する必要があるかという話です。
例えばですが、全く同じ機能のコードやアクティビティを毎回コピペを使って実装していた場合、もし何かのタイミングのその箇所に不具合が出た場合、またはアップデートなどのタイミングで動かなくなってしまった場合、コピペしていた箇所全てを修正する必要が出てきます。
しかし、共通部品の所をライブラリ化しておけば、そのライブラリだけ修正するだけでライブラリを使用していた全てのロボットに同時に適応することが出来るので、とても開発効率を上げることが出来ます。
結論としましては、ライブラリ化(部品化)出来るものは基本的にはした方が"保守性"が上がると言えます。
保守性が上がることで開発者個人としても、チーム全体としても開発・運用しやすいロボットが作成出来る事になります。
また今回のイベントのテーマが「保守運用」ということでしたので、その点を踏まえて今回このネタを選ばせて頂きました。
ライブラリ化をした方がいい機能の候補についてですが、以下のようなものが挙げられます。
・毎日一度は行っているようなログイン処理
・ログの掃き出し(特に部署でやり方が決まっている場合があるなど)
・毎回同じタイプのレポートやファイルをダウンロードするような処理
これらは総じて"全く同じ処理を別のロボットでも使用する可能性が高いもの"と言い換えることも出来ると思います。
しかし、ここで大きな問題が発生しました。
Studioにはもちろんここまで説明したライブラリを作成する機能が標準搭載されていますが、StudioXでは標準では搭載されておりません。
これは最初にも説明した通り、StudioXは機能が制限されているという点の一つに挙げられると思います。
ですので、それに代わる手段として
・スニペット(小さなコード単位での使いまわしが出来る機能)
・サブのワークフローの呼び出し機能
が挙げられます。
スニペットは開発を進めていく上で一般的によく使われる機能をアクティビティ単位で作ったものがよく活用されます。
こちらはUiPathのマーケットプレースでもたくさんのものが共有されており、先人に知見を活用して開発を効率化して行う事が出来ます。
しかし、このスニペット機能はStudioXではメニュー画面で表示されていないのでそもそも使うことができません。。(これもまた機能が制限されている点に挙げられます)
次に先ほど挙げたサブのワークフローの呼び出しについてですが、こちらはStudioXでも使用する事が出来ます。
使用するには作成しているワークフローと同じ配下にサブのワークフローを配置することで実現可能です。
ただここでも難点がありまして、、
・Studioではメニュー画面でサブのワークフローが一覧で表示されるが、StudioXではそれを表示する機能がない
・Studioでは同じ画面でサブのワークフローを別のタブで開いて編集可能ですが、StudioXではそれができない
といった点があり、StudioXで使用するにはあまり使い勝手が良くないです。
これは困った！！
何か他にいい開発のやり方は無いものか。。と嘆いていた所、とあるRPAの詳しい部署からこんな機能が使えるのではないかという提案がありました。
それはライブラリの代わりとして「プロセス呼び出し」という機能が使えるのではないかという事です。
UiPathでは一つ一つのワークフローをパブリッシュ(作成完了したロボットとしてOrchestoratorの実行環境に吐き出すこと)をすることで、プロセスという単位で個々のロボットを実行・管理出来ます。
このプロセスという単位を部品として扱うことで、疑似的にライブラリと同じことが出来るのではないかという提案を頂きました。
ちなみに一般的にプロセスというと、ターミナル画面でのプロセスIDを思い出される方も多いかと思います。
私も最初はプロセスというのはここの事を指しているのだと思い、ターミナルでプロセスIDを調べてその番号などを使用して動かすのかと勘違いしていて、それでプロセス呼び出しが使えずに四苦八苦してしまった経験がありました。
ここで一つTipsです
「プロセス呼び出し」の機能はStudioXの最初の設定のままではアクティビティが表示されません
そこでアクティビティ一覧のフィルターの所で「開発者」というフィルターをオンにすることで画像のように「プロセスを呼び出す」の機能が使えるようになります
この機能に限らず、開発者フィルターをオンにしないとStudioXでは使えない機能は多数あります。
これは最初に出来る機能を絞ってはいるものの、もっと高度な事をStudioXでも実現したいとなった時にオンにすることで使用可能となります。
ただし一点だけ注意が必要でして、これは開発者のカテゴリは主にStudio向けに設計して作られているものになります
なので、StudioXでこれらの機能を使用した場合、思わぬ所でバグなどが発生する可能性が一応あります。
これはUiPath公式でも正常に全部動くとは保証していない点になる為、使用する際はその点も考慮に入れた上で活用してみて下さい。
では実際のデモ動画を使ってプロセス呼び出しのやり方を説明したいと思います
デモでご説明した通り、「プロセス呼び出し」を使用することで疑似的にライブラリ化(機能の部品化)を実現することが出来ました！
これで修正やアップデートに強い保守性の高いロボットが作成できたと言えます。
今回のデモではログを出力するだけという非常に簡単なロボットでしたが、これを応用すればどんな機能であっても部品化したいものを疑似的にライブラリ化することがStudioXでも実現可能になったと言えます。
Happy UiPath Life！
ということで今回の発表した内容の共有を終えたいと思います。
この内容が良かったと思って頂けた方はいいねや同じような事でお困りの方がいらっしゃった場合はぜひシェアして情報を伝えて頂ければと思います。
UiPathは非常に強力で使い勝手の良いツールだと自分自身も感じています。
RPAのエンジニアだけでなく市民開発者が増えていく事は、今後の日本全体を考えても必要な事だと考えていますので、このスライドがそういった方が増えるキッカケになれば幸いです。
ここまで長文をお読み頂きありがとうございました。
これで発表した内容は以上になります。
もし少しでも為になったという方いましたら、投げ銭などして頂けますと今後の励みになりますので大変助かります。
記事に関する質問などありましたら、ぜひXの方でお尋ね下さい！
https://twitter.com/codinglife4
この記事が気に入ったらサポートをしてみませんか？