[実験室] ロボット実行中にMCを落とすとどうなる？

## はじめに

めったにないことですが、ロボット運用中に `Managamengt Console`（以降、`MC`） がダウンしたらどうなるのでしょうか？ もしくは メンテナンスのために `MC` を止めるタイミングを誤って ロボット[^1] が起動してしまった場合、どうなるのでしょうか？

今回は実際の挙動へどのような影響が出るのか実験してみます。

[^1]: 具体的なロボットの実装については `ベーシックエンジンロボット`、緑の `ロボット` がありますが、`強調` されていない場合の 「ロボット」は、その総称として使っています。

:::note
本記事は、BizRobo! v11.4.0.2 時点の情報を基に記述しています。
:::

## 仮説・想定

`MC` からスケジュール実行されるロボットの場合、経験上以下のような手順で処理が行われていると認識しています。[^2]

1. スケジュールトリガー（時間になりました）
1. スケジュール実行準備
    1. 前回実行処理が終了済か（重複起動防止）
    1. 登録されているスケジュールが正しいか（静的チェック）[^3]
    1. 登録されているスケジュールが実行可能か（動的チェック）[^4]
1. スケジュール実行
    1. 優先度順実行キューイング（順番待ち、スタンバイ）
    1. ロボット実行

ゆえに、ロボットはスケジュール実行時点で処理に必要な情報をすべて持っており、ロボット実行後の `MC` 停止はその処理に影響を受けない。（例外あり）と考えています。

::: note
キューイングと優先度順の実行タイミングについては、その範囲やタイミングがどこまでなのか詳しくないので、今後時間がある時に検証してみたいと思います。
:::

[^2]: あくまで経験上の理解であり、厳密さや正確さについて保証するものではありません。特に開発チームに確認したわけでもありません。

[^3]: スケジュール登録後に例えばスケジュールで指定したロボットがリポジトリから破棄されてスケジュールとのリンクが切れてしまっていたリ、クラスターへの割り当てKCUの数が 0 になっていたリなど。

[^4]: スケジュールで動かすロボットが扱う RoboServer や DAS と疎通が取れてリソースが利用可能であること。

### 検証するロボット

### 処理1
`ベーシックエンジンロボット` を基盤とし、DAS を操作する `ロボット` を2回実行する処理

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/70a96be9-de7b-0805-c8d7-379f0b00ff24.png)

スケジュール実行後は `MC` との個別の通信は発生せず、`MC` がダウンしたとしてもロボット自体は問題なく動き続けると思われるタイプの処理。

### 処理2
`ベーシックエンジンロボット` を基盤とし、DAS を操作する `ロボット` を2回実行する処理であり、かつ2回目の DAS 接続の前に MC上の `パスワードストア` にアクセスするもの

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/eadc88cd-3400-74b3-2006-9b404510eb8e.png)

スケジュール実行後、`パスワードストア` の参照ステップにて `MC` にアクセスするため、そのタイミングで通信エラーになると思われるタイプの処理。

## 検証の方法

処理１ロボット、処理２ロボット双方に対して「正常時」「異常時」のスケジュールを作成し、順番に手動でスケジュールを実行、その結果を観察する。

* 「正常時」のスケジュールを手動で実行し、スケジュール終了まで観察
* 「異常時」のスケジュールを手動で実行、 **リモート端末操作１** を通過して **60秒停止** が開始されたタイミングで `Tomcat` を停止し（`MC` を落として）数分間観察。

## 検証結果

### スケジュールへの影響

「正常時」のスケジュールと比較し、「異常時」のスケジュールは実行後も内容が更新されません。
ロボット自体はスケジュールに沿って実行しているものの、実行中にスケジュールの「`MC` <--> `RoboServer`」間セッションが切れているためスケジュールが完結せず、ゆえにステータスが更新されないようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/42c22ca1-073c-b4d5-c351-143850d6ed49.png)

### ログへの影響
#### スケジュール実行ログ
`MC` とのセッションがロボット実行後に途切れてしまうため、スケジュール開始時のログは記録されるが、切断後の終了ログは記録されず、空のままになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/1dbf2621-153d-885a-abc7-ffb15187ad3a.png)

スケジュールのエラーは発生していませんが、「ロボットのエラー」が処理１では1件、処理２では2件報告されているので観ていきましょう。

