はじめに
日頃、Blue prismの開発案件を担当しておりますが参画したての頃こんなエラーに良く遭遇していました。
-
最速のデバッグだとプロセスがエラーになる
-
セッション実行にした途端上手く動かなくなる
後輩からも似たような相談を受ける事が増えたので今回はここにまとめようと思います。
今回使用した動作環境
- Blue Prism ver6.10.1
自動化したもの
今回は、「yahoo路線情報を起動し、運行情報をクリックする」を自動化しました。
アプリを起動し、下記画像の「運行情報」ボタンをクリックします。
よくある原因
多い事象として以下が考えられます。
-
アプリで読み込み時間が発生し、その間にプロセスの処理が進んでしまう
-
アプリだけ先に進んでしまいプロセスが追い付かない
要するにプロセスとアプリ間の動作で足並みが揃っていない事が原因です。
これらは、オブジェクトやプロセスの実装を修正すれば大抵解決できるのでその方法を下記にまとめてみました。
オブジェクト側の対策
1.画面遷移する場合は、遷移後の要素が存在するか待機ステージを入れる
アプリの起動やボタンを押して画面遷移を行う場合は、遷移後の画面が表示されているか
待機ステージを入れて確認しましょう
この「起動」ステージの後に・・・
待機ステージを入れ、起動後の要素が存在するか確認しましょう。
今回、遷移後に確認する要素は画面赤枠のロゴにしました。
2.待機ステージの条件は「親ドキュメントの読み込み完了」に設定する
待機プロパティの条件には「親ドキュメントの読み込み完了」を指定します。
これにすると「要素が存在し且つ画面の読込みが完了しているか」を確認できるまで待機するので
オブジェクトがアプリの動作と合わせてくれます。
アプリによっては画面遷移に時間がかかる場合もあるのでその都度、待機時間を調整する必要があります。
プロセス側の対策
リトライロジックを実装する
オブジェクトの修正は完了しました。
次はプロセスにも一工夫しましょう
こうする事で予期しないエラー等が発生してもリトライするので稼働の安定性が向上します。
配置した各データアイテムの詳細は以下の表をご確認ください。
| データアイテム | 説明 |
|---|---|
| Retry Limit | リトライの上限を設定する |
| Retry Count | 現在のリトライ回数をカウントする |
リトライの判断をする「再試行？」の判断ステージには以下のロジックを実装しています。
[Retry Count]<[Retry Limit]
オブジェクト側でビジネス例外などを実装しており、その時はリトライをさせない場合は以下のように設定します。
[Retry Count]<[Retry Limit] AND (Lower(ExceptionType())=
"system exception" OR Lower(ExceptionType())="internal")
追加で配置した計算ステージには以下のロジックを実装しています。
追加した計算ステージのプロパティについて
リトライをする際はここで現在のリトライ数に+1します。
ここでは、前の処理でリトライした回数を「0」にリセットしています。
補足
上記のリトライ実装では、起動アクションのリトライをそのまま実行しますがアプリケーションによっては
2重起動を避けるため以下のようにリトライ時に「Kill Process」アクションを入れるパターンもあります。
これを入れる事でアプリを強制終了できます。
| オブジェクト名 | アクション名 |
|---|---|
| Utility - Environment | Kill Process |
| 入力プロパティ | 値（例） |
|---|---|
| Process Name | 起動させたプロセス名を入力する（例：google chromeならchrome,Microsoft Edgeならedgeなど） |
さいごに
いかがだったでしょうか？
今回はプロセスとアプリで動作にズレが起きない対策についてまとめてみました。
弊社では他にも
-
グローバルマウスクリックを行う際、「右クリック」を行う方法
-
ウィンドウサイズの取得方法
などBlueprismの開発で得たナレッジ・小技などを記事にしておりますので
そちらも是非参考にしていただければと思います！