處理 Azure Logic Apps 中的錯誤和例外狀況

發行項
12/09/2023

適用于： Azure Logic Apps（取用 + 標準）

任何整合架構都能適當地處理相依系統所造成的停機時間或問題，可能會帶來挑戰。為了協助您建立健全且具彈性的整合，以正常處理問題和失敗，Azure Logic Apps 提供處理錯誤和例外狀況的第一級體驗。

重試原則

針對最基本的例外狀況和錯誤處理，您可以在觸發程式或動作上支援時使用 重試原則 ，例如 HTTP 動作。如果觸發程式或動作的原始要求逾時或失敗，導致 408、429 或 5xx 回應，重試原則會指定觸發程式或動作會根據原則設定重新傳送要求。

重試原則限制

如需重試原則、設定、限制和其他選項的詳細資訊，請參閱重試原則限制。

重試原則類型

支援重試原則的連線or 作業會使用 除非您選取不同的重試原則，否則預設 原則除外。

重試原則	描述
Default	針對大部分作業，預設重試原則是指數間隔原則，以指數遞增間隔傳送最多 4 次重試。這些間隔會縮放 7.5 秒，但上限為 5 到 45 秒。數個作業使用不同的預設重試原則，例如固定間隔原則。如需詳細資訊，請檢閱預設重試原則類型。
None	請勿重新傳送要求。如需詳細資訊，請檢閱 [無 - 沒有重試原則 ]。
指數間隔	此原則會等候隨機間隔，這是在傳送下一個要求之前，先從指數成長範圍選取的間隔。如需詳細資訊，請檢閱指數間隔原則類型。
固定間隔	此原則會先等候指定的間隔，再傳送下一個要求。如需詳細資訊，請檢閱固定間隔原則類型。

變更設計工具中的重試原則類型

在 Azure 入口網站中，在設計工具中開啟邏輯應用程式工作流程。
根據您是否使用取用或標準工作流程，開啟觸發程式或動作的設定。
- 取用：在動作圖形上，開啟省略號功能表（ ... ），然後選取 [設定 ]。
- 標準：在設計工具上，選取動作。在詳細資料窗格中，選取 [設定 ]。
如果觸發程式或動作支援重試原則，請在 [重試原則 ] 底下 選取您想要的原則類型。

在程式碼檢視編輯器中變更重試原則類型

如有必要，請完成設計工具中的先前步驟，確認觸發程式或動作是否支援重試原則。
在程式碼檢視編輯器中開啟邏輯應用程式工作流程。

在觸發程式或動作定義中，將 retryPolicy JSON 物件新增至該觸發程式或動作的物件 inputs 。否則，如果沒有 retryPolicy 物件存在，觸發程式或動作會 default 使用重試原則。

"inputs": {
   <...>,
   "retryPolicy": {
      "type": "<retry-policy-type>",
      // The following properties apply to specific retry policies.
      "count": <retry-attempts>,
      "interval": "<retry-interval>",
      "maximumInterval": "<maximum-interval>",
      "minimumInterval": "<minimum-interval>"
   },
   <...>
},
"runAfter": {}

必要

屬性	值	類型	描述
`type`	<retry-policy-type>	String	要使用的重試原則類型： `default` 、、 `nonefixed` 、或 `exponential`
`count`	<retry-attempts>	整數	針對 `fixed` 和 `exponential` 原則類型，重試嘗試次數，其值為 1 - 90。如需詳細資訊，請參閱固定間隔和指數間隔。
`interval`	<retry-interval>	String	若為 `fixed` 和 `exponential` 原則類型，則為 ISO 8601 格式的重試間隔值。針對原則 `exponential` ，您也可以指定選擇性的最大值和最小間隔。如需詳細資訊，請參閱固定間隔和指數間隔。耗用量：5秒（ `PT5S` ）至1天（ `P1D` ）。標準：針對具狀態工作流程，5 秒（ `PT5S` ）到 1 天（ `P1D` ）。針對無狀態工作流程，1 秒（ `PT1S` ）到 1 分鐘（ `PT1M` ）。

選擇性