#### スケジュールメッセージログ
ちなみに、エラー報告のされていないスケジュールメッセージは以下の通り。
仮説・想定の章で記述したステップ3（スケジュール実行）へ処理が移行されたことを基準にスケジュール自体の成否が決まるようです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/20bf8d82-9414-0bb0-3c83-5f1c4e392ee2.png)

:::note
ステップ3で異常が発生した場合の反応は下記の追加検証を参照
:::

#### ロボット実行ログ
`MC` とのセッションは実行後に途切れてしまうものの、`RoboServer` へ引き渡されたロボットはその後も動作し続けるため、「正常時」「異常時」どちらの場合でもロボットは処理を継続し、そのログも記録されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/3bf5d557-efcc-0581-bc50-f04a2b41a352.png)


#### ロボットメッセージログ
##### 処理1 のロボット
ログ上、1件の実行時エラーが報告されていますがロボットの処理自体は **想定通り最後まで実行されました。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/72fa4161-375e-f740-8167-bd5dee7872bc.png)


##### 処理2 のロボット
ログ上、2件の実行時エラーが報告されており、 **「LookUp Password」以降の「リモート端末操作２」は実行されないままでした。**

「LookUp Password」では　`MC` に登録されたパスワードストアに対してリアルタイムで登録情報を取得に行くため、 `MC` との疎通が取れず API例外が発生し後続のステップがスキップされたのだと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/acbe883c-0042-0760-f05f-af14c39f4129.png)


### DAS メッセージログ
Desktop Automation サービスから受信したイベントを表示します。
各ロボットごとの「Connect（接続）」「Disconnect（切断）」情報がログに記載されていますが、先のロボットメッセージで表示されたエラー（`The connection to the client has been lost`）とは時間が一致しておらず、その後の情報（`Execution statics`）と時間が一致していることからも、DASは `MC` 切断の影響は受けておらず（エラーにより切断されたのではなく）、ロボットの処理が完了したことにより切断されたというのがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/a9220498-7686-93bc-641f-9baebdd63554.png)

:::note
`The connection to the client has been lost` については、下記で追加検証
:::
:::note
意外と使われていないようですが、`DAS メッセージ` はスタディック接続／ダイナミック接続関わらず DASの開始／停止、ロボットからの利用開始（接続）／終了（切断）が全て記録されます。
弊社では `Chromium` がメインで動いていますが、多くの端末を運用されている会社さんでは結構有用な情報だと思います。[^5]
:::

[^5]: 弊社は1台しかDAS端末は使っておらず、ほとんどが Chromium のロボットですが。

### タスク メッセージログ
`MC` と `RoboServer` 間のセッションが切れてしまったことにより、タスクのトレースについても途切れており、`completed` は記録されません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/7ecd28f9-a6f1-43b6-2f20-ce1257fd4821.png)

タスクメッセージについては馴染みのない機能だと思いますので、以下[オンラインヘルプ](https://docshield.kofax.com/RPA/ja_JA/11.4.0-vcsft2fhaw/help/rpa_help/help_main/mgmtconsole/c_logsmc.html)から機能の説明を引用します。

>**[タスク メッセージ]**
>　キューイング タスクの状態を通知する個々のメッセージを表示します。タスクについて表示されるメッセージ タイプは、キューイング、実行中、完了、タイムアウト、および削除です。すべてのメッセージに対して、[詳細] 列に説明が表示されます。
Desktop Automation サービス、ライセンス ユニット、RoboServer 実行スロットなどの必要なリソースを取得できなかった場合、タスクはタイムアウトします。「タスク ビュー」のスケジュールまたは対応するタスクが停止した場合、RoboServer が停止した場合、**あるいは Management Console がオフラインになった場合、タスクは削除されます。**

最後の記述にある通り、`MC` を落としたことにより自動的にタスクも削除されたようです。
今回大元の `MC` 自体を落としてしまったので `completed（完了）` のログが残っていませんが、`MC` ではなく `RoboServer` がダウンした場合には `completed` ログは記録されそうですね。 


## 検証結果（追加）

### ① スケジュール実行時にキューイングしたまま処理を開始できない場合

スケジュールは実行され、処理がタスク管理（キュー）に移ったものの、先行している他のロボットが DAS 端末をロックしている（まだ動いている）ために、処理を `RoboServer` に渡せない間、スケジュールログは以下の様に `No Runs*` の状態で保留されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/011b0910-d10c-65c6-f9ba-2ad46bd83671.png)
この場合、処理は `MC` 内のキューに留まり DAS 端末が解放されるのを待ちます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/3eb6ab16-f5fb-0ae4-ff15-ff052c469c8a.png)
システム上 `満期` に設定されている時間は600秒で、それを過ぎるとタスクはエラーとなり処理を断念します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/ef9abfe9-31de-84fb-29c4-6b44476da61d.png)
満期で設定された時間を超えるとタスクは停止され、併せてスケジュールも完了するため、以下の様に `No Runs*` が確定し停止時刻が刻印されます。とはいえ想定した処理が実行できていないので、スケジュールが「成功」になるのは違和感ですね。。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/bbff10c7-fd02-4987-60cc-1f2a9e0a2291.png)


