LoginSignup
10
7

More than 3 years have passed since last update.

UiPath Orchestratorに接続されたRobot のライセンシングについて備忘(Unattended版)。

Last updated at Posted at 2019-07-10

概要

UiPathのOrchestrator(以下Orch)導入でいつもややこしい、ライセンスの種類の件について:
https://robot.uipath.com/lang-ja/v2018.4/docs/about-licensing
このサイトの情報の備忘です。

前回は Attended Roboについて書きましたので、今回は、Unattended Roboについて。

この情報は2019/06/30時点のモノであり、誤りもあるかもしれません。したがって信頼性のある情報が必要な場合は、UiPathの中のヒトにお問い合わせください。また対象バージョンは、UiPath 2018.4.5 です。

TL;DR

  • Unattended なロボットは購入したライセンス数分と同数のマシン上で稼働させることが可能で、そのマシン上に複数のロボット(Windowsアカウントをわけるってこと)を作成することは可能
  • たとえば業務ごとにロボットグループを作って、それぞれにWindowsアカウントを用意し、ある1PC上に複数ロボットを作成して、いろんなワークフローを運用することが可能
  • 2ライセンス購入して3台のPCで同時利用、などはできない
  • ジョブを実行中に他のジョブを投入すると、保留中でキューに入る。そのキューはロボット・プロセスごとに1つだけ保留になる
  • 大量にキューさせるためには、動的に割り当てを用いる
  • 1ロボ内では、処理順番は投入順になっているように見えるが、複数ロボが稼働する場合は注意が必要(後述)

備忘メモ

  • Unattended なロボットには、2018.4には「同時接続ランタイム (Concurrent Runtime)」というライセンス形態しかなさそう。Node Locked などはないようです。
  • Unattended は「ロボット」を作成した時点でライセンスが消費される。でも消費は「ロボット」ごとではなく「マシン」ごと。つまり、同じマシン内にいくつものユーザで「ロボット」を作っても、消費されるライセンスは一つ1
    下記は、おなじマシンにいくつもUnattendedなロボットを作成している図
    image.png
    1ランタイムに、ロボットが3つぶら下がっていますと書いてある
    image.png

  • さらに、ライセンスを消費ずみでもライセンス数を超えるマシン数のロボット作成が可能
    下記の図は、このテナントはUnattendedのライセンスは1つなのですが、複数のマシンにロボットを作成できている図
    image.png
    ただし、右肩メニューから、ライセンス>> Unattended >> 詳細を確認 、で見られる下記のページにはオレンジの「ライセンスなし」表示となっていて、マシンは利用できない状態になっています。。実際、このライセンスなしのロボットにジョブを割り当てようとすると、ジョブの投入まではできてしまって、さらにずっと「保留中」になってしまうのでご注意。基本、このような状態にしちゃダメってことみたいですね。
    image.png

  • ロボットはいくらでも作れちゃうので「じゃあいつ、つかえるのか」って考えてみると、タスクトレイのロボットアイコンからの「接続」が済んでる前提で、上記のようにライセンス状態が緑のとき、といえそう。Attended RoboのとくにConcurrent Userライセンスの場合は、ライセンスの消費・解放のためにロボットアイコンの「起動・終了」をこまめにやったりするわけですが、そもそもUnattendedはログアウト状態でリモートでワークフローを実行するわけで、ライセンスの消費・解放は、タスクトレイのロボットアイコンの起動・終了などには依存しないようです。

さてここまでを整理すると、 Unattended なロボットは購入したライセンス数分と同数のマシン上で稼働させることが可能で、そのマシン上に複数のロボット(Windowsアカウントをわけるってこと)を作成することは可能 となります。たとえば業務ごとにロボットグループを作って、それぞれにWindowsアカウントを用意し、ある1PC上に複数ロボットを作成していろんなワークフローを運用することはできますが、2ライセンス購入して3台のPCで同時利用、などはできない構成になってます。

TIPS

結局マシン分のライセンスが必要?

そのようです。

一方、マシンごとにわりあてる「ランタイム数」というのがあり「ライセンス>> Unattended >> 詳細を確認」で表示される画面から、さらにマシンごとの「ランタイムを編集」を選ぶと
image.png
このマシンに割り当てる「ランタイム数」を制御することが出来ます
image.png

これは、ジョブが複数投入されたときに「並行に稼働する」プロセス数を制御するようで、実際に2以上を割り当てるとジョブを同時に処理しようとします。。が、Windows Serverなどではない普通のWindowsマシンは通常ログイン出来るユーザが1ですので、実際にはうまく動きません(むしろ同時に起動することでエラーになりましたorz)。。。

このランタイム数の設定は「高密度ロボットについて」 ココにあるようにWindows Serverなどをロボ稼働環境として準備した場合に使用するパラメタのようです。

