7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

UiPath Advent Calendar (produced with UiPath Friends)Advent Calendar 2021

Day 13

[UiPath] Orchestratorバージョンアップ時の検討事項(よくわかるモダンフォルダ番外編)

Last updated at Posted at 2021-12-12

この投稿はUiPath Advent Calendar (produced with UiPath Friends) Advent Calendar 2021 の13日目の投稿です。この前の記事は【Uipath】ユーザー操作が必要なアクティビティを並列アクティビティで自動操作するです。

イントロ

こんにちは。UiPath Friendsコミュニティ運営メンバの @masatomix です。

ここ最近、いくつかのOrchestratorバージョンアップ案件に関わっています。オンプレの2018.xや2019.x 系を、 2020.10系にするプロジェクトが多いですね。

さていままでモダンフォルダについていくつか記事をかきましたが、実戦でモダンフォルダを導入してわかったこともあるので、あらためて情報を整理しておきます。ついでにバージョンアップまわりのトピックもいくつか。

最終的には「バージョンアップ時の検討事項」みたいな内容になればいいなとおもってます。

クラシックフォルダからモダンフォルダへの移行方針の整理

はじめにクラシックからモダンへの移行方針を整理しておきます。定石は

  • クラシックフォルダと同名のモダンフォルダを作って、そのなかにロボットグループ名のサブフォルダをつくる

ですね。ただしクラシック運用の時にフォルダをひとつ(Defaultのみ) で運用していたばあいは、もっとシンプルにロボットグループ名のフォルダ群を作成する、でよいとおもいます。

参考: [UiPath] よくわかるモダンフォルダ(基本編)

rootフォルダはつくるべきか

続いてこのはなし。

root

このようにrootフォルダをつくって、各フォルダはその下に配置するかについて。結論をいうと「rootフォルダは作った方がよい」でしょう。モダンフォルダ使い始めは「どっちでもイイかな」と思っていましたが、特にフォルダが多い場合は作った方が無難です。

理由は「全フォルダに一括でユーザを追加したいケースが結構ある」から、です。
フォルダって基本「フォルダを作成したユーザ」が Folder Administrator ロールになるのですが、そのままだと(当たり前ですが)他のユーザが参照できないんですよね。なのでフォルダを新規作成したらかならず、そのフォルダに「プロセスリリース担当者」的なユーザを追加する必要があります。
また「プロセスリリース担当者」的な役割のユーザが増えたり減ったりしたときも、各フォルダに対してそのユーザを追加する必要があります。

rootフォルダがあれば、rootフォルダに対して作業をすれば、サブフォルダにもそのユーザやロールは反映されます。フォルダを新規作成してもrootのサブフォルダであれば作業不要だし、ユーザを追加・削除する際はrootフォルダへの作業だけで十分となります。

まあフォルダの運用が「完全にフォルダごと(図中だと部署ごと)に別々」です、などであれば、このメリットは薄いかも知れませんが、原則rootフォルダは作っておいた方がよさそうですね。

もう一つの理由としては、監視タブでサブフォルダも含めて表示することで、フォルダ内に散らばったプロセスの状態などを一度に確認することができたりします。

監視

スケジューラはどうやって見ればイイの(未解決)

ちなみに、このやり方でもスケジューラ(トリガー)はいちどに確認できないんですよね。

クラシックフォルダのときもフォルダ管理していた場合は同じだったと思うんですが、モダンフォルダになって「あのトリガー、どのフォルダに定義してたっけ?」ってなるんですけど、皆さんどうしてるんでしょう。。。識者の方ぜひともコメントをください。

AR/URフォルダはつくるべきか

次はコレ。階層が結構深くなるのが微妙なのと、そもそもプロセスが少量なら作らなくてもいいような。ARもURも使うワークフローは両方におくのか?とかもありますし。Robot Assistant からUR用ワークフローが見えるか否かくらいの効果ですので、それを重要とするならやってもイイかも。

階層ってのはたとえば元が「クラシックフォルダA」の「ロボットグループB」の「プロセスC(UR用)」のであった場合「 root / モダンフォルダA / ロボットグループB / UR」にプロセスCを配置する、となるわけですね。

subsub

アセットの置き場所は?

続いてアセット移行です。アセットって「キーを指定したら一意にデータを取得できる仕組み1」なのですが、アセットってシステム全体で一意ではなくて、フォルダ単位で一意なんですよね。同じキーでもフォルダが違えば別のデータってことです。

クラシックフォルダ一つ運用をしていた場合

クラシックフォルダ一つで運用していた場合は、アセットがシステム単位かフォルダ単位かあまり意識しないので、アセットは「システムで一意」とおもってしまいがちです。ロボットグループが異なるロボットたちも「同フォルダ内なのでアセットは共通」でしたしね。

