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

適用於：Azure Logic Apps (使用量 + 標準)

適當地處理相依系統所造成的停機情況或問題，對任何整合架構來說都是種挑戰。 為協助您建立強固且具復原性的整合方案以便順利處理問題與失敗，Azure Logic Apps 提供一流的錯誤和例外狀況處理體驗。

重試原則

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

重試原則限制

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

重試原則型別

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

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

1. 在 Azure 入口網站中，在設計工具中開啟您的邏輯應用程式工作流程。

2. 根據您使用的是使用量或標準工作流程，開啟觸發程序或動作的 [設定]。

   • 使用量：在動作圖形中，開啟省略符號功能表 (...)，並選取 [設定]。

   • 標準：在設計工具上，選取動作。 在詳細資料窗格中，選取 [設定]。

3. 如果觸發程序或動作支援重試原則，請於 [重試原則] 下，選取您想要的原則型別。

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

1. 如有必要，請完成設計工具中的先前步驟，確認觸發程序或動作是否支援重試原則。

2. 在程式碼檢視編輯器中，開啟您的邏輯應用程式工作流程。

3. 在觸發程序或動作定義中，將 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、none、fixed 或 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)。 如需詳細資訊，請檢閱指數間隔。

預設重試原則

支援重試原則的連接器作業會使用預設原則，除非您選取不同的重試原則。 對於大多數作業，預設重試原則是一個指數間隔原則，其以指數增加的間隔傳送最多 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
      }
   }
}

指數間隔重試原則

指數間隔重試原則會指定觸發程序或動作先等候隨機間隔，再傳送下一個要求。 隨機間隔會從指數成長範圍選取。 或者，您可以根據是否具備使用量或標準邏輯應用程式工作流程，指定自己的最小和最大間隔，藉此覆寫預設的最小和最大間隔。

隨機變數範圍

對於指數間隔重試原則，下表顯示 Azure Logic Apps 用來在每個重試的指定範圍內，產生統一隨機變數的一般演算法。 指定範圍最高可達並包括重試次數。

管理「執行時間點」行為

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

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

若要確保無論動作的前置任務狀態為何，該動作仍可執行，您可以變更動作的「執行時間點」行為，處理前置任務失敗的狀態。 如此一來，當前置任務的狀態為 Succeeded (成功)、Failed (失敗)、Skipped (略過)、TimedOut (逾時) 或所有這些狀態時，動作仍會執行。

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

變更設計工具中的「執行時間點」行為

在程式碼檢視編輯器中變更「執行時間點」行為

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

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

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

3. 在此範例中，將 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"
   }
   

4. 若要在無論前置任務動作標示為 Failed、Skipped 或 TimedOut 的情況下指定動作執行，請新增其他狀態：

   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed", "Skipped", "TimedOut"
      ]
   },
   

以範圍和其結果評估動作

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

若要檢查範圍的狀態，您可以使用檢查工作流程執行狀態時所用的相同準則，例如 Succeeded (成功)、Failed (失敗) 等。

根據預設，當範圍的所有動作都成功時，範圍的狀態會標示為 Succeeded (成功)。 如果範圍內的最後動作標示為 Failed (失敗) 或 Aborted (中止)，範圍的狀態會標示 Failed (失敗)。

若要攔截 Failed (失敗) 範圍的例外狀況，並執行處理這些錯誤的動作，您可以使用 Failed (失敗) 範圍的「執行時間點」設定。 如此一來，如果範圍內的「任何」動作失敗，而您對該範圍使用「執行時間點」設定，則可建立單一動作來擷取失敗。

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

取得失敗的內容和結果

雖然從範圍擷取失敗很實用，但還是建議您取得更多內容以了解實際失敗的動作，以及任何錯誤或狀態碼。 result() 函式會傳回範圍動作中最上層動作的結果。 此函式接受範圍名稱做為單一參數，並傳回包含最上層動作結果的陣列。 這些動作物件包含的屬性與 actions() 函式傳回的屬性相同，例如動作的開始時間、結束時間、狀態、輸入、相互關聯識別碼和輸出。

若要取得失敗範圍中的動作內容，您可以使用 @result() 運算式搭配範圍名稱和「執行時間點」設定。 若要將傳回的陣列篩選為狀態是 Failed (失敗) 的動作，您可以新增篩選陣列動作。 若要執行傳回為失敗的動作，請採用傳回的篩選陣列，並使用針對每個迴圈。

下列 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"
      ]
   }
}

下列步驟描述此範例中發生的情況：

1. 若要從 My_Scope 內的所有動作取得結果，篩選陣列動作會使用此篩選條件運算式：@result('My_Scope')

2. 篩選陣列的條件是狀態等於 Failed 的任何 @result() 項目。 此條件會將具有 My_Scope 所有動作結果的陣列篩選成只有失敗動作結果的陣列。

3. 對「篩選陣列」輸出執行 For_each 迴圈動作。 此步驟會對之前篩選的每個失敗動作結果執行動作。

   如果範圍中的單一動作失敗，For_each 迴圈中的動作只會執行一次。 如果有多個失敗動作，則會導致對每個失敗執行一個動作。

4. 在 For_each 項目回應本文上傳送 HTTP POST，即 @item()['outputs']['body'] 運算式。

   @result() 項目圖形和 @actions() 圖形相同，並可透過相同方式剖析。

5. 包含兩個具有失敗動作名稱 (@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 範例和情節