こんにちは。UiPath Friends 運営メンバの @masatomix です。業務で UiPath Orchestratorの導入・リリース統制などふくめた運用設計などを行ったりしています。
さて今回は、UiPath Orchestrator(以下 OC)を利用している環境について、たとえば「あ、ワークフローが異常終了したときに、どうやって検知できるんだっけ？」とか「実行したいワークフローがたくさんあるけど、ジョブをじゃんじゃん投入しちゃってよいのかな？」のような「こんなことが起きたとき、OCを入れておけばこういう動きをするよ」 といったUiPath OrchestratorのTIPSを紹介したいと思います。
今回はおもに、障害発生時の検知についてと、Unattendedロボにおけるジョブ投入時の保留の仕様に関するTIPSとなります。
この記事の対象の方
- UiPath Orchestrator を導入したい方
- UiPathを単体で使うのにくらべて、OCをいれたらどう便利か、気になる方
前提
OCサーバ: UiPath Orchestrator 2019.10.18
Robot/Studio: UiPath Studio/Robot 2019.10.3
で疎通確認を行っています。
TL;DR
障害発生時の検知について
- 障害等のアラートの通知手段は以下。
- OC画面上部にポップアップするアラートダイアログ、OCのアラート一覧画面による一覧表示
- アラートメールによる通知
- ロボット(PC)の障害時は、ダイアログ通知・一覧・アラートメールによって通知される(設定で抑制可能)
- ワークフローの異常終了も同様に、ダイアログ通知・一覧・アラートメールによって通知される(設定で抑制可能)
- ただし通知は「Attended/Unattended」の実行のみで、Studioからの実行は通知されない
- ワークフローをOC画面から停止・強制終了させたばあい、各アラートは通知されない
- 長時間保留となっているワークフローは通知がされないので注意が必要。
ジョブ投入時にロボットに空きがない場合の挙動について
- ジョブ投入時に、ワークフローを実行するロボットを指定する方法として「特定のロボット」「動的に割り当てる」の二つの方式があり、空きがないときの保留の考え方が異なる
- どちらも、ロボットが空いていないときには「保留」というステータスでジョブを投入できるが「動的に割り当てる」ほうが、とりあえず投入、ができて使い勝手がよい
- 「特定のロボット」は特定のロボット上で、少数のジョブの実行に向いている
- 「動的に割り当てる」は、複数のロボット上で、大量のジョブの実行に向いている
- トリガー(スケジューラ)からのジョブ生成については 「あるロボットについて、同じワークフローはひとつしか保留中にできない」 という制約あり
TIPS集
さて、以下に詳細をみていこうと思います。
OCで管理されたPCがダウンした場合の障害検知について
たとえば、ネットワーク障害などでOCに登録されたロボットとの接続が切れた場合や、明示的に接続・切断を行った場合(含PCのシャットダウン)の検知について。
以下の二点による障害検知を行います。
- OC画面上での「ロボットxxが、応答しません」などの通知ダイアログ。またアラート画面による一覧表示
- 定期的な (デフォルトでは10分おき)メールによる通知、あさ7時1のサマリーメール通知
アラート通知ダイアログ:
アラート画面による一覧表示:
定期的なメールによる通知:
アラートを受信するユーザの条件
上記のアラートを(画面やメールで) 受信する条件は、だいたい以下の通りです2。
- OCにユーザとして登録されている
- そのロボットの情報を参照する権限がある、つまり
- ロボットの参照、の権限がロールで与えられている
- ロボットが属するフォルダを参照できる - アラートの参照、の権限がロールで与えられてる
- メールアドレスが登録されている(メール通知をうける場合)
- 右上のアイコン >> マイプロファイル を選択、もしくは左メニューのユーザ >> ユーザ一覧の右のメニューより「プロファイルの表示」を表示して、アラートを表示。そこの**「ロボット」がオンになっている**こと。
最後の、プロファイル画面のアラート制御画面は以下のようなかんじ。今回はロボットのアラート通知の制御を行いましたが、そのほかに「トランザクション」「ジョブ」「トリガー」「キュー」のアラートの制御が可能になっています。
ちなみに、ロールによってアラートの参照の権限を付与されていない場合、そもそも右上のアラート一覧へ遷移するボタンも表示されないし、通知の赤いダイアログも表示されません。下の画像は、左がアラート参照権限がないユーザ、右があるユーザです。
さて、下記のサイトによると、
https://docs.uipath.com/orchestrator/lang-ja/docs/webconfig
PeriodicErrorMailJobCron - 定期的なメール アラートの送信頻度を制御する cron 式を設定できます。これはメール アラートが有効な場合にのみ使用できます。既定値は 10 分ごとです。これは、過去 10 分間に生成された、重要度が Fatal および Error のアラートがレポートに含まれることを意味します。アラートが 1 つも生成されなかった場合、レポートは送信されません。
だそうで、Orchestratorの設定によって、この間隔は制御することが可能です。また 過去10分間に「Fatal/Error」なアラート通知があると、メール送信する とのことなので、切断しっぱなしの端末がなんどもメールがくる、てこともないし、逆に復旧したとしてもその旨のメールはこないってことになりそうです。明確に確認してないですけど、つかってて確かにそんな感じでメールが来てた気がします。
また**「Fatal/Error」なアラート通知があると、メール送信する** ということなので、Infoなアラートはメール通知が来ません。たしかにアラート一覧画面には、PC上で「切断」したあと再度「接続」をしたときの「利用可能になりました」というInfoアラートが表示されましたが、このアラートは右上のアラートのマークも未読マークがつかないし、メール送信には含まれていませんでした。
https://docs.uipath.com/orchestrator/lang-ja/docs/about-alerts
によると一覧画面にはInfo、Success、Warn、Error、Fatal のアラートが表示されるが、ダイアログ・メールによる通知はError、Fatalのみ、とのことです。
最後に、、ユーザを登録する際にメールアドレスを登録すると「You are receiving this e-mail because you or your Orchestrator administrator have requested to confirm your email.」 みたいな「確認を押してね」メールが届くんですが、この確認オペを行わなくても、アラート通知メールは届いているようです。。ちょっとよく分からないですね、、。
ジョブ実行中に、ワークフローが異常終了したばあい
さきほどはPCがダウンしたときの障害検知でした。つづいてワークフローの障害検知です。
「Attendedロボについて、ユーザがタスクトレイからワークフローを実行」 したり 「Unattendedロボについて、OC画面からジョブ実行」 したときに、そのワークフローが異常終了した場合などですね。
ワークフローが異常終了する場合というのはたとえば、下記のようにワークフローが BusinessRuleExceptionをスローしたり、セレクタが見つからない結果例外がスローされるなど、ようするになんらかの例外がスローされた場合だと思ってください。
さて、このような異常終了するワークフローを実行した場合、基本的にはロボット自体の障害検知と同様、
- OC画面上での「xxx の # ジョブは # ロボット xxx で失敗しました。」などの通知ダイアログ。またアラート画面による一覧表示
- 定期的なメールによる通知
によって障害が通知されます。
ジョブが失敗したときのOC上のエラーダイアログ:
アラート画面による一覧表示:
定期的なメールによる通知:
ジョブ画面やアラート一覧の詳細表示で、障害が発生した原因を確認できます:
詳細表示:
いまのはワークフローが異常終了した場合ですが、Unattendedロボをが動き出した際、Windowsアカウントのパスワードが間違っていた場合なども、ジョブの失敗としてアラートが通知されます。
パスワード誤りで発生したアラート
アラートを受信するユーザの条件
上記のアラートを(画面やメールで) 受信する条件も、基本的にはロボットの場合と同じで、おおむね以下の通りです。
- OCにユーザとして登録されている
- そのジョブの情報を参照する権限がある、つまり
- ジョブの参照、の権限がロールで与えられている
- ジョブが属するフォルダを参照できる
- ロボットの参照、の権限はどうやら不要っぽい - アラートの参照、の権限がロールで与えられてる
- メールアドレスが登録されている(メール通知をうける場合)
- 右上のアイコン >> マイプロファイル を選択、もしくは左メニューのユーザ >> ユーザ一覧の右のメニューより「プロファイルの表示」を表示して、アラートを表示。そこの**「ジョブ」がオンになっている**こと。
ロボットの接続・切断などは通知が来るとうっとうしいから抑制したいけど、ジョブの障害通知は欲しい、ってケースはわりとあるとおもいますが、その場合はこのプロファイル画面でジョブはオン、ロボットはオフ(もちろんロールでジョブの参照の権限は付与する) としておけばよさそうです。
下記の通り、ジョブのみしかアラート通知がこないようになります。
ジョブが異常終了した場合は以上です。
ジョブを停止/強制終了させた場合
さて、ジョブには停止と強制終了によってジョブを途中で終了させることができますが、これらはOC画面上から手動でおこなうからでしょうか、アラート通知は行われません。メール通知も行われないようですね。
以下蛇足
蛇足ですが、停止・強制終了の挙動ですが、
- 強制終了は、すぐに処理を「強制」終了させる
- 停止は**「停止して」という指示をワークフローに送信するだけ**です。ワークフロー側は「停止すべきか確認」というアクティビティ(True/Falseを返す)を使って「停止指示」を受けたかを判断し、必要に応じて途中で処理を終了させる(必要がある)
という違いがあります。OC上で「停止」を選択したらすぐワークフローが停止されるわけではないのでご注意ください。
ワークフロー側は定期的にそのアクティビティで「停止指示をうけているか」をチェックし、指示を受けたら終了処理 (例: 停止されたというログを出力して開いているファイルを閉じる、など)をおこなう、というのが定番の使い方です。
従って、下記の通り、**強制終了についてはジョブのステータスは「停止」**となりますが、**通常の停止は、終了処理で例外をスローすれば「失敗」だし、普通に処理を抜けて終了すれば「成功」**となります。
ジョブを強制終了した場合の「停止」の図
最後にジョブを停止・強制終了させる手順ですが、ジョブの一覧から停止させたいジョブ行の右のメニュー >> 停止 or 強制終了 を選べばOKです。
ジョブを実行したいときに、ロボットに空きがない場合の挙動
ジョブの保留とは
Unattended ロボを導入する目的のひとつは遠隔からのジョブ実行だと思いますが、とすると他の人がジョブを実行しようとしているか分からない状況状況のなか「とりあえずロボットが空きそうかわからないけど、ジョブの投入だけはしておく(空いたら実行しといてね)」という使い方になります。
そのため、Orchestratorには実行待ちのジョブは保留にしておいて、空きができしだい順次実行するという機構があります。
ジョブが「保留中」状態とは、ロボットがワークフローを実行中、もしくはワークフローの実行が不可能な状態のときに、ロボットがワークフローを実行可能になるまで待っているという状態です。
ジョブ実行の方式は2つ
また、ジョブの実行には「(ロボットグループ内の)特定のロボット」で実行するやり方と「(ロボットグループ内の)いずれかに動的に割り当て」て実行するやり方があります。
それぞれの、つかいどころを整理してみます。
「特定のロボット」は特定のロボット上で、少数のジョブの実行に
「特定のロボット」はジョブ作成時にロボットを直接指定するやりかたで、「動的に割り当てる」は、実行時に空いているロボットをOCが選んで実行するやり方です。
「特定のロボット」は、明確にロボットを指定できるのが便利ですが 「あるロボットについて、同じワークフローはひとつしか保留中にできない」という制約があるので注意です。ロボット上であるワークフローが保留中になっていると、そのロボットに同じワークフローをさらに投入しようとすると「既に保留中がある」というエラーが発生して、投入ができないようになっています。
つまり「特定のロボット」は同じワークフローをバンバン実行させるような用途には不向きです。逆にロボット指定で、1日数回のバッチ実行、などに向いているといえます。
参考: https://docs.uipath.com/orchestrator/lang-ja/docs/about-jobs#section-execution-priority
「動的に割り当てる」は、複数のロボット上で、大量のジョブの実行に
「動的に割り当てる」は、実行時に空いているロボットをOCが選んでくれる方式で、先の**「あるロボットについて、同じワークフローはひとつしか保留中にできない」という制約もありません**。なので、複数台のロボットを用意して、大量のジョブを並列で実行するとか、どのロボットで実行してもかまわないジョブなどは「動的に割り当てる」のが柔軟性があってよいと思います3。
ロボットが実行不可能状態で、ジョブが保留中となる場合の注意
ロボットがワークフローの実行が不可能な状態 (トレイから「切断」を押していたり、ネットワークが切れて無応答状態など) の場合でも、ジョブの投入は可能です(スケジュールからの投入時も同様)。そのときはジョブの状態が「保留中」となるのですが、ロボットが復旧しない限り、ずっと保留中のままとなってしまいます。
あ、もちろんロボットが復旧したら、ジョブは実行開始されますが。
しばらくしたら異常終了になるかと 1時間ほど待ってみたのですが、ずっと保留中のままなので、障害の通知も来ません。タイムアウトなどがあるとよいのですが、、。したがって、**ワークフローの実行結果をジョブのステータス(状態)でしかチェックできない場合4**は、保留中のジョブが存在するかどうかを定期的にチェックする必要があるかもしれません。
いちおう OrchestratorにはAPIが備わっているので、APIをコールすることで下記のようなジョブの状態の情報を出力することは可能です。「Pending」となっている行が、保留中のジョブですね。
OCが障害でダウンしている場合
Orchestratorサーバ自体が障害でダウンしている場合は
- (OC画面から実行する) Unattendedロボのジョブ実行・スケジュール実行は不可能
- AttendedロボもOCに接続出来ないため、タスクトレイからのワークフローの手動実行も不可能
となります。
通常状態:
OCダウン状態:
野良ロボの統制という観点ではこの仕様は厳密で正しいのですが「OCがダウンしていると業務が止まる、ってのは困る」という意見もあります。とくにOCは「シングル構成で(副系の代替サーバを用意しない)構築する」ことも多いので、より回避策がもとめられたりします5。
じつはOCの設定によりタスクトレイからのワークフロー実行については、「OC障害後も、一定時間はAttendedロボットでワークフローを実行可能にする」ことができます。設定箇所は OC画面の右上のアイコン(キャプチャ上は「A」のアイコン) >> 設定 >> セキュリティにある「切断状態で実行可能な時間」です。デフォルトは「0」かもしれませんが、これを 1h〜168h (=7日) の範囲で変更すればOKです。
実際、OCをダウンさせてみると、、、
OCダウン状態(実行可能時間の設定後):
ステータスは「接続失敗」になっていますが、ワークフローの実行は可能となっています。実際に実行してみて、動作することを確認しておきましょう。
OCとの接続が切れている間にタスクトレイから実行されたワークフローのログについても、復旧したときにアップロードされてOCに記録されています。
ただ、ジョブ画面には登録されないようですね。
ちなみにこの「切断状態で実行可能な時間」は、ロボットの「切断」「接続」ボタンによってOCに接続したときや、ロボットサービスが再起動されたときに、適用されるようです。OC画面の設定を変更したらロボットたちにすぐに反映されるわけではないのでご注意ください。
参考: https://docs.uipath.com/orchestrator/lang-ja/docs/field-descriptions-host-settings#section-robot
スケジューラ関連の障害検知について
さてさて、スケジューラ(2019からはトリガー)から起動されたジョブの障害検知についてですが、ジョブ自体は既出の「ジョブの障害検知」で通知されるわけで、それの詳細は割愛します。とすると残りは、スケジューラがジョブ作成を出来なかった場合 の検知についてですね。
あ、このスケジューラの障害もアラート通知が出てきますが、アラートを受信する条件はいままでとほぼ同じで、プロファイルで「スケジュール」 をオンにしておきましょう。
スケジューラがジョブを作成しようとしたとき、ロボットに空きがない場合
たとえば1分毎にスケジューラがジョブを投入するとして、ロボットが実行不可の状態のとき、1つめは保留中として投入されますが、次以降のジョブは「ロボットには既にこのプロセスに対する保留中のジョブがあります」エラーとなり、アラート通知されました。
ダイアログ
一覧画面
ジョブ投入の際の保留の考え方によれば「特定のロボット」では保留中の重複エラーになるとしても「動的に割り当てる」ケースでは投入だけはできる想定でしたが、、そうはならないようです。
もちろん「あるロボットについて、同じワークフローはひとつしか保留中にできない」の制約で動いているので、別のワークフローのジョブを投入することは問題なく可能です。
保留中のうごきが一部想定外でしたが、アラートの通知の観点では、ただしく通知がされました。
また、ジョブのときと同様、ロボットがワークフローの実行が不可能な状態において保留中のジョブが放置される可能性があるので、発生頻度によってはチェックの仕組みをかんがえた方がよさそうですね。
まとめ
いかがだったでしょうか。まとめると
- ロボットの使用不可能状態やワークフローの異常終了について「OC画面上のダイアログやアラート一覧画面」「ユーザに紐付いたアドレスでアラートメールを受信すること」で、それらの検知ができることがわかりました。
- またジョブの投入について、稼働するロボットを動的に割り当てる機能によってロボットが空いていないときにもジョブの投入ができることがわかりました。
- ロボットを指定してワークフローを実行したいとき、そのロボットですでに同じワークフローがジョブ登録されている場合は「すでに保留中ジョブが存在する」となってジョブの投入ができないのでご注意ください。
- ロボットが使用不可(ネット切断や電源断) な状態が頻繁に発生する場合は**「長時間の保留中」の検知**を個別に作り込む必要がありそうです。
- スケジュール実行について、そのロボットですでに同じワークフローがジョブ登録されている場合は「すでに保留中ジョブが存在する」となって、エラーとして処理(アラート通知)されるのでご注意ください。
以上、おつかれさまでした。
関連リンク
- アラートについて「アラートの分類」に発生するアラートの種類の説明があります。
- 切断状態で実行可能な時間 の解説
- Jobsについて ジョブの投入、優先度、などについての解説
- Web.Config:アラート
- キュー(保留する)の考え方 上記で説明した保留について、いろいろ試した結果を記載