Enterprise Blue Ocean ◮

神谷町RPAブログ

  • Blue Prism 初級者向け
    • Blue Prism を 無料で利用する 方法はこちら
    • Blue Prism の Blue Prism 事始め!オンボーディングの記事はこちら
    • Blue Prism で Excelを操作 する記事はこちら
  • Blue Prism、ちょっと進んだコンテンツ☆
    • Blue Prism の ベストプラクティス 記事はこちら
    • Blue Prism の 逆引きナレッジ wiki こちら
    • Blue Prism を リアルタイムで起動する 方法はこちら
  • RPA、そもそも論!
    • Youtube で、あらためて振り返る RPA とは?・・・はこちら☆

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

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

 

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

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

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

www.ebocean.work

www.ebocean.work

 

そうではなくって、、、 

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

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

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

 

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

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

f:id:EnterpriseBlueOcean:20200907171846p:plain

 

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

 

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

f:id:EnterpriseBlueOcean:20200908134459p:plain

 

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

 

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

 

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

先ず、スケジュールのログを確認します。

何か情報が出ているかもしれません。

f:id:EnterpriseBlueOcean:20200908134521p:plain

 

そこに例えばこんなメッセージがログに出ていれば、、、

「リソース○○ is offline」(○○がオフラインです)。

これは、そのランタイムリソースに通信が出来ていないことを示しています。

f:id:EnterpriseBlueOcean:20200908134539p:plain

 

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

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

 

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

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

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

 

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

f:id:EnterpriseBlueOcean:20200908134600p:plain

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

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

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

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

 

f:id:EnterpriseBlueOcean:20200908134617p:plain

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

 

もう一つの確認方法

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

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

 

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

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

f:id:EnterpriseBlueOcean:20200908134726p:plain

 

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

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

f:id:EnterpriseBlueOcean:20200908134744p:plain

 

インストール、サーバの環境設定、ランタイムリソースの環境設定、正しく出来てるか、見直しする必要があります。

また、ネットワーク通信の設定も確認する必要があります。

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

https://portal.blueprism.com/documents/guide-tests-network-connectivity

 

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

アプリケーションサーバのイベントログにも手掛かりになるようなエラーメッセージが出力されている可能性もあります。確認してみましょう。

f:id:EnterpriseBlueOcean:20200908134839p:plain

 

ネットワーク接続の不調が原因の場合、アプリケーションサーバのマシン、あるいは、ランタイムリソースのマシン、の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以降に。

 

ナレッジベース文書 

以下のナレッジベースも参考にしてみましょう。

How do I check network connectivity for Blue Prism? 
How do I check if a Runtime Resource is alive remotely? 

portal.blueprism.com

 

How can a Session created by Scheduler get stuck in a 'Pending' state?

help.blueprism.com

 

そして、

「遅延」というと、ネットワークの問題も多いのですが、

実はもう一つ。

データベースとの通信レスポンスの悪化

注意する必要があるのが、データベースのパフォーマンスの劣化です。

ランタイムリソースとアプリケーションサーバは、高頻度で通信を行います。

プロセスを実行していないアイドル状態でも、ランタイムリソースが生きているか、オフラインになっていないか、を定期的に確かめています。

この状態情報をSQL Serverデータベースに書き込んだり、参照したりといったことをやるのですが、もしこのデータベースへ問い合わせあるいは書き込みを行った際に、結果が想定範囲の時間内で返ってこない場合、つまり、タイムアウトが発生した場合、上記のような「通信ができなかったぜ」エラーを出すことがあります。

 

データベースのレスポンスが悪くなる原因の一つが、データベーステーブルが肥大化し、CPUやメモリ、ディスクなどを逼迫し、SQL処理が重くなってしまった、ということがあります。

特に、セッションログのテーブルが、いとも簡単に肥大化します。適切なタイミングで適切な範囲でセッションログをアーカイブするようにし、肥大化を避けるようにしましょう。

セッションログをアーカイブし、DBが軽くなったことで、ネットワーク通信エラーが激減した、というお話もよく聞きます。

 

通信、接続は正しく行われている、にもかかわらず、でもまだスケジュールでエラーが発生する、あるいは、ここ最近急にエラーが頻発し出した、などというときは、データベースのレスポンス悪化も疑って下さい。

レスポンス悪化の大きな要因のひとつは、定期的な適切なデータベースのメンテナンスを行っていないこと、です。

トラブルを未然に防止する為にも、データベースのメンテナンスは、規模が大きくなればなるほど、重要です。

 

www.ebocean.work


、、、これでも埒が明かないようであれば、カスタマーサポートへ問い合わせ、ですな。。。

 

まとめ

スケジュール実行が出来ない、という現象が発生する場合、スケジューラサービスなどの事前設定が正しく行われていないかもしれない、といった点に加えて、ネットワーク通信が正常に動作していない場合も考えられます。

ホスト名の名前解決が出来ているか、通信が遅延なく常にしっかり安定して出来ているか、各種ネットワークコマンドを駆使して確認し、問題解決にあたる必要があります。

アプリケーションサーバ、ランタイムリソースの双方のWindowsのイベントビューワにある、イベントログも解決のヒントになります。

製品のマイナーバージョンのアップデートで解決する場合もあります。

SQL Serverデータベースのテーブルが肥大化することでレスポンスが悪化し、通信エラーを引き起こしていることも考えられます。

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