Blue Prism Interact（インタラクト）紹介動画がYoutubeにアップされました！
みなさんこんにちは。ドリームアイランドです。
前回の記事
で取り上げられていたBlue Prism Interact（インタラクト）の紹介動画がYoutubeにアップされました！
動画1本目
はじめようBlue Prism Interact ～フォーム作成・送信～
概要：Blue Prism Interactを使って、プロセス・フォームを作成し、ページ内の項目とルールを設定します。
フォームをユーザーに紐づけた後、ユーザーがフォームからデータ入力・送信を行い、Blue Prismのワークキューにデータが追加されるところまでを収録しております。
動画2本目
はじめようBlue Prism Interact ～ファイルアップロード・データ更新～
概要：Blue Prism Interactフォームへのファイルアップロード項目の追加と、Blue Prismのワークキューにデータが追加された後のデータ更新について収録しています。
Blue Prism Interact（インタラクト）についてもっと聞きたい！
という方いましたら、
そういうちゃんとしたことは、
公式 HP にでも聞くんだな！
L M K I ?
（Let me know Interact: 教えて☆Interact！）
って聞けば、この前、やったウェビナーの
録画でも見せてくれるだろ。
（たぶん）
公式HPに聞きましょう！
P.S.
Blue Prism Interact（インタラクト）、
一発で名前を覚えるのが難しい方もいらっしゃるかと思い、
フリガナをつけて目で覚えてもらおうと思って振ってみました。
Interact（インタラクト）、名前だけでもおぼえて帰ってくださいね。
Blue Prism Interact でワークキューにアイテムを入れた後は、どうしたらいいの？（構想策定、あるいはほぼ雑談編）
オッス！オラ、プリズムマン！！
みんな、在宅ワークは捗ってっか？？
オラは在宅ワークで、ずーっと会議ばっか
してっと、もう頭がおかしくなりそうだぞ。
週末くれぇは技術的なこともすっぞ。
オラ、一応、日曜プログラマだかんな！
Blue Prism Interact とは
ちょっと疲れてきたんで文体を
もとに戻したいんですけど、
構いませんね！
この話をするためには、
Blue Prism Interact とは何かを
理解している
ということが前提になります。
え、ご存じない？
そうですかそうですか。
Blue Prism Interact とはですね、、
・・・
・・・・・・
・・・・・・・・・
教 え ね ぇ よ ！
そういうちゃんとしたことは、
公式 HP にでも聞くんだな！
L M K I ?
（Let me know Interact: 教えて☆Interact！）
って聞けば、この前、やったウェビナーの
録画でも見せてくれるだろ。
（たぶん）
Blue Prism Interact でワークキューにアイテムを入れた後…の話
さて、皆様、よくご存じの Interact で
ワークキューにアイテムを入れた後ですが、
どんなプロセスを組めばいいのか…？
この辺りは設計の話になるので、
最終的には慎重に考え、レビューも
キッチリとやる必要がありますが、
最初から構えていても、
話が始まらないので、まずは雑談ベースで
進めていきましょう。
１ライセンスで Interact からのリクエストをさばく
雑談といいつつも、いきなり方式案の
提示になってしまって申し訳ないですが、
たとえばこんな感じにすれば、
最小の１ライセンスでも Interact の
リクエストをさばけると思うんですよね。
まず、キュー処理プロセスを
プロセステンプレートベースで作って、
キュー（メッセージ）駆動の処理をさせます。
- アイテムがあればデキューして、
- アイテム内のデータから実行する業務処理を特定、
- 業務処理の情報を入力として、プロセス起動.bat を実行し、
- プロセス自体は終了する（ランタイムリソースを空ける）
プロセステンプレートってなんだっけ・・・？
こちらですね👇。
プロセス起動.bat はしばらく待ってから、
AutomateC.exe で業務処理用のプロセスを起動します。
ランタイムリソースは空いてるはずなので、
プロセス実行が可能！・・・なはずです。
AutomateC.exe ってなんだっけ・・・？
こちらになります👇。
業務処理が終わったら、
同じ要領でキュー処理プロセスを起動します。
これでワークキューの次のアイテムを
処理できるはずです。
Interact からリクエストが来ないときもランタイムリソースを有効活用したい
いろいろやり方はあると思いますが、
Dynamic Scheduler 的な考え方で、
事前にワークキューにアイテムを
突っ込んでおけば良いと思います。
Dynamic Scheduler is 何？
・・・こちらです👇。
Interact からのリクエストを優先したければ、
優先度の機能を使って制御できると思います。
この処理方式の課題
さっき、お風呂に入ってるときに考えた、
インスタントな処理方式なので、
いろんな課題があると思います。
たとえば、、
- プロセス起動.bat をどう実装するか。固定の時間、待機するのではなく、AutomateC.exe でランタイムリソースの状態をチェックするなど、いろいろ検討のポイントがある
- 〇月×日 xx:xx:xx という日付・時刻指定のスケジュール実行がやりにくい
- リアルタイム性が低い（１ライセンスしかない前提だと、これは仕方ない気もする）
他にもお気づきの点があれば、
ぜひ、コメントください。
Leave your comment !
まとめ
- Blue Prism Interact の後続処理を検討。いきなり完璧なものは作れないので、まずは雑談ベースで。
- プロセステンプレートやAutomateC.exe、Dynamic Scheduler などのノウハウを組み合わせれば、１ライセンスでも Interact の活用は可能そうだし、Interact からのリクエストがないときもライセンスを有効活用できそう。
- まだまだ雑談ベースの処理方式なので、もっと精緻化したい・・・！（サンプルを GitHub 公開とかしたい☆）
雑談ついでなんですが、
どう考えても
黒歴史になっているコイツ👇
先日、社内イベントでウエルカムパーティがあり、その帰りのバスでプリズムマンと遭遇しました。可愛カッコ良い感じです。
— hnamaizawa (@hnamaizawa) 2019年11月7日
未だ日本でお披露目する予定はないのですが、近くの Blue Prism 関係者へ早く会いたいと言っていただければ早めに参上するかも知れません。😄 pic.twitter.com/DoPCYNxeR0
を Refine して、
フルHDデジタルリマスター版で復刻
しようとしている人がいるらしいです。
（うわさに聞いた）
ヤバいですね。
正気を疑います。
名前も一新したい、って聞いてるんですが、
皆様、何か良いアイデア、
ございますでしょうか？
私は
プ リ 山 ズ ム 男
がいいんじゃないかな、って思ってます。
これ以上に良い案とか、
たぶん、無いと思いますけど、
もし何かあれば、
ぜひコメントください☆
スケジュール実行が動かない?
どもども、ジャナイホーです。
スケジュールの定義をしたのに、時間になってもうんともすんとも言わない、ということがあったりします？
先ずは一通り、Blue Prismのスケジュール定義やスケジュールサービスの稼働が正しくセットアップされているか、確認します。
一回も動いたためしがない、ということであれば、これらセットアップを確認しましょう。
そうではなくって、、、
これまでは、ちゃんと動いていたのに、突然、あるいは、ときどき、「保留」ステータスのまま、動いていなかった、ということがあったりしたとき。
そんなとき、実は色んな原因が考えられるのですが、そのうちの一つとして、ネットワーク接続に起因してたりすることがあります。
念の為、切り分けの一つとして、今回の記事を参考にしてみて下さい。
コントロールルーム画面上で、手作業でプロセスは動く
セッション管理の画面で、手操作で任意のプロセスを右側のリソースにずずずぃっと、ドラッグアンドドロップでセッションを作成＆実行すると、上手く動きます。動くんですよ。と。
そもそも、ここで動いてくれなければ、ランタイムリソースが正常に稼働していないか、通信が出来ていません。スケジューラ以前の問題です。ネットワーク接続やランタイムリソースのプログラムの稼働状況を確認して下さい。
もし、上記の手操作ではちゃんと動くけれども、同じプロセス、同じランタイムリソースをスケジュールで起動した場合に、動いてくれないんですよ。と。
あるいは、コントロールルームの画面上を見ていると、リソースの接続状態が断続的に「接続中」→「検証しています」→「未接続」を繰り返したりする。
そんなときは、マシン間のネットワーク接続の設定が正しいかどうか、疑ってみる必要があります。
スケジュールログを確認する
先ず、スケジュールのログを確認します。
何か情報が出ているかもしれません。
そこに例えばこんなメッセージがログに出ていれば、、、
「リソース○○ is offline」（○○がオフラインです）。
これは、そのランタイムリソースに通信が出来ていないことを示しています。
えっ！？ だって、手操作での実行は出来てんじゃん。通信が出来てるってことでしょ？
。。。そうなんですけど、コントロールルーム画面上（つまりそのインタラクティブクライアント）と当該ランタイムリソース間の通信方式・手順と、スケジュール実行を司るアプリケーションサーバと当該ランタイムリソース間の通信方式・手順は、微妙に違います。なので、こっちは出来てるのにそっちは出来ない、という現象が起こります。
そっちで通信が正しく出来ているか、確認する
以下を確認しましょう。（ちょっとネットワークの専門的な話になりますが。）
- Windows Firewall、（Amazon AWSなどで動かしている場合、そのセキュリティグループの設定）など、TCP通信（アプリケーションサーバとランタイムリソース間、双方向）が開放されているか
- ホスト名の名前解決が出来ているか
アプリケーションサーバのコマンドプロンプトを起動して、そこから、pingコマンドを実行してみます。
上記のようなメッセージ（ホスト○○が見つかりません。ホスト名を確認してもう一度実行して下さい）が出るようであれば、ホスト名の名前解決が出来ていません。
nslookupコマンドを実行して、DNSによるホスト名の名前解決が正しく行えているかどうか、を確認することも必要です。
ネットワーク管理者に連絡して、ホスト名の名前解決が出来るように依頼する必要があります。
（DNSの設定を正しくする、あるいは、ローカルのhostsファイルにホスト名＆IPアドレスのエントリを記載する、などです。）
上記のように、ホスト名の後にIPアドレスがきちんと正しい値で表示されていれば、ホスト名解決については、問題ないでしょう。
もう一つの確認方法
もうひとつ、ネットワーク通信接続が正しく設定され、動作しているか、を確認する方法ですが、以下のように、ブラウザからランタイムリソースに接続してみます。
http://<ホスト名>:<ポート番号>/version
ここでは、アプリケーションサーバのブラウザから、＜ホスト名＞（とあるのは、ランタイムリソースです。）に対して接続してみる、ということをやってみます。
こんな画面が出れば、正しく通信が行えています。ここまでくれば大丈夫のはず。
下記のような画面が出るのであれば、正しく通信が行えていません。
Windowsのファイヤーウォールやその他ネットワークの制限などが邪魔をしているか、あるいは、ランタイムリソースがそのポート番号で正しく動作していない、ということが考えられます。
インストール、サーバの環境設定、ランタイムリソースの環境設定、正しく出来てるか、見直しする必要があります。
また、ネットワーク通信の設定も確認する必要があります。
ネットワーク通信の確認手順については、下記を参考にしてみて下さい。
https://portal.blueprism.com/documents/guide-tests-network-connectivity
イベントビューワでログを確認
アプリケーションサーバのイベントログにも手掛かりになるようなエラーメッセージが出力されている可能性もあります。確認してみましょう。
ネットワーク接続の不調が原因の場合、アプリケーションサーバのマシン、あるいは、ランタイムリソースのマシン、の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 <アプリケーションサーバのホスト名>
などとコマンドプロンプトから実行してみて、応答時間、パケットの損失率などを確認します。これを長いこと、定期的に実施してみて、変な挙動が無いか確認するのも手です。繋がるには繋がるけど、不安定っぽいなぁ、とか。
最近の事例では、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?
How can a Session created by Scheduler get stuck in a 'Pending' state?
そして、
「遅延」というと、ネットワークの問題も多いのですが、
実はもう一つ。
データベースとの通信レスポンスの悪化
注意する必要があるのが、データベースのパフォーマンスの劣化です。
ランタイムリソースとアプリケーションサーバは、高頻度で通信を行います。
プロセスを実行していないアイドル状態でも、ランタイムリソースが生きているか、オフラインになっていないか、を定期的に確かめています。
この状態情報をSQL Serverデータベースに書き込んだり、参照したりといったことをやるのですが、もしこのデータベースへ問い合わせあるいは書き込みを行った際に、結果が想定範囲の時間内で返ってこない場合、つまり、タイムアウトが発生した場合、上記のような「通信ができなかったぜ」エラーを出すことがあります。
データベースのレスポンスが悪くなる原因の一つが、データベーステーブルが肥大化し、CPUやメモリ、ディスクなどを逼迫し、SQL処理が重くなってしまった、ということがあります。
特に、セッションログのテーブルが、いとも簡単に肥大化します。適切なタイミングで適切な範囲でセッションログをアーカイブするようにし、肥大化を避けるようにしましょう。
セッションログをアーカイブし、DBが軽くなったことで、ネットワーク通信エラーが激減した、というお話もよく聞きます。
通信、接続は正しく行われている、にもかかわらず、でもまだスケジュールでエラーが発生する、あるいは、ここ最近急にエラーが頻発し出した、などというときは、データベースのレスポンス悪化も疑って下さい。
レスポンス悪化の大きな要因のひとつは、定期的な適切なデータベースのメンテナンスを行っていないこと、です。
トラブルを未然に防止する為にも、データベースのメンテナンスは、規模が大きくなればなるほど、重要です。
、、、これでも埒が明かないようであれば、カスタマーサポートへ問い合わせ、ですな。。。
まとめ
スケジュール実行が出来ない、という現象が発生する場合、スケジューラサービスなどの事前設定が正しく行われていないかもしれない、といった点に加えて、ネットワーク通信が正常に動作していない場合も考えられます。
ホスト名の名前解決が出来ているか、通信が遅延なく常にしっかり安定して出来ているか、各種ネットワークコマンドを駆使して確認し、問題解決にあたる必要があります。
アプリケーションサーバ、ランタイムリソースの双方のWindowsのイベントビューワにある、イベントログも解決のヒントになります。
製品のマイナーバージョンのアップデートで解決する場合もあります。
SQL Serverデータベースのテーブルが肥大化することでレスポンスが悪化し、通信エラーを引き起こしていることも考えられます。
セッションログのアーカイブなど、データベースのメンテナンスも安定運用のカギです。