しかしながら、ここまで記述した移行方針だとモダンではロボットグループがサブフォルダになっているので、それらロボットは別フォルダにいるロボットとなります。ワークフローはデフォルトでは、呼び出されたロボット(正確にはプロセス)が存在するフォルダのアセットを参照するので、フォルダごとにアセットを置いちゃえばイイのですが、同じ値のアセットをフォルダごとに設定してまわるのも本末転倒で、このやり方は避けたいですね。

あらためて「システム全体でアセットを一意にしたいんだけど、その場合どう設定すんのさ」ですが、クラシックと違いモダンフォルダは他のフォルダのアセットも参照可能なので(他のフォルダへのアクセス権限さえあれば) 、

  • 「root/共通」などのフォルダを作って、アセットはそこに定義する
  • そのフォルダを各ロボット(を保持するユーザ)を紐付けて、参照可能にする
  • 各ワークフローがアセットを取得するときに、アセット名だけじゃなくてフォルダパス「root/共通」も指定する

folderpath

とすればOKです。ワークフロー側の対応も必要となるのですが、クラシックフォルダ一つで運用していた場合は、上記のようにすれば、今までとほぼおなじ運用でいけるとおもいます。

最初に書いたとおりワークフローの改修を避けるためにフォルダ毎にアセットを冗長に置いてしまう、という考え方もありますが、冗長な配置となりますのであまりよろしくないでしょう。

もともとクラシックフォルダでフォルダ複数運用だった場合

逆に、クラシックでフォルダごとにアセットを分けていた勢は、

  • アセットはフォルダごとに定義する(今までと同じ)
  • 各ワークフローでは、アセット名だけを指定(フォルダパスを指定しない)。つまり今までと同じ

でOK。ワークフロー側でフォルダパスを指定しなければ、呼び出されたプロセスが存在するフォルダのアセットを参照するようになっているので、これでいままでの運用と同じコトが実現できますね。

クラシックのときからフォルダを複数つくっていた場合は、アセットはフォルダごとって感覚がすでにあるでしょうけど、ロボットグループの階層がサブフォルダとなるため、先ほど(フォルダ1つ運用)と同様の改修が必要です2。つまり、

  • 「root/FolderA/共通」などのフォルダを作って、アセットはそこに定義する
  • そのフォルダを各ロボット(を保持するユーザ)を紐付けて、参照可能にする
  • 各ワークフローがアセットを取得するときに、アセット名だけじゃなくてフォルダパス「root/FolderA/共通」も指定する

まとめると

  • アセットはフォルダ単位で、システム単位じゃないのでご注意
  • OC上のアセットの配置場所はいままでの運用を考えて要検討(一箇所に集めるか、各フォルダに冗長に置くか)
  • ワークフロー側の対応も、工数ふくめて検討しないと3

などを考えて、アセットの移行先を検討しましょう。

蛇足: そもそもクラシックか、モダンかってのは本筋じゃなくて

ここまでモダンフォルダ移行にフォーカスして話してきましたが、 [UiPath] よくわかるモダンフォルダ(基本編) にも書きましたが、モダンフォルダ移行で大きいのは、クラシックかモダンかよりも

  • ロボット作成方法が「フォルダごとに手動で作成する」か「自動(ユーザに紐付いてロボットを作成する)で作成されフォルダに紐付けする」か
  • ロボットが「標準ロボット」か「フローティングロボット」か

この二点だと思います。あ、一応ですがフローティングロボットっていうのは、いままでの標準ロボットは「マシン+Windowsアカウント」で一意になるように作成していたのに対して、フローティングロボットは「Windowsアカウント」で一意になるように作成するロボットのことです。

この変更によって

  • ロボット作成が超絶ラクになった。最大、PC数xアカウント数のロボットを手動作成していたのが、アカウント数分だけで済むようになった
  • 標準ロボットの概念でいう「フォルダをまたいだロボットの移動」ができるようになった。
    • クラシックではフォルダをまたげなかったので、その場合作り直しとなっていた
    • モダンではユーザを別フォルダに紐付け直せば良いだけ

など、目に見える良いことがあるのですが、いくつか制約事項も出てきます。

  • ロボットごとのアセットが、ユーザごとのアセットになった
  • PCごとに配布するワークフローを変えたいが、できなくなった

などは、場合によっては制約事項になりそうですね。

制約: ロボットごとのアセットが、ユーザごとのアセットになった

フローティングになってロボットの単位がマシン+アカウント単位ではなくなったので、いままで「おなじWindowsアカウントで別のPCにログインしたとき、アセットの値を別の値にする」ことが可能でしたが、モダンだとできなくなりました。Windowsアカウントが同じなら、どのPCでログインしてもアセット値は同じ値しか設定できない、となります。

ちなみに今まで「それはこまる」って話はあまり聞いたことはありませんが、、。

assetbyuser

制約: PCごとに配布するワークフローを変えたいが、できなくなった

同じような話でクラシックでは「同じWindowsアカウントでもPCが違えばロボットは別」だったので、それらのロボットを別のグループに入れる事で「おなじWindowsアカウントでも、PCによって配布するワークフローを変える」コトができました。

