スクリーンロック(画面ロック)

[denden]

はじめまして。
uipathの勉強中の身です。

ロボットから動作させた別のアプリケーションで時間のかかるものがあり、アプリケーション動作中にスクリーンロックがかかってしまいます。
その後、アプリケーション動作が終了したあとに再度ロボットで後続の操作を行いたいのですが、
画面ロックがかかってしまっているため、動作できず、エラーとなってしまいます。
画面ロックはセキュリティ上の観点から、ロックしない設定に容易に変更が出来ず、
attended robotでの運用を想定しています。

①なにか回避方法(ロックさせない)などあるのでしょうか。
→画面ロックさせないように定期的にクリック(default)を挟む…など強引な手段を考えもしましたが、意図せず何かのボタンをクリックする可能性もあるので危ないですよね…

②そもそも、考え方として、画面ロックされてしまう状況(処理に長時間かかるアプリの使用)を含むシナリオを、attended robot(orchestraterなし)で運用すること自体が間違っているのでしょうか。
→そもそもorchestraterを導入すべきシナリオ？
→ARでこのようなシナリオを運用にしたいのであれば、PCの設定で画面ロックされないようにするべき？

[Yoichi]

こんにちは

まずARライセンスの話になりますが、利用規約上、ユーザーの監視のもとに実行しなければ
ならないことになっています。このあたりの解釈は幅があるかと思いますが、この点はあらかじめ
留意いただいた方が良いかもしれません。

技術的な観点からは、ロックさせないというアプローチの他に、ロック時でも動作可能にする
という選択もあります。後者は対象のアプリケーションにも依存しますが、Simulate Click等で
実装し、ロック画面でエラーとなるアクティビティを排除するとロック時でも動作すると思うので、
それが可能ならそのようにした方が良いかもしれません。

ロックさせないアプローチですが、例えばHoverのようなアクティビティをDefaultモードで
使用すると、実害なくマウス操作したことになると思いますので、一度試してみてはと
思います。

[denden]

早速の回答ありがとうございます。
また、返答が遅くなってしまい申し訳ありません。

おっしゃるとおり、ARなので、ユーザーが起動し、ユーザーの監視下の元、動作させるべきロボットです。
ご指摘ありがとうございます。
そして、技術的な観点でのご回答もいただき、ありがとうございます。
アプリケーションの問題でシミュレートだとうまく動作しない場合があるので困っておりました。
なるほど、Hoverをデフォルトで動作させれば実害はほとんどなさそうです。
ご回答ありがとうございます。
非常に参考になりました。
試してみます。