スケジュール実行が動かない？
どもども、ジャナイホーです。
スケジュールの定義をしたのに、時間になってもうんともすんとも言わない、ということがあったりします？
先ずは一通り、Blue Prismのスケジュール定義やスケジュールサービスの稼働が正しくセットアップされているか、確認します。
一回も動いたためしがない、ということであれば、これらセットアップを確認しましょう。
そうではなくって、、、
これまでは、ちゃんと動いていたのに、突然、あるいは、ときどき、「保留」ステータスのまま、動いていなかった、ということがあったりしたとき。
そんなとき、実は色んな原因が考えられるのですが、そのうちの一つとして、ネットワーク接続に起因してたりすることがあります。
念の為、切り分けの一つとして、今回の記事を参考にしてみて下さい。
コントロールルーム画面上で、手作業でプロセスは動く
セッション管理の画面で、手操作で任意のプロセスを右側のリソースにずずずぃっと、ドラッグアンドドロップでセッションを作成＆実行すると、上手く動きます。動くんですよ。と。
そもそも、ここで動いてくれなければ、ランタイムリソースが正常に稼働していないか、通信が出来ていません。スケジューラ以前の問題です。ネットワーク接続やランタイムリソースのプログラムの稼働状況を確認して下さい。
もし、上記の手操作ではちゃんと動くけれども、同じプロセス、同じランタイムリソースをスケジュールで起動した場合に、動いてくれないんですよ。と。
あるいは、コントロールルームの画面上を見ていると、リソースの接続状態が断続的に「接続中」→「検証しています」→「未接続」を繰り返したりする。
そんなときは、マシン間のネットワーク接続の設定が正しいかどうか、疑ってみる必要があります。
スケジュールログを確認する
先ず、スケジュールのログを確認します。
何か情報が出ているかもしれません。
そこに例えばこんなメッセージがログに出ていれば、、、
「リソース○○ is offline」（○○がオフラインです）。
これは、そのランタイムリソースに通信が出来ていないことを示しています。
えっ！？ だって、手操作での実行は出来てんじゃん。通信が出来てるってことでしょ？
。。。そうなんですけど、コントロールルーム画面上（つまりそのインタラクティブクライアント）と当該ランタイムリソース間の通信方式・手順と、スケジュール実行を司るアプリケーションサーバと当該ランタイムリソース間の通信方式・手順は、微妙に違います。なので、こっちは出来てるのにそっちは出来ない、という現象が起こります。
そっちで通信が正しく出来ているか、確認する
以下を確認しましょう。（ちょっとネットワークの専門的な話になりますが。）
Windows Firewall、（Amazon AWSなどで動かしている場合、そのセキュリティグループの設定）など、TCP通信（アプリケーションサーバとランタイムリソース間、双方向）が開放されているか
ホスト名の名前解決が出来ているか
アプリケーションサーバのコマンドプロンプトを起動して、そこから、pingコマンドを実行してみます。
上記のようなメッセージ（ホスト○○が見つかりません。ホスト名を確認してもう一度実行して下さい）が出るようであれば、ホスト名の名前解決が出来ていません。
nslookupコマンドを実行して、DNSによるホスト名の名前解決が正しく行えているかどうか、を確認することも必要です。
ネットワーク管理者に連絡して、ホスト名の名前解決が出来るように依頼する必要があります。
（DNSの設定を正しくする、あるいは、ローカルのhostsファイルにホスト名＆IPアドレスのエントリを記載する、などです。）
上記のように、ホスト名の後にIPアドレスがきちんと正しい値で表示されていれば、ホスト名解決については、問題ないでしょう。
もう一つの確認方法
もうひとつ、ネットワーク通信接続が正しく設定され、動作しているか、を確認する方法ですが、以下のように、ブラウザからランタイムリソースに接続してみます。
http://<ホスト名>:<ポート番号>/version
ここでは、アプリケーションサーバのブラウザから、＜ホスト名＞（とあるのは、ランタイムリソースです。）に対して接続してみる、ということをやってみます。
こんな画面が出れば、正しく通信が行えています。ここまでくれば大丈夫のはず。
下記のような画面が出るのであれば、正しく通信が行えていません。
Windowsのファイヤーウォールやその他ネットワークの制限などが邪魔をしているか、あるいは、ランタイムリソースがそのポート番号で正しく動作していない、ということが考えられます。
インストール、サーバの環境設定、ランタイムリソースの環境設定、正しく出来てるか、見直しする必要があります。
また、ネットワーク通信の設定も確認する必要があります。
ネットワーク通信の確認手順については、下記を参考にしてみて下さい。Testing Connectivity Blue Prism Guide
イベントビューワでログを確認
ネットワーク接続の不調が原因の場合、アプリケーションサーバのマシン、あるいは、ランタイムリソースのマシン、のWindowsのイベントログ上には、以下のようなメッセージが出力されていたりします。（このうちのどれか、だったり、複数だったりします）
こんなときは、ネットワーク管理者に連絡して調べてもらいましょう。遅延、寸断が発生している、あるいは、ホスト名の名前解決が正しく行えていない、というのが多い原因です。
通信が安定して、遅延も発生しない高品質でないと、上手く動きません。
System.IO.IOException: Unable to write data to the transport connection: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。. ---> System.Net.Sockets.SocketException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
System.IO.IOException: 転送接続にデータを書き込めません: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。。 ---> System.Net.Sockets.SocketException: 確立された接続がホスト コンピューターのソウトウェアによって中止されました。
Failed to read next incoming line within ...
Error connecting to resource. Attempts to re-establish the connection will occur periodically. BluePrism.BPCoreLib.BluePrismException: リソースへの接続がタイムアウトしました。
Failed to connect to Resource PC - Reply: ''
Failed to create session on ○○ - No reply from Resource PC
Timed out waiting for all sessions to start
Timed out waiting for valid connection
Not connected to ○○
An error occurred while 'Say'ing: ...
Connection to the resource timed out
IPアドレスが固定で割り振られていない環境ではないですか？（DHCPで動的に割り当てられたりしていませんか？）
マシンあるいはWindowsの電源管理の オプション設定で、待機状態やオフになったりすることは無いですか？
Wifiでネットワークに接続したりしていませんか？
もし心当たりがあるのであれば、これらは見直しをする必要があります。
安定して、低遅延な接続が必要です。
アプリケーションサーバから：
ping -l 1024 -n 30 <ランタイムリソースのホスト名>あるいは、ランタイムリソースから：
ping -l 1024 -n 30 <アプリケーションサーバのホスト名>などとコマンドプロンプトから実行してみて、応答時間、パケットの損失率などを確認します。これを長いこと、定期的に実施してみて、変な挙動が無いか確認するのも手です。繋がるには繋がるけど、不安定っぽいなぁ、とか。
最近の事例では、AWS環境で、AZ(Availability Zone) を跨いだ複数のランタイムリソースを1つのリソースプールでスケジュールタスクを割り当てたケースで、ネットワークセグメントを超えることによる影響なのか、AZを超えることによる影響なのか、通信が遅延・タイムアウトが頻発していた、ということがありました。
こういうのって、見え難いんですよね。。。
この場合、一つのリソースプールに所属するランタイムリソースは、すべて同じネットワークセグメントの中で、同じAZにあるものに限定するようにしました。これで、通信環境が改善され、結果的にスケジュールタスクが失敗する、プロセスが落ちる、保留状態のセッションがそのまま残る、ということが発生しなくなりました。
リソースプールを使って、そのリソースプールの中に多くのランタイムリソースを入れている、という環境になると、ネットワークにかかる負荷とレスポンス・安定性要求はよりシビアになります。
バージョンアップ
ネットワーク接続に問題はなさそうだ、と切り分けが出きている場合、それでも問題が頻発するようでしたら、Blue Prismのバージョンがv6.7以降であれば、最新のバージョンに上げてみましょう。
6.7.0、6.7.1、6.7.2であれば、6.7.3以降に。
6.8.0であれば、6.8.1以降に。
ナレッジベース文書
以下のナレッジベースも参考にしてみましょう。
そして、「遅延」というと、ネットワークの問題も多いのですが、実はもう一つ注意する必要があるのが、データベースのパフォーマンスの劣化です。
データベースとの通信レスポンスの悪化
ランタイムリソースとアプリケーションサーバは、高頻度で通信を行います。
プロセスを実行していないアイドル状態でも、ランタイムリソースが生きているか、オフラインになっていないか、を定期的に確かめています。
この状態情報をSQL Serverデータベースに書き込んだり、参照したりといったことをやるのですが、もしこのデータベースへ問い合わせあるいは書き込みを行った際に、結果が想定範囲の時間内で返ってこない場合、つまり、タイムアウトが発生した場合、上記のような「通信ができなかったぜ」エラーを出すことがあります。
データベースのレスポンスが悪くなる原因の一つが、データベーステーブルが肥大化し、CPUやメモリ、ディスクなどを逼迫し、SQL処理が重くなってしまった、ということがあります。
特に、セッションログのテーブルが、いとも簡単に肥大化します。適切なタイミングで適切な範囲でセッションログをアーカイブするようにし、肥大化を避けるようにしましょう。
セッションログをアーカイブし、DBが軽くなったことで、ネットワーク通信エラーが激減した、というお話もよく聞きます。
通信、接続は正しく行われている、にもかかわらず、でもまだスケジュールでエラーが発生する、あるいは、ここ最近急にエラーが頻発し出した、などというときは、データベースのレスポンス悪化も疑って下さい。
レスポンス悪化の大きな要因のひとつは、定期的な適切なデータベースのメンテナンスを行っていないこと、です。
トラブルを未然に防止する為にも、データベースのメンテナンスは、規模が大きくなればなるほど、重要です。
、、、これでも埒が明かないようであれば、カスタマーサポートへ問い合わせ、ですな。。。
まとめ
スケジュール実行が出来ない、という現象が発生する場合、スケジューラサービスなどの事前設定が正しく行われていないかもしれない、といった点に加えて、ネットワーク通信が正常に動作していない場合も考えられます。
ホスト名の名前解決が出来ているか、通信が遅延なく常にしっかり安定して出来ているか、各種ネットワークコマンドを駆使して確認し、問題解決にあたる必要があります。
アプリケーションサーバ、ランタイムリソースの双方のWindowsのイベントビューワにある、イベントログも解決のヒントになります。
製品のマイナーバージョンのアップデートで解決する場合もあります。
SQL Serverデータベースのテーブルが肥大化することでレスポンスが悪化し、通信エラーを引き起こしていることも考えられます。
セッションログのアーカイブなど、データベースのメンテナンスも安定運用のカギです。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。