屬性	值	類型	描述
`maximumInterval`	<maximum-interval>	String	針對原則 `exponential` ，隨機選取間隔的最大間隔為 ISO 8601 格式。預設值為 1 天（ `P1D` ）。如需詳細資訊，請檢閱指數間隔。
`minimumInterval`	<minimum-interval>	String	針對原則 `exponential` ，隨機選取間隔的最小間隔為 ISO 8601 格式。預設值為 5 秒（ `PT5S` ）。如需詳細資訊，請檢閱指數間隔。

預設重試原則

支援重試原則的連線or 作業會使用 除非您選取不同的重試原則，否則預設 原則除外。針對大部分作業，預設 重試原則是指數間隔原則， 以指數遞增 間隔傳送最多 4 次重試 。這些間隔會縮放 7.5 秒，但上限為 5 到 45 秒。數個 作業使用不同的預設 重試原則，例如固定間隔原則。

在您的工作流程定義中，觸發程式或動作定義不會明確定義預設原則，但下列範例顯示預設重試原則對 HTTP 動作的行為：

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

無 - 無重試原則

若要指定動作或觸發程式不會重試失敗的要求，請將 < retry-policy-type > 設定為 none 。

固定間隔重試原則

若要指定動作或觸發程式在傳送下一個要求之前等候指定的間隔，請將 retry-policy-type > 設定 < 為 fixed 。

範例

此重試原則會在第一次失敗的要求之後再嘗試兩次取得最新消息，每次嘗試之間延遲 30 秒：

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

指數間隔重試原則

指數間隔重試原則會指定觸發程式或動作會在傳送下一個要求之前等候隨機間隔。這個隨機間隔是從指數成長範圍中選取的。您可以選擇性地根據您的使用量或標準邏輯應用程式工作流程，指定您自己的最小和最大間隔，以覆寫預設的最小和最大間隔。

名稱	耗用量限制	標準限制	備註
延遲上限	預設值：1 天	預設值：1 小時	若要變更取用邏輯應用程式工作流程中的預設限制，請使用重試原則參數。若要變更標準邏輯應用程式工作流程中的預設限制，請檢閱在單一租使用者 Azure Logic Apps 中編輯邏輯應用程式的主機和應用程式設定。
最小延遲	預設值：5 秒	預設值：5 秒	若要變更取用邏輯應用程式工作流程中的預設限制，請使用重試原則參數。若要變更標準邏輯應用程式工作流程中的預設限制，請檢閱在單一租使用者 Azure Logic Apps 中編輯邏輯應用程式的主機和應用程式設定。

名稱

耗用量限制

標準限制

備註

延遲上限

預設值：1 天

預設值：1 小時

若要變更取用邏輯應用程式工作流程中的預設限制，請使用重試原則參數。

若要變更標準邏輯應用程式工作流程中的預設限制，請檢閱在單一租使用者 Azure Logic Apps 中編輯邏輯應用程式的主機和應用程式設定。

最小延遲

預設值：5 秒

若要變更取用邏輯應用程式工作流程中的預設限制，請使用重試原則參數。

若要變更標準邏輯應用程式工作流程中的預設限制，請檢閱在單一租使用者 Azure Logic Apps 中編輯邏輯應用程式的主機和應用程式設定。

隨機變數範圍

針對指數間隔重試原則，下表顯示 Azure Logic Apps 用來為每個重試產生指定範圍內統一隨機變數的一般演算法。指定的範圍最多可以包含重試次數。

重試編號	最小間隔	最大間隔
1	max（0， < minimum-interval > ）	min（interval， < maximum-interval > ）
2	max（interval， < minimum-interval > ）	min（2 * interval， < maximum-interval > ）
3	max（2 * interval， < minimum-interval > ）	min（4 * interval， < maximum-interval > ）
4	max（4 * interval， < minimum-interval > ）	min（8 * interval， < maximum-interval > ）
....	....	....

管理「執行後」行為

