PADの例外処理の使い方(ブロック・アクション別エラー対応)【Power Automate Desktop】

Power Automate Desktop

Power Automate Desktop(PAD)での例外発生時の対応方法について解説します。PADでの例外対応は大きく分けて2種類あります。

  • ブロックエラー発生時の対応
  • 個別エラー発生時の対応

上記のように、エラーが発生してフローが止まってしまうのを防ぐには、例外対応が必要となります。

以降でそれぞれについて初心者向けに分かりやすく解説します。

両者の違いをざっくり

両者の違いをざっくり解説すると、ブロックエラー対応は「そのブロック内のどこかでエラーが発生したら対応」、個別エラー対応は「指定のアクションでエラーが発生したときのみ対応」という違いになります。

ブロックエラー発生時の対応

PADにおける例外対応の手段の1つとして、ブロックエラー発生時の対応があります。

プログラミング言語でいう、try-catchと同じように使うことができ、ブロック内にあるアクションのいずれかでエラーが発生したときに例外対応します。

「ブロックエラー発生時」の設定方法

左側のメニューから「ブロックエラー発生時」アクションをドラッグアンドドロップで真ん中の白いエリアに追加します。

ブロック名は、そのブロック内でどんなことをしているか分かるような名前をつけます。

エラー発生時の対応を設定する

デフォルトでは、「スロー エラー」に設定されており、このままだとエラーが発生したときにフローが落ちてしまいます。そこで、「フロー実行を続行する」を押します。

例外処理モードを選択する

「例外処理モード」を選択します。これは、エラーが発生したときに、次にどのような処理を行うのかを設定するものです。

次のアクションに移動

「次のアクションに移動」を選択すると、文字通り1つ下のアクションが実行されます。次のアクションがない場合は、そのままフローが終了します。

アクションの繰り返し

「アクションの繰り返し」は、エラーが発生したアクションを再度実行します。

例えば、ブラウザが開く前にボタンが押されてエラーが発生したなら、再度実行したときにブラウザが開かれていたら処理に成功するかもしれません。しかし、大抵の場合は何度実行してもエラーが繰り返されるだけで、フローが永遠に終わらなくなってしまう可能性があります。

ラベルに移動

「ラベルに移動」では、エラー時に設定したラベルに移動し、そこから再実行します。

ブロックの先頭に移動する

「ブロックの先頭に移動する」では、ブロック内の一番最初のアクションから再実行されます。

ブロックの末尾に移動する

「ブロックの末尾に移動する」では、ブロックの一番最後に移動します。つまり、ブロックを抜けることになります。

予期しないロジック エラーを取得

「予期しないロジックエラーを取得」については、Microsoftのリファレンスに以下のような記載がありました。

エラー処理のスコープを拡張し、フローの論理エラー (たとえば数値を 0 で除算する、範囲外の位置から項目にアクセスするなど) も取り込みます。

引用:Microsoft Power Automate フロー制御アクション

試しにゼロ除算で試してみます。

「予期しないロジックエラーを取得」をオフにして実行すると、例外のキャッチが行われませんでした。

「予期しないロジックエラーを取得」をオンにして実行すると、例外のキャッチが行われました。よって、オンにしておいたほうがより多くのエラーをキャッチできるということになりますが、気を付けたい点もあります。

使用上の注意点

例えば、リストやデータテーブルなどへのアクセス時に範囲外でエラーが発生したときに、「予期しないロジックエラーを取得」をオンにしておくと、例外が発生しないので、何が原因でエラーが起こっているのか判断しにくくなる可能性があります。

また、そもそもフローが完成した時点で「予期しないロジックエラー」が起こるのであれば、むしろ例外の発生が分かったほうがフローそのものを見直すことができるので、個人的にはオフにしておいたほうが良いかなと思います。

個別のエラー発生時の対応

個別のエラー発生時の対応では、各アクションにてエラーが発生したときの対応を設定することができます。

個別のエラー発生時の設定方法

まず、例外処理を設定したいアクションをクリックします。今回は、「Webページのリンクをクリック」で、うまくクリックできなかったことを考慮して例外処理を追加します。

アクションを開き、左下にある「エラー発生時」を押します。

すると、先ほどと似たような画面が開きます。