### ② 当該検証において、DAS 端末を利用しないロボットを実行した場合

処理１、処理２ともに共通して `The connection to the client has been lost` というエラーが発生しましたが、ロボット自体の処理には影響を与えておらず、且つ Client（DAS端末？） が何を指すのかも、いまいちわかりません。

ということで、そもそもDAS端末を使用しないロボットにおいてどのような影響が発生するのかを観察してみます。

#### 処理３
ベーシックエンジンロボット を基盤とし、DAS を操作する ロボット を1回実行する処理であり、DAS 操作後に `MC` を切断する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/ff63a3d3-3480-71b0-356f-a1bcc9548f00.png)

#### 処理４
ベーシックエンジンロボット を基盤とし、DAS を操作しない処理であり、処理の途中に `MC` を切断する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/98b09bc6-08a7-a284-7da9-d2cddf85d3ca.png)

#### 検証実行後のログ表示

処理１の実行結果と同じ内容となりました。
`The connection to the client has been lost` エラーと DAS端末の間に関係はないようです。
`MC（Client）` からの命令で `RoboServer（Server）` が動いているという関係を考えると、`MC` とのセッションが切れたことを `The connection to the client has been lost` と表している。と考えるのが妥当な気がします。（発生時刻も合致）

ただ、システム的には正しい表現であったとしても、利用者としては `The connection to the **Management Console** has been lost` の方が正しい表現に思えます。

**スケジュール実行ログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/fd54c03b-87aa-ea71-00c9-05767052dfe2.png)

**スケジュールメッセージログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/62092355-8a46-548b-3f26-376da9b728ee.png)

**ロボット実行ログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/391a4901-9b60-1283-490a-a9236e72d805.png)

**ロボットメッセージログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/d689a1cc-2d0e-f8a4-b8aa-b254158ac27c.png)

**DAS メッセージログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/71185ec4-71d6-26d6-f941-cfd421bc11bf.png)

**タスク メッセージログ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/c5ff7bbc-850e-b3b2-280e-b6567dbc7186.png)


## まとめ

BizRobo!を構成する各モジュールが「疎結合」しているが故かなという感想です。

ロボットはスケジュール実行後は `RoboServer` を中心として自立的に動くことを確認しました。ロボット実行開始前の準備段階でチェックした情報[^6] をロボット実行時にまとめて `RoboServer` に送信している[^7] ためではないかと思います。

一方で、パスワードストアについては実行中に都度 `MC` へ問い合わせに行くため、その時に `MC` と疎通が取れないことでエラーになったようです。[^8]

パスワード情報につては「使うときだけ `RoboServer` 側に渡す」というセキュリティに考慮した仕組みのためだと思われます。

[^6]: ロボットファイル、KCU情報、接続デバイス等の情報

[^7]: `MC` への通信負荷軽減、処理効率化観点

[^8]: 当該ステップのエラー処理設定がデフォルトのまま「API例外」を有効としていたため、`MC`との通信エラーを例外としてエスカレーションし後続のブランチ処理をスキップしましたが、「API例外」のチェックを外していた場合には「処理１」と同様に処理を継続します。また、「API例外」を有効としている場合にもスキップされるのは同ブランチ内の後続の処理であり、別ブランチが `ベーシックエンジンロボット` 内に存在する場合には、処理は別ブランチに移行され、ロボット自体は継続して動作します。