當您在工作流程設計工具中新增動作時，會隱含宣告用來執行這些動作的順序。動作執行完成之後，該動作會標示為狀態，例如 [成功 ]、[失敗 ]、 [ 略過] 或 [TimedOut ]。根據預設，您在設計工具中新增的動作只會在前置專案完成 且狀態為 [成功 ] 之後執行。在動作的基礎定義中， runAfter 屬性會指定必須先完成的前置動作，以及在後續動作可以執行之前允許該前置專案的狀態。

當動作擲回未處理的錯誤或例外狀況時，動作會標示 為 [失敗] ，且任何後續動作都會標示為 [略過]。 如果此行為發生于具有平行分支的動作，Azure Logic Apps 引擎會遵循其他分支來判斷其完成狀態。例如，如果分支以 [略過 ] 動作結束 ，該分支的完成狀態會以該略過動作的前置狀態為基礎。工作流程執行完成之後，引擎會評估所有分支狀態，以判斷整個執行的狀態。如果有任何分支在失敗中結束，整個工作流程執行都會標示為 [失敗]。

Conceptual diagram with examples that show how run statuses are evaluated.

若要確定動作仍可執行，儘管其前置專案的狀態，您可以變更動作的「執行後」行為，以處理前置任務未成功的狀態。如此一來，當前置任務的狀態為 Succeeded、Failed、Skipped 、 TimedOut 或所有這些狀態時，動作就會執行。

例如，若要執行 Office 365 Outlook 在 Excel Online 將資料列新增至資料表 前置動作之後傳送電子郵件 動作標示 為失敗 ，而不是成功，請使用設計工具或程式碼檢視編輯器變更「執行後」行為。

注意

在設計工具中，[在之後執行] 設定不適用於緊接在觸發程式的動作，因為觸發程式必須先順利執行，才能執行第一個動作。

在 Azure 入口網站中，開啟設計工具中的邏輯應用程式工作流程。
在設計工具上，選取動作圖形。在詳細資料窗格中，選取 [ 執行之後 ]。

[ 執行後] 窗格會顯示目前選取動作的前置動作。
展開前置動作節點，以檢視所有「執行後」狀態。

根據預設，[在之後執行] 狀態會設定為成功。因此，前置動作必須先成功執行，才能執行目前選取的動作。
將「執行之後」行為變更為您想要的狀態。請先確定您先選取選項，再清除預設選項。您必須一律至少選取一個選項。

下列範例會選取失敗。
若要指定目前的動作是否標示為 Failed 、 Skipped 或 TimedOut ，請選取其他狀態。
若要要求執行多個前置動作，每個動作都有自己的「執行之後」狀態，請展開 [ 選取動作 ] 清單。選取您想要的前置動作，並指定其必要的「執行後」狀態。
當您準備好時，請選取 [ 完成 ]。

在程式碼檢視編輯器中變更「執行之後」行為

在 Azure 入口網站中，在程式碼檢視編輯器中開啟邏輯應用程式工作流程。

在動作的 JSON 定義中，編輯 runAfter 具有下列語法的屬性：

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

在此範例中，將 runAfter 屬性從 Succeeded 變更為 Failed ：

"Send_an_email_(V2)": {
   "inputs": {
      "body": {
         "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
         "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
         "To": "Sophia.Owen@fabrikam.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/v2/Mail"
   },
   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed"
      ]
   },
   "type": "ApiConnection"
}

若要指定動作執行前身動作是否標示為 Failed 、 Skipped 或 TimedOut ，請新增其他狀態：
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

使用範圍及其結果評估動作

類似于使用「執行後」設定的個別動作之後執行步驟，您可以將動作群組在範圍內。當您想要以邏輯方式將動作分組在一起、評估範圍的匯總狀態，以及根據該狀態執行動作時，您可以使用範圍。在範圍中的所有動作完成執行之後，範圍本身就會取得自己的狀態。

若要檢查範圍的狀態，您可以使用用來檢查工作流程執行狀態的相同準則，例如 [成功 ]、 [失敗 ] 等。

根據預設，當所有範圍的動作都成功時，範圍的狀態會標示為 [ 成功]。如果範圍中的最後一個動作標示 為 [ 失敗] 或 [中止 ]，則範圍的狀態會標示 為 [失敗]。

