こんにちは。UiPath Friendsコミュニティ運営メンバの @masatomix です。
イントロ
前回の記事「よくわかるモダンフォルダ(基本編)」でモダンフォルダについて記事を書きましたが、UiPath Orchestrator 上で出てくる用語や、それらのつながり(関連)など、いわゆる構成図的なモノをちゃんと整理していなかったので、今回は構成図を整理していきます。
だいたい、以下のスコープで整理しています。
- Orchestratorに出てくるリソース (マシン、ユーザ、パッケージ、フォルダ) などの全体の構成
- フォルダ内のリソースにスコープをあてた構成図
- モダンフォルダをグループで管理した場合の関連がわかる、構成図
ここでいう構成図とは、下記のようなものです。
こんな登場人物たちを整理しておこう、という備忘メモです。
記事の対象のかた
- 会社で UiPath Orchestrator(以下OC)が導入されててなんとなく触ってるけど、もうちょっと構成をちゃんと知りたいなー、って方。
- でも UiPath Academy やるほどでもないんだよなー、、という方。
前提の環境
| 環境の項目 | 値 |
|---|---|
| Orchestrator | オンプレのOrchestrator 2020.10.7 |
| Robot | UiPath Robot (v20.10.9) サービスモード (ロボット側は別に何でもOK) |
構成図： 全体像
まずは全体の構成図です。
大事なポイント
マシン、ロボット、ユーザについて
- ロボットの概念は「あるユーザがARやURを使える・使えない」などの設定レベルまで、簡略化された1。ロボットはもはや、あまり表に出てこない。(文脈によってロボットとかユーザって書きますが、ほぼ意味は同じ)
- したがって ロボットはアカウント単位で管理され、マシンごとには管理されない2。
- ただしUnattended Robot (UR)を動かしたいPCのみ「URはこの端末でうごかすよ」という追加設定(マシンキーという) が必要。
- マシンキーは「マシンテンプレート3」というのを使って、PC間で共有できるものになっている
- Attended Robotもこのマシンキー接続を用いてもよいが、対話型ログインという便利な機構を用いる方がシンプルでよい。
フォルダ、パッケージ、プロセスについて
- ロボットがパッケージ(=ワークフロー) を実行できるようにするには、ユーザとパッケージ双方をフォルダに紐付ける、という作業で行う。紐付いたパッケージをプロセスと呼ぶ
- ユーザは紐付いたフォルダ内を参照できるようになり、フォルダ内のプロセスを実行可能になる
- URとして実行したい場合は、追加で「このマシンキーはこのフォルダを参照可能」というマシンキーの紐付けが必要
- フォルダ内には複数のパッケージを配置可能だし、逆にパッケージも複数フォルダにリリース可能
- フォルダ内には複数のユーザを追加可能だし、逆にユーザも複数フォルダに紐付け可能
ちなみにURとマシンテンプレートなどについては、動画でまとめたことがあるのでご興味がありましたらどうぞ。
参考:
構成図：フォルダ内のリソース
先の全体像は、フォルダ内のリソースを少し省略して書いてあるので、それらにフォーカスした構成図がこちら。
大事なポイント
フォルダの配下には、おもにジョブとトリガーとアセットとキュー、そしてフォルダを配置可能です。
サブフォルダの機構
- サブフォルダは、フォルダのなかにフォルダを配置できる機構のこと。親フォルダのリソースへアクセス可能なユーザ達は、サブフォルダのリソースへのアクセスも可能という仕組み。図では「部外者用フォルダ」内のリソースへアクセス可能なのは
- フォルダBのユーザ user003～user005
- 直接紐付けた、user002
となります。
ご参考:
ジョブ、トリガー、アセット、キュー
- ジョブは、プロセスを動かしたときの記録で、プロセスを動かすことを「ジョブを開始する」という
- トリガーは、条件にしたがってジョブを開始する機能。一定時間ごとなど時間をトリガーにしたいわゆるスケジューラと、監視しているキューにデータが投入されたら起動する、キュートリガーがある
- アセットは、ワークフロー全体で共有したい情報をKey/Value形式でサーバに保管できる機能。情報はシステム全体で共通にもできるし、ユーザ単位に個別のValueを設定できたりします。
- キューは、大量のデータなどを複数のワークフローで手分けして処理するときなどに便利なデータを格納しておく領域です4。複数のワークフローがここからデータを取り出し、処理をしたい場合などに使います。
--2021/09/14追記--
アセットはシステム全体で共通にもできると書きましたが、注意点があるのでちゃんと書きます。
アセットは正確には「フォルダ名+アセット名」と指定するのが正しく、その前提でシステム全体で共通にすることはできます(アクティビティ上では、フォルダパスというプロパティでフォルダを指定する)。一方「フォルダ名を省略すると、実行しているプロセスがいるフォルダの、アセットが使われる」ため、結果、同じアセット名でも「実行されるフォルダによって、適用されるアセットが異なる」場合がありえます。。
後半だけ見ると、システム全体じゃなくて、フォルダ内で共通じゃん って思えてきますので、ご注意ください。
この仕様自体は、開発フォルダと本番フォルダでアセットの値を異なるモノにできる、など利用価値はいろいろありそうですが、クラシックフォルダ時にはなかった機能なので、考え方を変える必要がありそうです。
(OC2021でアセットのリンク機能というのが追加されました。これは別フォルダのアセットを「自フォルダにショートカットのように配置する」機能なのですが、これはOC2020から必須の機能だったと思います)
ちなみに、キューやアセットについてはかつてハンズオンをしたことがあるので、ご興味がありましたらどうぞ。
参考:
構成図： モダンフォルダへの紐付けをグループで行った場合
フォルダへの紐付けはユーザだけでなく「グループ」を紐付けることも可能です。
大事なポイント
ここで出てくる「グループ」ですが、オンプレのWindows認証環境下では「ADのグループ」、クラウドの場合はAutomation Cloud上で作成した「グループ」(デフォルトだとAutomation Usersとかが定義されてるアレです) などのことですね。
ユーザでなくグループを紐付けることで、そのグループに属するユーザをいちどにフォルダに紐付けることが可能になり、この図のとおり設定がとってもシンプルになります4。
グループの機能は、ライセンスのアサインやユーザの作成、ロールの継承など様々なところで管理を楽にするので積極的に使っていきたいですね。
以上、構成図のご紹介でした。いままで構成図を説明できてなくてモヤモヤしていたのですが、スッキリしました。
おつかれさまでした！
関連リンク
-
実際OC2021のARについてはアカウントを入れる欄すら、ない) ↩
-
もともと「フローティングロボット」として存在していた機構がデフォルトになった、ってこと。ログインアカウント nコ x PC m台 という膨大なロボットを作る、などの概念がなくなった。逆に、おなじWindowsアカウントで、ワークフローをPC単位で使い分ける、とかはできなくなっちゃったけどね。 ↩
-
マシンテンプレートも、フローティングロボットとともに昔からありましたが、クラシックフォルダの時はそんな普及していなかった ↩
-
なんかこうかくとアセットと何が違うのってみえますが、アセットは固定的な共有情報などを保管する目的のもので、キューは日々の大量処理データなどをココにため込んでおいて、ワークフロー達がここから順番にデータを取り出して処理をしていく、みたいな目的で使います。 ↩ ↩2