知識マップ: Power Automateのエラー処理とリトライ設計 ── 「動いていたフローが止まっていた」を防ぐ
記事「Power Automateのエラー処理とリトライ設計 ── 「動いていたフローが止まっていた」を防ぐ」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。
Power Automateのクラウドフローは、基盤であるAzure Logic Appsの標準リトライポリシーにより一時的な障害の多くを自動的に吸収しますが、データ起因の失敗・権限や認証の切れ・仕様変更にはリトライが効かず、スコープによるTry-Catch-Finallyパターンで捕まえて通知し、Terminateアクションで実行を失敗として記録する必要があります。既定の失敗通知メールは既知の修正方法がある失敗に限られるため当てにできず、失敗の放置はフローの自動無効化や中断につながります。復旧の要となる再送信は処理を最初からやり直すため、処理済みフラグやupsert、トリガー条件による冪等な設計と、必要なら同時実行制御による直列化を組み合わせて、二重実行に強いフローにしておくことが実務上の要点です。
flowchart LR
accTitle: Power Automateのエラー処理とリトライ設計の知識マップ
accDescr: クラウドフローの標準リトライが解決する一時的な障害と、スコープによるTry-Catch-Finallyで捕まえるべきデータ起因・認証切れ・仕様変更の失敗を分け、実行条件の構成やTerminateアクション、失敗通知、フローの自動無効化、再送信と冪等な設計・同時実行制御の関係を示す図
cloud_flow["クラウドフロー"]
retry_policy["標準リトライポリシー"]
azure_logic_apps["Azure Logic Apps"]
transient_failure["一時的な障害"]
data_caused_failure["データ起因の失敗"]
auth_expiry_failure["権限・認証切れによる失敗"]
spec_change_failure["仕様変更起因の失敗"]
scope_try_catch["スコープによるTry-Catch-Finallyパターン"]
run_after_configuration["実行条件の構成(run after)"]
terminate_action["Terminateアクション"]
flow_auto_disable["フローの自動無効化(14日ルール)"]
flow_suspended["フローの中断(suspended)状態"]
dlp_policy["データ損失防止(DLP)ポリシー"]
flow_failure_notification["クラウドフローの失敗通知"]
flow_run_history["フローの実行履歴"]
resubmit_flow_run["再送信(Resubmit)"]
idempotent_flow_design["冪等な設計"]
upsert_pattern["upsert(あれば更新、なければ作成)"]
trigger_condition["トリガー条件(Trigger Conditions)"]
self_trigger_loop["自己トリガーによる多重起動"]
concurrency_control["同時実行制御(concurrency control)"]
dirty_read_in_flow["フロー実行間のダーティリード"]
cloud_flow -->|"利用する"| azure_logic_apps
cloud_flow -.->|"利用する"| retry_policy
retry_policy -->|"軽減する"| transient_failure
retry_policy -->|"用いるのは非推奨"| data_caused_failure
retry_policy -->|"用いるのは非推奨"| auth_expiry_failure
retry_policy -->|"用いるのは非推奨"| spec_change_failure
scope_try_catch -->|"推奨される対応"| data_caused_failure
scope_try_catch -->|"推奨される対応"| auth_expiry_failure
scope_try_catch -->|"利用する"| run_after_configuration
scope_try_catch -->|"利用する"| terminate_action
auth_expiry_failure -->|"原因になり得る"| flow_auto_disable
auth_expiry_failure -.->|"原因になり得る"| flow_suspended
dlp_policy -->|"原因になり得る"| flow_suspended
flow_failure_notification -->|"用いるのは非推奨"| data_caused_failure
flow_auto_disable -->|"で確認できる"| flow_run_history
resubmit_flow_run -->|"前提とする"| flow_run_history
idempotent_flow_design -->|"推奨される対応"| resubmit_flow_run
idempotent_flow_design -->|"利用する"| upsert_pattern
idempotent_flow_design -->|"利用する"| trigger_condition
trigger_condition -->|"防止する"| self_trigger_loop
idempotent_flow_design -.->|"利用する"| concurrency_control
concurrency_control -->|"軽減する"| dirty_read_in_flow
概念間の関係(全22件)
図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。
- クラウドフローはAzure Logic Appsを利用します。
- クラウドフローは標準リトライポリシーを利用します。
- 標準リトライポリシーは一時的な障害を軽減します。
- 標準リトライポリシーをデータ起因の失敗に用いることは推奨されません。
- 標準リトライポリシーを権限・認証切れによる失敗に用いることは推奨されません。
- 標準リトライポリシーを仕様変更起因の失敗に用いることは推奨されません。
- スコープによるTry-Catch-Finallyパターンはデータ起因の失敗に対する本記事の推奨です。
- スコープによるTry-Catch-Finallyパターンは権限・認証切れによる失敗に対する本記事の推奨です。
- スコープによるTry-Catch-Finallyパターンは実行条件の構成(run after)を利用します。
- スコープによるTry-Catch-FinallyパターンはTerminateアクションを利用します。
- 権限・認証切れによる失敗はフローの自動無効化(14日ルール)の原因になることがあります。
- 権限・認証切れによる失敗はフローの中断(suspended)状態の原因になることがあります。
- データ損失防止(DLP)ポリシーはフローの中断(suspended)状態の原因になることがあります。
- クラウドフローの失敗通知をデータ起因の失敗に用いることは推奨されません。
- フローの自動無効化(14日ルール)はフローの実行履歴で確認できます。
- 再送信(Resubmit)はフローの実行履歴を前提とします。
- 冪等な設計は再送信(Resubmit)に対する本記事の推奨です。
- 冪等な設計はupsert(あれば更新、なければ作成)を利用します。
- 冪等な設計はトリガー条件(Trigger Conditions)を利用します。
- トリガー条件(Trigger Conditions)は自己トリガーによる多重起動を防ぎます。
- 冪等な設計は同時実行制御(concurrency control)を利用します。
- 同時実行制御(concurrency control)はフロー実行間のダーティリードを軽減します。
主要概念の定義
機械可読データ
このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。