あるAさんがxx部PCでログインしたときとyy部PCでログインしたときで、xx部のロボットグループ、yy部のロボットグループからそれぞれ別のワークフロー群を配布してもらうことができていました。これはやりたいと思うんですが、、、、できなくなりました。

既存運用から移行すると「あるAさんが使用しているロボットは一つになって、複数のサブフォルダ(=元々ロボットグループだったモノ)に紐付ける」ことになるとおもいますので、結果、それらサブフォルダがもつワークフローがPC関係なく全て配布されます。

先の例だと「AさんがどのPCでログインしても、xx部向けフォルダ、yy部向けフォルダ両方からワークフローが配布されちゃう」事になります。これは場合によっては結構うっとうしいかもしれませんね。

良くなった点もう一個

そうだ良くなった点もう一つ。クラシックでは、あるおなじワークフローを複数のロボットグループから配布してもらうことができなかった4のですが、それができるようになりました。あるロボットが複数のフォルダを参照可能なとき、それぞれのフォルダからおなじワークフローを配布することができます。バージョンが異なっていてもOKです。

ロボットグループの運用で「ん、なんでエラーになった?」ってコトが時々あったのですが、モダンフォルダになってこの点はとっても直感的になりました。

assistant

というわけで、クラシックとモダン、そこだけ見るとできるコトに大差はないのですが「標準かフローティングか」「ロボが自動生成か」によって、いくつか制約はあるのもの、とても使いやすくなったと思います。

蛇足: その他バージョンアップで感じたこと

その他バージョンアップで感じたメリットやデメリットなど、書きたいことが盛りだくさんなのですが、時間の都合であらためます。概要だけ書いておきますので、お楽しみに!

  • マシンキー管理が相当楽になった
  • ロールは相変わらず、わかりにくい
    • テナントロールとフォルダロールの概念をちゃんと周知徹底してほしい
    • が、フォルダロールができたことで、フォルダごとにロール制御できるのはよい
  • いつのまにか、ユーザモードでのインストールが主流となっている(ARのみ)
    • 2018系まではデフォだったサービスモードでのインストール方法を変えるって、結構な変更だと思うんだが。ちゃんと周知徹底して欲しいなぁ。マシンキー設定をPCごとじゃなくて、ユーザごとにやるってコトだよ??
  • ユーザモードにしても、対話型サインインがあるからダイジョブって思ってる?
    • わたしが知ってるOrchestrator導入会社さんの運用設計は「OCいじる人は最小限。ほとんどStudio/Robotしか使わないよ」なので対話型サインインは流行らない。てか、そもそもそういう運用設計なので「ロボ作るために、OCユーザ作ってください」も最初は拒否反応が出ちゃう。
    • 個人的にはめっちゃ好きですよ。対話型サインイン。とくにアカウント管理をWindows認証をいれたときのシームレス感は完成系といえる
    • ただしコンプラ的にはどうなんでしょ(参考:対話型サインインとマシンキー )
    • マシンキー接続と対話型サインインのロボット特定の挙動が違いすぎるので、表でまとめないとヤバいレベル(さすがに記憶できないのでまとめた)
  • 個人用ワークスペースの使用可否は、、うーん原則NGかなぁ
    • デバッグ目的だと「ちゃんと配布したモノで動かした」という安心感がとっても大きいが。
    • 個人でワークフロー実行出来ちゃうと、なんのためのOCかよく分からない(野良ロボ統制の件はどこいった)
    • かつ、StudioのPublish先がデフォルトで「個人」の方になっちゃうので、多分事故がたくさんおきる(パブリッシュしたのにでてこないーって。)
  • これらあぶり出された課題めいたものが、OC2021で結構改善されている(アセットのリンク機能とか、ロールの分類とか、ユーザグループの導入とか)
  • Orchestrator Managerを使おう
    • ガッツリ活用させていただきました。同じようなツール使ってたけど、さすが謹製ですね。
    • バージョンアップやデータ移行はもちろん通常の運用でも活用してよいんじゃないかな
    • 上で書いて未解決だった「トリガーの一覧」も作れる

以上、おつかれさまでした。

関連リンク

  1. ロボットごとアセット、ってのもあるけど一旦無視して続けます :-)

  2. 取り消し線で記述している対応でいけるケースは、モダンフォルダに移行する際、ロボットグループのサブフォルダを作らなかった(わりとレアな)ケースでした。大変失礼しました

  3. 「ワークフローはいじりたくないので、冗長になるけどアセットをフォルダごとに置いちゃえ」とか、修正工数と保守性の天秤で決まることもありますからね

  4. あるロボットがグループAとBに属していて、グループAがワークフローxを配布済みだと、グループBでワークフローxを配布しようとするとエラーになる。別バージョンだからダメとかでなく同バージョンでもダメ。

7
3
0

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
7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?