13
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

UiPath (produced with UiPath Friends)Advent Calendar 2022

Day 17

【UiPath】リトライスコープ (Retry Scope) の豆知識

Posted at

UiPath RPA デベロッパー上級資格試験 (UiARD) の勉強がてら、リトライスコープについて色々調べた内容をここに記します。

基本的な仕様

公式ドキュメントの説明は次の通り。

説明
条件が満たされないか例外がスローされる限り、含まれているアクティビティをリトライします。

image.png

より細かく言うと、以下のどちらかの条件を満たした時に「アクション」の最初からリトライする。

  • 「アクション」内のアクティビティをすべて実行した後、「条件」に指定したアクティビティが False を返す
  • 「アクション」内、または「条件」に指定したアクティビティがキャッチされていないエラーを返す

また、独自のオプションとして以下の2つを設定できる。

リトライの回数 - シーケンスをリトライする回数です。
リトライの間隔 - 各リトライの合間の時間 (秒数) を指定します。

「リトライの回数」の既定は3回、「リトライの間隔」の既定は5秒に設定されている。

「条件」に指定できるアクティビティは限られる

「要素の存在を確認」や「テキストの存在を確認」など一部のアクティビティしか使えない。
論理値を返すアクティビティなら使えるのかと思いきや、「ファイルの存在を確認」などは使えない。
「True か確認」は論理値を返さないが(おそらく例外的に)使うことができる。

「リトライの回数」はアクションを実行する回数

「リトライの回数を1回に設定する」と聞くと、「エラーが起こったら1回リトライする」とも聞こえるが、
リトライスコープの「リトライの回数」は「アクションを実行する回数」に近い。

  • リトライ回数 1 の場合、アクションを一度実行して終わる。エラーが起こってもリトライしない。
  • リトライ回数 2 の場合、アクションを実行し、エラーが起こったら一度だけリトライする。
  • リトライ回数 0 の場合、アクションを一度も実行せずに終わる。

「条件」は何も設定しなくても良い

「条件」にアクティビティを置かなければ常にTrueを返すのと同じ扱いになる。
なので、この場合は単に「アクション」がエラーを返した時だけリトライする形になる。

以下の例だとC:\Temp\Test.txtのファイルが存在するかを5秒置きに確認し、3回目でも見つからなければエラーになる。
image.png
image.png

「アクション」も何も設定しなくて良い

逆に、「アクション」にも何を設定しなくてよい。
この場合は「条件」に指定したアクティビティがTrueを返すまでリトライする形になる。

以下は上の例の「アクション」にあるアクティビティを「条件」に移した例で、これも処理の流れは同じ。
image.png
image.png

「True か確認」を使うなら「アクション」の最後に置いても「条件」に置いても同じ

image.pngimage.png
どちらでも結果は同じ。
ちなみに昔は「条件」に「True か確認」を置けなかったので、「Is True」アクティビティ(標準パッケージ外)で代用されたりもしていた。

エラーになるまでの時間を考える時はアクティビティのプロパティも考慮に入れる

各アクティビティのプロパティが既定値として、
以下のワークフローは「要素の存在を確認」が対象ウィンドウを見つけられない時、100秒でエラーになる。
image.png

各プロパティは既定値だと、
リトライスコープの「リトライ回数」が3回で、「リトライの間隔」が5秒、
要素の存在の確認の「タイムアウト」が30秒である。

リトライ回数が3回なので「要素の存在の確認」は3回実行される。
リトライの間隔が5秒なので、リトライする際に5秒の待ち時間が挟まる。
「要素の存在の確認」自体のタイムアウト時間が30秒なので、
30秒 + 5秒 + 30秒 + 5秒 + 30秒 のおよそ100秒(1分40秒)でエラーになる、という内訳。
image.png

変数のスコープに考慮する

繰り返しアクティビティ等でも同じだが、内側のシーケンスにはリトライの度に都度入り直す形になるので、
スコープを内側のシーケンスに設定した変数はリトライの度に既定値に戻る。
image.png
image.png

これを防ぐには単にリトライスコープの外側のシーケンスに変数のスコープを設定すればよい。
image.png

これを利用してリトライの度に変数を既定値に戻すのも考えられるが、もしスコープを変えられると台無しになるため、
戻したいならスコープに頼らず代入アクティビティなどで明示的に戻すか、別のワークフローとして切り出したほうがよさそう。

エラーのスロー元はリトライスコープになる

まずリトライスコープ無しでのエラーのログを確認する。
image.png
上のワークフローを実行すると、「Throw」アクティビティが「BusinessRuleException」を投げました、とログには表示される。
image.png

次に、リトライスコープが囲った場合のログを確認する。
image.png
「リトライスコープ」アクティビティが「BusinessRuleException」を投げたことになっている。
リトライスコープ内のどのアクティビティがエラーになったのかはこのログからは読み取れなくなるので注意。
image.png

リトライスコープ内のエラーもグローバルハンドラーに拾われる

「リトライスコープ」の内部にシーケンスを挟まず直接アクティビティを置いた場合は拾われないが、シーケンスを挟むと拾われる。
(「トライキャッチ」アクティビティの挙動と同じ。)
image.png
image.png

参考

動作環境

UiPath.System.Activities 22.10.3

13
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?