再試行ポリシー

エラーが発生した際に、再試行するかどうかを指定します。

なし

再試行を行いません。

固定

再試行を固定間隔で行います。

指数

再試行の間隔を指数関数的に増やします。

例外処理モード

例外処理モードは、ブロックエラー発生時の対応と同様のものになります。

次のアクションに移動

「次のアクションに移動」を選択すると、文字通り1つ下のアクションが実行されます。次のアクションがない場合は、そのままフローが終了します。

アクションの繰り返し

「アクションの繰り返し」は、エラーが発生したアクションを再度実行します。

例えば、ブラウザが開く前にボタンが押されてエラーが発生したなら、再度実行したときにブラウザが開かれていたら処理に成功するかもしれません。しかし、大抵の場合は何度実行してもエラーが繰り返されるだけで、フローが永遠に終わらなくなってしまう可能性があります。

ラベルに移動

「ラベルに移動」では、エラー時に設定したラベルに移動し、そこから再実行します。

「詳細」ではエラー時に変数設定・サブフロー実行が可能

個別のエラー時の対応では、「詳細」からエラー発生時に変数を設定したり、サブフローを実行することができます。

「詳細」を開くと、このアクションで起こりうるエラーが一覧で表示されます。各エラーにある「新しいルール」をクリックし、エラー発生時の動作を追加します。

変数の設定

「変数の設定」では、エラーが発生した際に任意の変数に値をセットできます。

メッセージボックスを出すときの引数や、フラグなどとして使えそうです。

サブフローの実行

「サブフローの実行」では、エラーが発生した際にサブフローを実行します。

サブフローはあらかじめ作成しておき、それを設定します。

実行すると、エラー発生時にサブフローが実行され、メッセージボックスが表示されました。

どうやって使い分けたらいい?

ここまで、ブロックエラー発生時の対応と、個別のエラー発生時の対応の2種類の例外対応について解説してきました。では、それぞれどのように使い分ければ良いかを簡単に紹介します。

ブロックエラーによる例外処理

先述のとおり、ブロックエラーはプログラミング言語でいう「Try – Catch」のような役割としています。

複数のアクションをまとめてエラーハンドリングする場合や、特定のプロセスセクションに対する全体的なエラーハンドリングが必要な場合に適しています。例えば、ウェブページからのデータ抽出やファイル操作など、連続した複数のステップで構成されるプロセスに有効です。

各アクションに一つずつ例外処理を設定するよりも、エラーハンドリングを一箇所に集中させることで、フローの可読性や管理を容易にすることができます。

基本的には、フロー全体をブロックエラーで囲んで、例外発生時にログを記録したりメールで通知するようにすることが多いです。

各アクションに設定する例外処理

個別のアクションに対して特定のエラー処理が必要な場合に適しています。例えば、特定のウェブ要素の検索失敗時の処理など、特定のエラーに対する独自の対応が必要な場合です。

特定のアクションに特化した詳細なエラーハンドリングが可能なので、フロー全体の中で特定のエラーに対してより適切に対処することができるのがメリットです。

まとめ

今回は、Power Automate Desktop(PAD)での例外発生時の対応方法について、

  • ブロックエラー発生時の対応
  • 個別エラー発生時の対応

上記2パターンの方法について解説しました。

例外処理を適切に利用することで、

例外対応をすることのメリット
  • フローが止まることなく最後まで実行できる(安定性・信頼性の向上)
  • 適切な対応が取れる(メッセージでの通知、エラーログの記録など)
  • エラーの原因となる部分が明確になる(デバッグとメンテナンスの容易化)

などの、様々なメリットがあります。個人でPADを使っている限りはそこまで気にすることでもないかもしれませんが、仕事としてPADのフローを作成している方や、クラウドソーシングなどで案件を受ける際には、例外処理を入れることを意識すると良いでしょう。

chaso

文系出身、数字が苦手な平凡主婦。塾講師、大手企業SE、不動産事務、Webライター、QAエンジニアを経て現在RPAエンジニアとして働いています。機械音痴だけど効率化や自動化をこよなく愛しています!お仕事の依頼・ご相談は問い合わせよりお願いいたします♪

chasoをフォローする

コメント

タイトルとURLをコピーしました