Guarded Choice（ガードチョイス）の内部挙動解説

Guarded choiceステップはその後のアクションと関連する幾つかの条件を判断するために利用されます。

設定されたいずれかの条件やガードが最初に満たされると、それに関連したアクションやステップが実行されます。これはボタンなどのインターフェイス要素がマウス移動やクリック動作などを実行する前に表示されていることを保証するために主に使用されます。無制限に待ち状態が発生することを避けるために、タイムアウトガードが追加されます。

Kapowロボットが必要な要素を発見しデザインしたとおりに動作することを確実にするために、ロケーションとタイムアウトガードが使用可能です。

とのことですが、具体的な挙動と使い分けについてはいまいちイメージがつかめません。以下、具体的なGuarded Choice（ガードチョイス）のパターン別の挙動と実際のシーンでの使い分けについて解説します。

各 Guard の実行開始タイミングと判定タイミング

Guarded Choice（ガードチョイス）が実行されると、各Guardは一斉に動作を始めますが、Location Not Foundについては実行直後の状態で成否を判定します。

また、Location Found と Tree Stops Changing については同様にFinderに指定したエレメントの有無を判断して成否を判断しますが、以下の2点について違いがあります。

1. Finderの対象範囲
2. 成否判定タイミング

まず、１．については Location Found が画面上のボタンやテキストなど Component レベルでの判断を実行するのに対し、Tree Stops Changing については特定画面のApplicationレベルでの判断となります。

次に２．については Location Found が対象エレメントの状態（有効/無効）は考慮せず単にエレメントの有無を判断するのに対し、
Tree Stops Changing は対象エレメントのバックグラウンド処理（ページの読込とエレメントツリーの展開完了）を検知したら指定時間待機して、エレメントの有無を判断します。

つまり、操作対象アプリケーションによっては、
Location Foundによる判定では、まだページローディング時の初期化処理が完了する前にエレメント要素の有無を判定してしまい、
ボタン等が有効化されていない時点でその後のクリック操作等を実施して、うまく動作しないということが発生します。
Tree Stops Changing による判定では、ページローディング時の初期化処理により、エレメント状態が変化したことを検知して待機し、
エレメント状態が変化せずに指定した待機時間が経過した場合に、エレメント有無を判定して、
その後のクリック操作等を安全に実施することが出来ます。

以下、発生例となります。
例：Ajaxなどによりページ読込後にプルダウンの要素が生成されるようなWebシステム

このタイミングの問題は往々にしてロボット作成時には発見しにくく、実際にデバッグ実行するタイミングや本番環境にてRoboServerにより効率的な処理が行われた場合に初めて発見されたりする厄介な問題です。

最後にLocation Removed についてですが、これは一時的に表示されるプログレスバーやスプラッシュ画面の表示とクローズを判断するためのガードであり特定エレメントの表示からクローズまでを判断するものですが、v10.2時点ではプロセスレベルで状態を監視しており、対象ウィンドウが特定アプリケーションの子画面として表示されている場合、FinderはComponentレベルで設定可能なもののDAS自体は対象プロセスの有無まで監視しており、いつまでのTRUEにならない問題が発生します。代替案としてはProgram Managerタブに対し、当該ウィンドウを画像判定にてFinder設定することによりウィンドウの表示からクローズまでを監視できるようになります。

各 Guard の利用シーン

上記の特性から以下の使い分けをお勧めします。