こんにちは。UiPath Friendsコミュニティ運営メンバの @masatomix です。
イントロ
前回の記事「よくわかるモダンフォルダ(イントロ編)」で、モダンフォルダを導入するための環境作りをしました。ロボットを使えるようにするための環境設定だったので、実質、今回からがモダンフォルダの内容です。
対象のかた・動作環境
- UiPath Orchestrator(以下OC)を使ってて、そろそろモダンフォルダに移行してもイイかな、くらいのナレッジの方を想定して書いています。
- 前回の記事を少しはやってみてくれた方
- 動作環境は、オンプレ版の Orchestrator 2020.10.7 と、ロボット(2020.10.x)を用いています。
--2022/08/16追記--
今日現在の最新版は、Orchestrator 2022.4.x となっています。
微妙に画面イメージ等が異なりますが、モダンフォルダの本質的なところは余り変わっておりませんのでご安心ください。
(仕様が変わったところはできるだけ明記するようにします)
--2022/08/16追記以上--
前提の環境
| 環境の項目 | 値 |
|---|---|
| Orchestrator | オンプレのOrchestrator 2020.10.7 |
| Robot | UiPath Robot (v20.10.9) サービスモード (実際はロボット側はなんでもよさげ) |
| Machine | PCとOCはマシンキーで接続 |
(今回あまり関係がないですが、Orchestrator 2019まではモダンフォルダ内ではURが管理できません。ご注意ください。)
ユースケース
部署が複数あって、使えるワークフローを制御したい
早速ですが、たとえば下記のような状況(ユースケース)を考えます。
上記のように、部署が複数あり、その部署の業務があり、その部署に属するユーザがいるとします。
ユースケースの制約としては、
- 自分の部署の業務はロボットで実行してもよい
- 共通業務は、UiPathを利用できるユーザなら、だれでも実行してよい
としてみます。よくありそうなユースケースです。
さてまずはクラシックフォルダでの運用方法を説明し、そのあとモダンフォルダでやってみたら、という流れで進めていきます。
クラシックフォルダだと
クラシックフォルダの場合は、ロボットグループをつかってロボットを分類し、グループにワークフローを紐付けるのでした。
Orchestrator 2018〜2019など、クラシックがデフォルトだった頃の構成だと、Default という一つのクラシックフォルダにロボットが配置され、それらを部署名のロボットグループで分類することになると思います1。
図示するとこんな感じ。
ロボットグループとワークフロー(=パッケージ)を「プロセス」で紐付けることで、どのロボットでどのワークフローが実行可能かが決まるのでした。この図の例だと「ロボット r001/r002 はワークフロー a001、ロボット r003 はワークフロー b001を実行可能」ということになるわけですね。
この考え方のもと、先のユースケースをOC上のリソース名で表現したのが下記の図です。
さて実際にOrchestratorを使ってセットアップしてみたので、画面を見ていきます。
ここではクラシックフォルダとして「classicFolder」というフォルダをつくっています。
ロボット一覧(classicFolder >> ロボット)
ロボットグループ列を見ると、ロボットがどのグループに属しているかを確認できます。
ロボットグループ一覧(classicFolder >> ロボットグループ)
パッケージ一覧(テナント >> パッケージ)
パッケージはフォルダ単位に管理されているのではなく、テナントに配置されています。
プロセス一覧 (classicFolder >> オートメーション >> プロセス)
ロボットグループとパッケージを紐付ける、プロセスの一覧です。パッケージ列とロボットグループ列を見ると、どのパッケージ(=ワークフロー) がどのロボットグループに紐付いているかを確認できます。
PC上でAssistantで見てみるとこうなる
さて実際にPC上のRobot Assistantで、上記のように紐付いているか確認してみます。
たとえば、r003のロボットのWindowsアカウントuser003 でログインしてみると、ロボットr003が属しているロボットグループ「部署A」「共通」に紐付いたワークフローだけが表示されましたね。
以上がクラシックフォルダを用いた運用方法です。
参考、というか制約
例として1つのクラシックフォルダで運用する方法を説明しましたが、このやり方だと、WEB画面にたとえばuser003でログインしてみると他部署のロボットも表示されてしまい、権限によっては操作できてしまいます。
これが気になる場合は、部署A、部署Bというクラシックフォルダを作成し、ロボットをそれぞれのフォルダに作成する運用方法もあります。
ただロボットはクラシックフォルダ間を移動できないので、部署異動によるロボットの変更などを考えると、ちょっと微妙な運用方法かも知れません。
モダンフォルダの運用
さてモダンフォルダです。 まず特徴を書いていきます。
特徴1: ロボットとパッケージを紐付ける(クラシックフォルダのロボットグループの役割)
モダンフォルダはクラシックフォルダでいうところのロボットグループの役割を持っています。フォルダとして
- 部署Aフォルダ
- 部署Bフォルダ
- 共通フォルダ
などを作り、フォルダにユーザ(=ロボット。後述)やワークフロー(=パッケージ)を紐付けることで、ロボットが紐付いたフォルダのワークフローを利用できるようになるという仕組みです。
図示するとこんな感じです。
この図の例は「ユーザ user001,user002,user003 はワークフロー a001とcommon001、ユーザ user004,user005 はワークフロー b001,b002,common001を実行可能」ということになります。
このように、あるユーザが複数のフォルダを参照する(紐付ける)ことももちろん可能ですし、またあるワークフローを複数のフォルダに配置することも可能です。2
特徴2: ロボットを明示的に作成しない
モダンフォルダでもう一つ重要かつわかりにくいのは、明示的に「ロボット」を作成しない(作成できない)ところですね。OC上にユーザを作成し、そのユーザにロボットを関連付けるという操作になります。
先に出てきたフォルダへの紐付けも、実際はロボットではなくユーザを紐付ける操作になるので、下記の通り、図示してもロボットという概念があまり出てこない感じ、になります。
フォルダと、ユーザ、ワークフローの関係
参考: ユーザ作成画面でロボットを紐付けている図。
この「ユーザとロボットを同一視する概念」を理解できると、モダンフォルダはとてもシンプルな機構に感じられるかも。慣れるとクラシック運用の個別のロボ作成がめんどくさく感じるようになります :-)
特徴3: ユーザの権限(ロール)をフォルダごとに変えられる
クラシックフォルダではできなかった、OCの画面にログインしたとき、ユーザに対して「フォルダAではただの一般ユーザね、フォルダBでは管理者ね」といったことが可能になりました。具体的にはユーザに対して
- そのユーザにテナント全体の権限を設定する「テナントロール」
- そのユーザにフォルダごとの権限を設定する「フォルダロール」
を設定できるようになりました。
テナントロールを割り当てている
フォルダロールが割り当てられている
このフォルダロール機構で「フォルダAではAutomation Userロール、フォルダBではFolder Administratorロール」を付与することで
- フォルダAでは、ワークフローを実行できるだけ
- フォルダBでは、管理者としてユーザを追加したり、アセットやトリガーを設定できたり
とかができるようになりました。
特徴4: 階層構造を使った権限の継承
つづいて階層構造についてです。モダンフォルダはクラシックにはできなかった、フォルダのなかにサブフォルダを作って階層構造をつくることができます。たとえば
- root/部署Aフォルダ
- root/部署Bフォルダ
などと階層構造をつくり、
- root フォルダに「管理者ユーザ」を紐付ける
- root/部署Aフォルダに「部署Aの部員ユーザ」を紐付ける
- root/部署Bフォルダに「部署Bの部員ユーザ」を紐付ける
なんて事ができます3。
階層化されたサブフォルダは、親フォルダの権限を継承する 仕組みなので、rootにいる「管理者ユーザ」は、サブフォルダ「部署A」「部署B」にも紐付けたことになります。
この継承機構を使えばたとえば、「部署B」フォルダの下に「部外者フォルダ4」を作成し、部外のユーザを紐付ける、などができます。
こうすると「部署B/部外者フォルダ」のワークフローは、部署Bフォルダのユーザと「ひもづけた部外のユーザ」が使えるわけです。
クラシックフォルダ運用だとこのケースは、ワークフローを「部署B」「部外者」グループそれぞれに紐付ける必要がありましたが、すこしだけ便利になりました。
特徴5: グループを使った、権限の継承
最後です。
今回、詳細は割愛しますが、フォルダへの紐付けはユーザだけでなく「グループ」を紐付けることも可能です。この「グループ」ですが、オンプレのWindows認証環境下では「ADのグループ」、クラウドの場合はAutomation Cloud上で作成した「グループ」(デフォルトだとAutomation Usersとかが定義されてるアレです) などのことですね。
ユーザでなくグループを紐付けることで、そのグループに属するユーザをいちどにフォルダに紐付けることが可能になり、下記の図のとおり設定がとってもシンプルになります5。
ユーザの異動時も、AD側で移動させれば紐付くワークフローも変わる、そんな便利な運用が可能になります。
先のユースケースをモダンフォルダでやってみるとこうなる
さて先のユースケースの設定をおこなったOrchestratorで、画面を見てみましょう。
ユーザ一覧 (テナント >> ユーザ)
ユーザはテナントという全体の領域に定義されています。登場するユーザたち(user001〜user005)を登録してあります。
ためしに user003を見てみます。 user003 右の点々メニュー >> 編集 を選択。
ロールは「Allow to be Automation User」を設定してあります。ロールはまたどっかで記事にしたいですが、とりあえずこのロールを選んでおけば「Automation User」にはなれるようですね。このロールは Attended Robot (AR) を利用するのに最低必要な権限をもったロールです。
さて右矢印をクリックして次画面へ。
次画面は、このユーザでARを利用可能とする設定がされています。
さらに次画面はURを使えるかですが、今回はいったんOFFにしてあります。
参考: [UiPath] よくわかるUnattendedロボット(イントロ編)
このユーザが持っている権限情報を見てみましょう。user003 右の点々メニュー >> 「権限を確認」を選びます。
テナント全体として、先の「Allow to be Automation User」ロールが割り当てられ、後に紐付ける「共通」「部署A」フォルダについて「Automation User」というロールが割り当てられていることが分かります。
パッケージ一覧(テナント >> パッケージ)
これはクラシック・モダンどちらも同じ定義を使用しますので、画面は割愛。
フォルダの定義情報
つづいてフォルダごとの定義情報を見ていきます。
テナント >> フォルダー >> フォルダ名
選択したフォルダに紐付いているユーザの一覧です。
- 部署Aフォルダ
user001,user002,user003 が紐付いていることが分かります。それぞれのユーザに「Automation User」というロールが割り当てられていますね。(赤枠が共通についてますが、間違ってますゴメンナサイ。。画面自体はあってます)
※本筋からはずれるのでさらっと流してもらっていいですが、親フォルダrootに「System Admin」というユーザを紐付けています。そのためrootのサブフォルダたちにも、このユーザが紐付いていることが分かります(rootから継承と書いてあるところです)。
- 部署Bフォルダ
user004,user005 が紐付いていることが分かります。
- 共通フォルダ
user001〜user005 が紐付いていることが分かります。
メニュー部の フォルダ名 >> プロセス
以上「選択したフォルダに紐付いたユーザ」を見てきましたが、ここからは「選択したフォルダに紐付いたプロセスの一覧」です。
各部署が利用可能なワークフローが紐付いている事が分かります。
- 部署Aフォルダ
- 部署Bフォルダ
- 共通フォルダ
さて、PC上のRobot Assistantでどう見えるかを確認してみます。
クラシックの時と同じように試しにuser003 でログインしてみると、、モダンフォルダ運用でもおなじ結果が得られましたね！
まとめ
設定操作などの具体的な手順は省略しましたが、モダンフォルダの構造の基本をご説明いたしました。
モダンフォルダにすることで
- ユーザとワークフローをフォルダに入れると、そのユーザがそのワークフローを実行できるという直感的なわかりやすさ
- ユーザを作るだけで明示的なロボット作成作業が不要
- 階層構造を使った権限の継承
- グループを活用することで、運用の負荷を下げられる
などのメリットがあることが分かりました。
まあ、階層構造のフォルダが作れることよりも、直感的な仕様になったこと、ユーザ作成=ロボット作成 であること、今回触れませんでしたがロボットをマシンごとに作らずユーザ単位で作るようになった6 ことがメリットといえそうです。その他、
- 個人ワークスペースによる、個人のスペース機能(そこにPublishしたら本人のみワークフローが使えるという領域)
- フォルダ単位のパッケージ機能
- 対話型サインインによる、マシンキー管理からの解放(Attended Robotのみだが)
- 対話型サインインによる、Windowsアカウントとの強い紐付けがなくなった(これは統制面で一長一短ありそう)
など色々なことが起きているのですが、まずは今回の内容を押さえておくとよいと思います。
今回は基本編でした。
次回、部外者フォルダなどを作ってみる具体的な操作などをやってみようとおもいます。
おつかれさまでした！
関連リンク
- よくわかるモダンフォルダ(イントロ編) 前回記事。
- UiPathモダンフォルダ設計Tips 安定の遠藤さんの設計Tips。参考にさせてもらいました！
- UiPathクラシック/モダンフォルダの違いや移行について おなじく遠藤さんコンテンツ！
- モダン フォルダーを使用する 公式
- クラシックフォルダーからモダンフォルダーへの移行に関する検討事項
-
運用設計上は、ロボットは「部署」で分類？いや普遍的な「業務」で分類じゃん？など、相当いろいろな議論があったりしますが、今回はシンプルに部署としました ↩
-
ロボットグループの運用だと「複数のロボットグループから同じ名前のパッケージを紐付けようとするとエラー(ワークフロー名がかぶるので、どっちを使ってイイか分からなくなるから)」になりましたが、モダンフォルダで改善されました。複数バージョンのワークフローが配布され、実行時どちらのフォルダのワークフローを使うか、明示的に指定するようになりました。ものすごく地味な変更なのですが、一番おどろいた改修かも。 ↩
-
はじめrootフォルダはなくてもイイかなって思ったのですが、中のヒトもつくったほうがイイよとおっしゃっていて、必須じゃないけど便利なので取り入れた説明にしました！長いものには巻かれるのです ↩
-
原則は部署B所有のワークフローだけど、一部の部外者も使ってイイワークフローをいれておくフォルダ ↩
-
ただしグループ単位の紐付けはAttended系ロボットだけなのでご注意 ↩
-
これはモダンフォルダっつうよりフローティングロボットを使う恩恵で、クラシックでも使えましたけどね ↩