Blue Prism 案内

スケジュール実行が動かない?

どもども、ジャナイホーです。

スケジュールの定義をしたのに、時間になってもうんともすんとも言わない、ということがあったりします?

先ずは一通り、Blue Prismのスケジュール定義やスケジュールサービスの稼働が正しくセットアップされているか、確認します。

一回も動いたためしがない、ということであれば、これらセットアップを確認しましょう。

そうではなくって、、、

これまでは、ちゃんと動いていたのに、突然、あるいは、ときどき、「保留」ステータスのまま、動いていなかった、ということがあったりしたとき。

そんなとき、実は色んな原因が考えられるのですが、そのうちの一つとして、ネットワーク接続に起因してたりすることがあります。

念の為、切り分けの一つとして、今回の記事を参考にしてみて下さい。

スケジュール実行が動かない?

コントロールルーム画面上で、手作業でプロセスは動く

セッション管理の画面で、手操作で任意のプロセスを右側のリソースにずずずぃっと、ドラッグアンドドロップでセッションを作成&実行すると、上手く動きます。動くんですよ。と。

スケジュール実行が動かない?-1

そもそも、ここで動いてくれなければ、ランタイムリソースが正常に稼働していないか、通信が出来ていません。スケジューラ以前の問題です。ネットワーク接続やランタイムリソースのプログラムの稼働状況を確認して下さい。

もし、上記の手操作ではちゃんと動くけれども、同じプロセス、同じランタイムリソースをスケジュールで起動した場合に、動いてくれないんですよ。と。

スケジュール実行が動かない?-2

あるいは、コントロールルームの画面上を見ていると、リソースの接続状態が断続的に「接続中」→「検証しています」→「未接続」を繰り返したりする。

そんなときは、マシン間のネットワーク接続の設定が正しいかどうか、疑ってみる必要があります。

スケジュールログを確認する

先ず、スケジュールのログを確認します。
何か情報が出ているかもしれません。

スケジュール実行が動かない?-3

Recent Activity > View Log

そこに例えばこんなメッセージがログに出ていれば、、、
「リソース○○ is offline」(○○がオフラインです)。
これは、そのランタイムリソースに通信が出来ていないことを示しています。

スケジュール実行が動かない?-4

えっ!? だって、手操作での実行は出来てんじゃん。通信が出来てるってことでしょ?

。。。そうなんですけど、コントロールルーム画面上(つまりそのインタラクティブクライアント)と当該ランタイムリソース間の通信方式・手順と、スケジュール実行を司るアプリケーションサーバと当該ランタイムリソース間の通信方式・手順は、微妙に違います。なので、こっちは出来てるのにそっちは出来ない、という現象が起こります。

そっちで通信が正しく出来ているか、確認する

以下を確認しましょう。(ちょっとネットワークの専門的な話になりますが。)

  • Windows Firewall、(Amazon AWSなどで動かしている場合、そのセキュリティグループの設定)など、TCP通信(アプリケーションサーバとランタイムリソース間、双方向)が開放されているか
  • ホスト名の名前解決が出来ているか

アプリケーションサーバのコマンドプロンプトを起動して、そこから、pingコマンドを実行してみます。

スケジュール実行が動かない?-5

上記のようなメッセージ(ホスト○○が見つかりません。ホスト名を確認してもう一度実行して下さい)が出るようであれば、ホスト名の名前解決が出来ていません。

nslookupコマンドを実行して、DNSによるホスト名の名前解決が正しく行えているかどうか、を確認することも必要です。

ネットワーク管理者に連絡して、ホスト名の名前解決が出来るように依頼する必要があります。

(DNSの設定を正しくする、あるいは、ローカルのhostsファイルにホスト名&IPアドレスのエントリを記載する、などです。)

スケジュール実行が動かない?-6

上記のように、ホスト名の後にIPアドレスがきちんと正しい値で表示されていれば、ホスト名解決については、問題ないでしょう。

もう一つの確認方法

もうひとつ、ネットワーク通信接続が正しく設定され、動作しているか、を確認する方法ですが、以下のように、ブラウザからランタイムリソースに接続してみます。

http://<ホスト名>:<ポート番号>/version

ここでは、アプリケーションサーバのブラウザから、<ホスト名>(とあるのは、ランタイムリソースです。)に対して接続してみる、ということをやってみます。

こんな画面が出れば、正しく通信が行えています。ここまでくれば大丈夫のはず。

スケジュール実行が動かない?-7

下記のような画面が出るのであれば、正しく通信が行えていません。

スケジュール実行が動かない?-8

Windowsのファイヤーウォールやその他ネットワークの制限などが邪魔をしているか、あるいは、ランタイムリソースがそのポート番号で正しく動作していない、ということが考えられます。

インストール、サーバの環境設定、ランタイムリソースの環境設定、正しく出来てるか、見直しする必要があります。
また、ネットワーク通信の設定も確認する必要があります。

ネットワーク通信の確認手順については、下記を参考にしてみて下さい。
Testing Connectivity Blue Prism Guide

イベントビューワでログを確認

スケジュール実行が動かない?-9

ネットワーク接続の不調が原因の場合、アプリケーションサーバのマシン、あるいは、ランタイムリソースのマシン、の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データベースのテーブルが肥大化することでレスポンスが悪化し、通信エラーを引き起こしていることも考えられます。

セッションログのアーカイブなど、データベースのメンテナンスも安定運用のカギです。

※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。

はじめてのBlue Prism
  • fb-button
  • line-button
  • linkedin-button
CONTACT

導入に関する
ご相談

TOP