画面遷移時のクリックのタイミングが合わない場合の処理について

画面遷移時に表示が完了する前にクリックを行ってしまい、タイミングが合わない場合
リトライの中にクリック処理を入れて対応しています。

いくつか、疑問があるので教えてください。

①上記、リトライがベストでしょうか

以下、②~⑤クリック、入力のアクティビティの設定中にある項目について
タイミングが合わない場合に使用することはありますか?
どのような場合に使用するのでしょうか

②クリック(入力)をシミュレート
API呼び出し以外は使用しない?
③準備完了まで待機
Interactive,Completeを設定すると読込まれるまで待つとありますが、うまく動作せず
ここはデフォルトのままで、リトライさせるとうまく動作します
④実行前の待機時間:強制的に待機?
⑤実行後の待機時間:強制的に待機?

参照:https://www.uipath.com/ja/blog/developer/click-activity

1 Like

うまく行った手法がベストです。

サイトによって、これ!と言う答えがなく、やって安定すればそれがベストって事になります。

1 Like

ワークフローの安定化にはみんな苦労しておりまして、みんないろいろなパターンを持っていると思います。

① 一定時間待つ(待機アクティビティや実行後の待機時間など)
→本当に困ったときには役立つが、ワークフローのシナリオがどんどん遅くなっていく諸刃の剣
② 次画面が表示されたかを判断する(要素の有無を検出/要素を探す)
→次画面が出たのをワークフローが認識してから動くので安定性は上がる
③ 要素が出たときに実行させる( On Element Appear 系)
→次画面が出たのをワークフローが認識してから動くので安定性は上がる
コンテナ(中にアクティビティを抱えこむ(Excel Application Scopeのよう)ので、
書き方にスキキライはでるかも・・・あと無限に繰り返すオプションでバグを起こしがち)

て感じですかね。
私は② or ③ をメインに使って、ボタンを押しても反応しないような場合にリトライスコープ、
どーしても上手くいかない場合に① って感じで使い分けています。

2 Likes

サイトによって安定するものが違うんですね。
統一性のある作り方にしたかったんですが難しそうですね。
ありがとうございます。

yukinoさん

パターン化するというのはいいですね。
開発にあたり、ある程度の統一性を持たせたかったのでとても参考になりました。
皆さん、苦労されているのですね。
勉強になりました。ありがとうございました。

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.