Hantera fel och undantag i Azure Logic Apps
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Det sätt på vilket en integreringsarkitektur hanterar driftstopp eller problem som orsakas av beroende system kan utgöra en utmaning. För att hjälpa dig att skapa robusta och motståndskraftiga integreringar som på ett smidigt sätt hanterar problem och fel ger Azure Logic Apps en förstklassig upplevelse för hantering av fel och undantag.
Principer för nya försök
För den mest grundläggande undantags- och felhanteringen kan du använda återförsöksprincipen när den stöds för en utlösare eller åtgärd, till exempel HTTP-åtgärden. Om utlösaren eller åtgärdens ursprungliga begäran överskrider tidsgränsen eller misslyckas, vilket resulterar i ett svar på 408, 429 eller 5xx, anger återförsöksprincipen att utlösaren eller åtgärden skickar begäran på nytt per principinställningar.
Principbegränsningar för återförsök
Mer information om återförsöksprinciper, inställningar, gränser och andra alternativ finns i Begränsningar för återförsöksprinciper.
Återförsök av principtyper
Anslut eller åtgärder som stöder återförsöksprinciper använder Standardprincip om du inte väljer en annan återförsöksprincip.
| Återförsöksprincip | beskrivning |
|---|---|
| Standard | För de flesta åtgärder är standardprincipen för återförsök en exponentiell intervallprincip som skickar upp till 4 återförsök med exponentiellt ökande intervall. Dessa intervall skalas med 7,5 sekunder men är begränsade mellan 5 och 45 sekunder. Flera åtgärder använder en annan standardprincip för återförsök, till exempel en princip för fast intervall. Mer information finns i principtypen Standard för återförsök. |
| None | Skicka inte begäran igen. Mer information finns i Ingen – Ingen återförsöksprincip. |
| Exponentiellt intervall | Den här principen väntar på ett slumpmässigt intervall som väljs från ett exponentiellt växande intervall innan nästa begäran skickas. Mer information finns i principtypen exponentiellt intervall. |
| Fast intervall | Den här principen väntar det angivna intervallet innan nästa begäran skickas. Mer information finns i principtypen för fast intervall. |
Ändra principtyp för återförsök i designern
Öppna arbetsflödet för logikappen i designern i Azure-portalen.
Baserat på om du arbetar med ett förbruknings- eller standardarbetsflöde öppnar du utlösaren eller åtgärdens Inställningar.
Förbrukning: Öppna ellipsmenyn (...) i åtgärdsformen och välj Inställningar.
Standard: Välj åtgärden i designern. I informationsfönstret väljer du Inställningar.
Om utlösaren eller åtgärden stöder återförsöksprinciper väljer du den principtyp som du vill använda under Återförsöksprincip.
Ändra principtyp för återförsök i kodvisningsredigeraren
Om det behövs kontrollerar du om utlösaren eller åtgärden stöder återförsöksprinciper genom att slutföra de tidigare stegen i designern.
Öppna logikappens arbetsflöde i kodvisningsredigeraren.
Lägg till
retryPolicyJSON-objektet i utlösaren eller åtgärdens objekt i utlösaren eller åtgärdsdefinitioneninputs. Om ingetretryPolicyobjekt finns använderdefaultutlösaren eller åtgärden annars återförsöksprincipen."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": {}Krävs
Property Värde Typ Beskrivning type<retry-policy-type> String Den principtyp för återförsök som ska användas: default,none,fixedellerexponentialcount<försök igen> Integer För fixedochexponentialprinciptyper, antalet återförsök, vilket är ett värde från 1 till 90. Mer information finns i Fast intervall och exponentiellt intervall.interval<återförsöksintervall> String För fixedochexponentialprinciptyper, återförsöksintervallvärdet i ISO 8601-format.exponentialFör principen kan du också ange valfria maximala och minsta intervall. Mer information finns i Fast intervall och exponentiellt intervall.
Förbrukning: 5 sekunder (PT5S) till 1 dag (P1D).
Standard: För tillståndskänsliga arbetsflöden, 5 sekunder (PT5S) till 1 dag (P1D). För tillståndslösa arbetsflöden, 1 sekund (PT1S) till 1 minut (PT1M).Valfritt
Property Värde Typ Beskrivning maximumInterval<maximalt intervall> String exponentialFör principen är det största intervallet för det slumpmässigt valda intervallet i ISO 8601-format. Standardvärdet är 1 dag (P1D). Mer information finns i Exponentiellt intervall.minimumInterval<minsta intervall> String exponentialFör principen är det minsta intervallet för det slumpmässigt valda intervallet i ISO 8601-format. Standardvärdet är 5 sekunder (PT5S). Mer information finns i Exponentiellt intervall.
Standardvärde för återförsöksprincip
Anslut eller åtgärder som stöder återförsöksprinciper använder Standardprincip om du inte väljer en annan återförsöksprincip. För de flesta åtgärder är standardprincipen för återförsök en exponentiell intervallprincip som skickar upp till 4 återförsök med exponentiellt ökande intervall. Dessa intervall skalas med 7,5 sekunder men är begränsade mellan 5 och 45 sekunder. Flera åtgärder använder en annan standardprincip för återförsök, till exempel en princip för fast intervall.
I arbetsflödesdefinitionen definierar inte utlösaren eller åtgärdsdefinitionen uttryckligen standardprincipen, men i följande exempel visas hur standardprincipen för återförsök fungerar för HTTP-åtgärden:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://myAPIendpoint/api/action",
"retryPolicy" : {
"type": "exponential",
"interval": "PT7S",
"count": 4,
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
},
"runAfter": {}
}
Ingen – Ingen återförsöksprincip
Om du vill ange att åtgärden eller utlösaren inte försöker utföra misslyckade begäranden igen anger du <återförsöksprinciptypen> till none.
Princip för återförsök med fast intervall
Om du vill ange att åtgärden eller utlösaren väntar det angivna intervallet innan nästa begäran skickas anger du <återförsöksprinciptypen> till fixed.
Exempel
Den här återförsöksprincipen försöker få de senaste nyheterna två gånger till efter den första misslyckade begäran med en fördröjning på 30 sekunder mellan varje försök:
"Get_latest_news": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://mynews.example.com/latest",
"retryPolicy": {
"type": "fixed",
"interval": "PT30S",
"count": 2
}
}
}
Återförsöksprincip för exponentiellt intervall
Återförsöksprincipen för exponentiellt intervall anger att utlösaren eller åtgärden väntar ett slumpmässigt intervall innan nästa begäran skickas. Det här slumpmässiga intervallet väljs från ett exponentiellt växande intervall. Du kan också åsidosätta standardintervallen för lägsta och högsta genom att ange dina egna minsta och högsta intervall, baserat på om du har ett arbetsflöde för förbrukning eller standardlogikapp.
| Name | Förbrukningsgräns | Standardgräns | Kommentar |
|---|---|---|---|
| Maximal fördröjning | Standard: 1 dag | Standard: 1 timme | Om du vill ändra standardgränsen i ett arbetsflöde för förbrukningslogikapp använder du parametern för återförsöksprincip. Om du vill ändra standardgränsen i ett standardarbetsflöde för logikappar läser du Redigera värd- och appinställningar för logikappar i Azure Logic Apps med en enda klientorganisation. |
| Minsta fördröjning | Standard: 5 sek | Standard: 5 sek | Om du vill ändra standardgränsen i ett arbetsflöde för förbrukningslogikapp använder du parametern för återförsöksprincip. Om du vill ändra standardgränsen i ett standardarbetsflöde för logikappar läser du Redigera värd- och appinställningar för logikappar i Azure Logic Apps med en enda klientorganisation. |
Slumpmässiga variabelintervall
För återförsöksprincipen för exponentiella intervall visar följande tabell den allmänna algoritm som Azure Logic Apps använder för att generera en enhetlig slumpmässig variabel i det angivna intervallet för varje nytt försök. Det angivna intervallet kan vara upp till och inklusive antalet återförsök.
| Återförsöksnummer | Minsta intervall | Maximalt intervall |
|---|---|---|
| 1 | max(0, <minsta intervall>) | min(interval, <maximum-interval>) |
| 2 | max(interval, <minimum-interval>) | min(2 * intervall, <maxintervall>) |
| 3 | max(2 * intervall, <minsta intervall>) | min(4 * intervall, <maxintervall>) |
| 4 | max(4 * intervall, <minsta intervall>) | min(8 * intervall, <maxintervall>) |
| .... | .... | .... |
Hantera beteendet "kör efter"
När du lägger till åtgärder i arbetsflödesdesignern deklarerar du implicit den ordning som ska användas för att köra dessa åtgärder. När en åtgärd har körts har åtgärden markerats med statusen Succeeded, Failed, Skipped eller TimedOut. Som standard körs en åtgärd som du lägger till i designern först när föregående har slutförts med statusen Lyckades. I en åtgärds underliggande definition runAfter anger egenskapen att den föregående åtgärden som först måste slutföras och de statusar som tillåts för föregående åtgärd innan den efterföljande åtgärden kan köras.
När en åtgärd utlöser ett ohanterat fel eller undantag markeras åtgärden Failed (Misslyckades) och eventuell efterföljande åtgärd markeras som Överhoppad. Om det här beteendet inträffar för en åtgärd som har parallella grenar följer Azure Logic Apps-motorn de andra grenarna för att fastställa deras slutförandestatus. Om en gren till exempel slutar med en överhoppad åtgärd baseras grenens slutförandestatus på den överhoppade åtgärdens föregående status. När arbetsflödeskörningen har slutförts avgör motorn hela körningens status genom att utvärdera alla grenstatusar. Om någon gren slutar misslyckas markeras hela arbetsflödeskörningen som Misslyckad.
För att säkerställa att en åtgärd fortfarande kan köras trots föregående status kan du ändra åtgärdens beteende "kör efter" för att hantera föregående misslyckade statusar. På så sätt körs åtgärden när föregående status är Succeeded, Failed, Skipped, TimedOut eller alla dessa statusar.
Om du till exempel vill köra åtgärden Skicka ett e-postmeddelande i Office 365 Outlook när åtgärden Lägg till en rad i en tabell i en tabell har markerats som Misslyckad, i stället för Lyckades, ändrar du beteendet "kör efter" med hjälp av antingen designern eller kodvisningsredigeraren.
Kommentar
I designern gäller inte inställningen "kör efter" för den åtgärd som omedelbart följer utlösaren eftersom utlösaren måste köras innan den första åtgärden kan köras.
Ändra beteendet "kör efter" i designern
Välj åtgärdsformen i designern. I informationsfönstret väljer du Kör efter.
I fönstret Kör efter visas föregående åtgärd för den aktuella åtgärden.
Expandera den föregående åtgärdsnoden för att visa alla "kör efter"-statusar.
Som standard är statusen "kör efter" inställd på lyckades. Den föregående åtgärden måste därför köras korrekt innan den markerade åtgärden kan köras.
Ändra beteendet "kör efter" till önskad status. Kontrollera att du först väljer ett alternativ innan du avmarkerar standardalternativet. Du måste alltid ha minst ett alternativ valt.
Följande exempelval har misslyckats.
Om du vill ange att den aktuella åtgärden körs oavsett om föregående åtgärd har markerats som Misslyckad, Överhoppad eller TimedOut väljer du de andra statusarna.
Om du vill kräva att fler än en föregående åtgärd körs expanderar du listan Välj åtgärder var och en med sina egna "kör efter"-statusar. Välj de föregående åtgärder som du vill använda och ange deras obligatoriska "kör efter"-statusar.
När du är klar väljer du Klar.
Ändra beteendet "kör efter" i kodvisningsredigeraren
Öppna arbetsflödet för logikappen i kodvisningsredigeraren i Azure-portalen.
I åtgärdens JSON-definition redigerar du
runAfteregenskapen, som har följande syntax:"<action-name>": { "inputs": { "<action-specific-inputs>" }, "runAfter": { "<preceding-action>": [ "Succeeded" ] }, "type": "<action-type>" }I det här exemplet ändrar du egenskapen
runAfterfrånSucceededtillFailed:"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" }Om du vill ange att åtgärden ska köras om föregående åtgärd har markerats som
Failed,SkippedellerTimedOut, lägger du till de andra statusarna:"runAfter": { "Add_a_row_into_a_table": [ "Failed", "Skipped", "TimedOut" ] },
Utvärdera åtgärder med omfång och deras resultat
På samma sätt som när du kör steg efter enskilda åtgärder med inställningen "kör efter" kan du gruppera åtgärder i ett omfång. Du kan använda omfång när du vill gruppera åtgärder logiskt, utvärdera omfattningens aggregerade status och utföra åtgärder baserat på den statusen. När alla åtgärder i ett omfång har körts får själva omfånget sin egen status.
Om du vill kontrollera statusen för ett omfång kan du använda samma villkor som du använder för att kontrollera status för arbetsflödeskörning, till exempel Lyckades, Misslyckades och så vidare.
När alla omfångsåtgärder lyckas markeras omfångets status som Lyckades som standard. Om den sista åtgärden i ett omfång har markerats som Misslyckad eller Avbruten markeras omfångets status som Misslyckad.
Om du vill fånga undantag i omfånget Misslyckades och köra åtgärder som hanterar dessa fel kan du använda inställningen "kör efter" som Omfånget Misslyckades . På så sätt, om några åtgärder i omfånget misslyckas och du använder inställningen "kör efter" för det omfånget, kan du skapa en enda åtgärd för att fånga fel.
Begränsningar för omfång finns i Gränser och konfiguration.
Hämta kontext och resultat för fel
Även om det är användbart att fånga fel från ett omfång kanske du också vill ha mer kontext som hjälper dig att lära dig de exakta misslyckade åtgärderna plus eventuella fel eller statuskoder. Funktionen result() returnerar resultatet från åtgärderna på den översta nivån i en begränsad åtgärd. Den här funktionen accepterar omfångets namn som en enskild parameter och returnerar en matris med resultatet från de översta åtgärderna. Dessa åtgärdsobjekt har samma attribut som de attribut som returneras av actions() funktionen, till exempel åtgärdens starttid, sluttid, status, indata, korrelations-ID och utdata.
Kommentar
Funktionen result() returnerar endast resultatet från åtgärderna på den översta nivån och inte från djupare kapslade åtgärder, till exempel växel- eller villkorsåtgärder.
Om du vill få kontext om de åtgärder som misslyckades i ett omfång kan du använda @result() uttrycket med omfångets namn och inställningen "kör efter". Om du vill filtrera ned den returnerade matrisen till åtgärder som har statusen Misslyckades kan du lägga till åtgärden Filtermatris. Om du vill köra en åtgärd för en returnerad misslyckad åtgärd tar du den returnerade filtrerade matrisen och använder en För varje loop.
I följande JSON-exempel skickas en HTTP POST-begäran med svarstexten för alla åtgärder som misslyckades inom omfångsåtgärden med namnet My_Scope. En detaljerad förklaring följer exemplet.
"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"
]
}
}
Följande steg beskriver vad som händer i det här exemplet:
För att hämta resultatet från alla åtgärder i My_Scope använder åtgärden Filtermatris det här filteruttrycket:
@result('My_Scope')Villkoret för filtermatrisen är alla
@result()objekt som har statusen lika medFailed. Det här villkoret filtrerar matrisen som har alla åtgärdsresultat från My_Scope ned till en matris med endast misslyckade åtgärdsresultat.Utför en
For_eachloopåtgärd på de filtrerade matrisutdata . Det här steget utför en åtgärd för varje misslyckat åtgärdsresultat som tidigare filtrerades.Om en enskild åtgärd i omfånget misslyckas körs åtgärderna i loopen
For_eachbara en gång. Flera misslyckade åtgärder orsakar en åtgärd per fel.Skicka ett HTTP POST på objektets
For_eachsvarstext, vilket är uttrycket@item()['outputs']['body'].Objektformen
@result()är samma som@actions()formen och kan parsas på samma sätt.Inkludera två anpassade huvuden med det misslyckade åtgärdsnamnet (
@item()['name']) och det misslyckade klientspårnings-ID:t (@item()['clientTrackingId']).
Här är ett exempel på ett enskilt @result() objekt som visar egenskaperna name, bodyoch som clientTrackingId parsas i föregående exempel. Utanför en For_each åtgärd @result() returnerar en matris med dessa objekt.
{
"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"
}
Om du vill utföra olika mönster för undantagshantering kan du använda de uttryck som beskrivs tidigare i den här artikeln. Du kan välja att köra en enda undantagshanteringsåtgärd utanför omfånget som accepterar hela den filtrerade matrisen med fel och ta bort åtgärden For_each . Du kan också ta med andra användbara egenskaper från svaret enligt beskrivningen \@result() ovan.
Konfigurera Azure Monitor-loggar
De tidigare mönstren är användbara sätt att hantera fel och undantag som inträffar inom en körning. Men du kan också identifiera och svara på fel som inträffar oberoende av körningen. Om du vill utvärdera körningsstatusar kan du övervaka loggarna och måtten för dina körningar eller publicera dem i valfritt övervakningsverktyg som du föredrar.
Azure Monitor ger till exempel ett effektivt sätt att skicka alla arbetsflödeshändelser, inklusive alla körnings- och åtgärdsstatusar, till ett mål. Du kan konfigurera aviseringar för specifika mått och tröskelvärden i Azure Monitor. Du kan också skicka arbetsflödeshändelser till en Log Analytics-arbetsyta eller ett Azure-lagringskonto. Eller så kan du strömma alla händelser via Azure Event Hubs till Azure Stream Analytics. I Stream Analytics kan du skriva livefrågor baserat på avvikelser, medelvärden eller fel från diagnostikloggarna. Du kan använda Stream Analytics för att skicka information till andra datakällor, till exempel köer, ämnen, SQL, Azure Cosmos DB eller Power BI.
Mer information finns i Konfigurera Azure Monitor-loggar och samla in diagnostikdata för Azure Logic Apps.