若要攔截失敗範圍中的 例外狀況，並執行處理這些錯誤的動作，您可以使用失敗 範圍的「執行後」設定 。 如此一來，如果範圍中的任何動作都失敗，而且您使用該範圍的「執行後」設定，您可以建立單一動作來攔截失敗。

如需範圍限制，請參閱限制和設定。

取得失敗的內容和結果

雖然從範圍攔截失敗很有用，但您可能也想要更多內容來協助您瞭解確切失敗的動作，以及任何錯誤或狀態碼。函 result() 式會傳回範圍動作中最上層動作的結果。此函式接受範圍的名稱做為單一參數，並傳回具有來自這些最上層動作結果的陣列。這些動作物件的屬性與函式所 actions() 傳回的屬性相同，例如動作的開始時間、結束時間、狀態、輸入、相互關聯識別碼和輸出。

注意

函 result() 式只會 從最上層動作傳回結果，而不是從更深入的巢狀動作傳回結果 ，例如參數或條件動作。

若要取得範圍中失敗之動作的內容，您可以使用 @result() 運算式搭配範圍的名稱和「執行後執行」設定。若要將傳回的陣列篩選為狀態為 [ 失敗] 的動作，您可以新增 [篩選陣列 ] 動作。 若要執行傳回失敗動作的動作，請採取傳回的篩選陣列，並使用 For each 迴圈。

下列 JSON 範例會針對名為 My_Scope 範圍動作內失敗的任何動作，傳送具有回應本文的 HTTP POST 要求。範例後面接著詳細說明。

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

下列步驟說明此範例中會發生什麼事：

若要從My_Scope 內的所有動作取得結果， 篩選陣列 動作會使用此篩選運算式：@result('My_Scope')
Filter Array 的條件 是狀態等於 Failed 的任何 @result() 專案。此條件會篩選具有所有動作結果的陣列，該陣列只會從 My_Scope 到只有失敗動作結果的陣列。
For_each在篩選的陣列輸出上執行迴圈動作。此步驟會針對先前篩選的每個失敗動作結果執行動作。

如果範圍中的單一動作失敗，迴圈中的 For_each 動作只會執行一次。多個失敗的動作會導致每次失敗一個動作。
在專案回應本文上 For_each 傳送 HTTP POST，這是 @item()['outputs']['body'] 運算式。

專案 @result() 圖形與 @actions() 圖形相同，而且可以以相同方式剖析。
包含兩個具有失敗動作名稱（ @item()['name'] ）的自訂標頭，以及失敗的執行用戶端追蹤識別碼（ @item()['clientTrackingId'] ）。

如需參考，以下是單 @result() 一專案的範例，其中顯示 name 上一個範例中剖析的、 body 和 clientTrackingId 屬性。在 For_each 動作之外， @result() 傳回這些物件的陣列。

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

若要執行不同的例外狀況處理模式，您可以使用本文先前所述的運算式。您可以選擇在接受整個篩選失敗陣列的範圍之外執行單一例外狀況處理動作，並移除 For_each 動作。您也可以包含回應中的其他實用屬性 \@result() ，如先前所述。

設定 Azure 監視器記錄

上述模式是處理執行中發生的錯誤和例外狀況的實用方式。不過，您也可以識別並回應與執行無關的錯誤。若要評估執行狀態，您可以監視執行的記錄和計量，或將它們發佈至您偏好的任何監視工具。

例如， Azure 監視器提供簡化的方式，將所有工作流程事件，包括所有執行和動作狀態傳送至目的地。您可以在 Azure 監視器中設定特定計量和閾值的警示。您也可以將工作流程事件傳送至 Log Analytics 工作區或 Azure 儲存體帳戶。或者，您可以透過 Azure 事件中樞串流處理所有事件到 Azure 串流分析。在串流分析中，您可以根據診斷記錄中的任何異常、平均值或失敗來撰寫即時查詢。您可以使用串流分析將資訊傳送至其他資料來源，例如佇列、主題、SQL、Azure Cosmos DB 或 Power BI。

如需詳細資訊，請參閱設定 Azure 監視器記錄並收集 Azure Logic Apps 的診斷資料。

下一步

深入瞭解 Azure Logic Apps 範例和案例