いままで「ロボット実行PCとしてWindows Serverを準備しています」ってケースに出会ったことがないので、実質「UnattendedのライセンスはPCの台数分だけご購入ください」となりそうです。。2

キュー(保留する)の考え方

Unattended ロボを導入するって事は、目の前にあるPCではないところ、でジョブを実行したいわけで、とすると他の人がジョブを実行しようとしているか分からない状況だけど「とりあえず混んでるかもだけどジョブの投入だけしておく(空いたら実行しといてね)」なんて使い方になるわけですね。

なのですが、Unattendedロボの仕様について、微妙なキューの仕様が。。あるジョブを投入して実行中のとき「同じプロセス」を「同じロボット」にジョブとして投入しようとすると「保留中」のステータスになります。
image.png
さらにもう一つ「同じプロセス」を「同じロボット」にジョブとして投入しようとすると下記の「保留中があるからもうダメ」というエラーが。。
image.png

つまり あるプロセスとあるロボット、ごとにキュー出来るジョブは一つだけ という仕様であることが分かります。

ためしに、あるロボット(下記キャプチャのROBO_01)に同じプロセス(app01)を投入して保留状態をつくり、、、別ロボット(ROBO_02)に同じプロセスを投入すると、、同時ランタイムが1なので、実行はもちろんされませんがこちらのジョブも保留中に。。
image.png

さらに一応ですが、ROBO_02についても保留中で、さらに同じプロセスをジョブ投入すると、このロボットはこのプロセスでほかで保留中ですというエラーが。。(利用可とでるのはたぶんバグでしょう)
image.png

さらにさらにですが、この状況下で「別の」プロセスを入れてみたらどうでしょうか。。

やってみました。プロセス「app01」を「ROBO_01」で実行中。さらに「app01」を「ROBO_01/ROBO_02」でジョブ投入してそれらを保留中に。これ以上は「ROBO_01/ROBO_02」には「app01」を投入出来なかったのですが、別のプロセス「other01」は、「ROBO_01/ROBO_02」へ投入できました。。
image.png

繰り返しですが、エラーメッセージにもありますが あるプロセスとあるロボット、ごとにキュー出来るジョブは一つだけ という仕様があることが分かりました。

とにかく無限にキューしてくれればいいのに、、、とはなっていないことにご注意ください。

「動的に割り当てる」をつかうことで回避する

ジョブを実行時に、上記ではロボット指定でジョブを投入していましたが、ロボットを指定しないで「動的に割り当てる」というオプションがあります。これは、ロボット・プロセスごとに一つキューする上記の仕様とはちがい、どこか別にジョブをキューしといて、空いたロボットをアサインしてプロセスを実行してくれる機能です。コレを用いると、、

image.png
下記の通り、ロボットの割り当て待ちという状況で、ジョブを投入することが出来ました。。
image.png

プロセスを実行する回数を指定することで、
image.png
このようにジョブを大量に投入することが可能です。Orchestratorの「キュー機能(保留のキューではなく)」に大量に投入されたデータをたくさんのロボットでガシガシ処理するなど、そんな場合を想定してる感じですかね。
image.png

具体例

具体例1。複数ロボ、1マシンでプロセス実行の場合。

さいごに具体例。

  • 1PC上にロボットを2台(ROBO_01,ROBO_02)作成
  • それぞれのロボをGroup 01,Group 02というロボットグループで分割
  • それぞれのロボットグループで、異なるワークフロー(app01,app02)を実行する
  • どちらのグループ利用者も、相手を気にしないでジョブ投入したい

などが普通に実現できるかやってみようと思います。図示するとこうです。
image.png

結果は以下のよう、、、。
image.png

画面は投入した順番に並んでるのですが、、うーん、投入した順番にかかわらずapp01を入れたロボットグループの処理が優先されているように見えます、、、。

app02を先に投入してみましたが、結果はやっぱりapp01優先。。プロセス名順もしくはロボット名順に見えますね、、。3
image.png

具体例2。1ロボ、1マシンでプロセス実行の場合。

では、同じロボに複数プロセスを並ばせてみます。
image.png

おお、順次実行。。あるべき実行結果が得られました。

image.png

このことから動的割り当てのキューの処理順番は、(プロセス名順ではなく)ロボット名順であることが濃厚 といえそうです。1ロボット内での処理順番は、投入したとおりになっている と見えますね。

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

関連リンク


  1. AttendedのNamed UserはWindowsアカウントごとに消費されたりしてましたね。参考 

  2. VDIとかの環境だと、話は別かもしれませんね 

  3. ロボ名を変更しても結果は変わらず、、とすると、内部で付番されているRobotId の可能性が高いです。 

10
7
1

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