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 om den här funktionen finns på 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

Anslutningsåtgärder som stöder återförsöksprinciper använder standardprincipen om du inte väljer en annan återförsöksprincip.

Ändra principtyp för återförsök i designern

1. Öppna logikappresursen i Azure Portal.

2. I resurslisten följer du de här stegen för att öppna arbetsflödesdesignern baserat på logikappen:

   • Förbrukning: Under Utvecklingsverktyg väljer du designern för att öppna arbetsflödet.

   • Standard

     1. Under Arbetsflöden väljer du Arbetsflöden.

     2. På sidan Arbetsflöden väljer du ditt arbetsflöde.

     3. Under Verktyg väljer du designern för att öppna arbetsflödet.

3. På utlösaren eller åtgärden där du vill ändra principtypen för återförsök följer du de här stegen för att öppna inställningarna:

   1. Välj åtgärden i designern.

   2. I åtgärdsinformationsfönstret väljer du Inställningar.

   3. Under Nätverk går du till Återförsöksprincip och väljer den principtyp som du vill använda.

Ändra principtyp för återförsök i kodvisningsredigeraren

1. Bekräfta om utlösaren eller åtgärden stöder återförsöksprinciper genom att slutföra de tidigare stegen i designern.

2. Öppna logikappens arbetsflöde i kodvisningsredigeraren.

3. Lägg till retryPolicy JSON-objektet i utlösarens eller åtgärdens inputs-objekt i deras definition. Om det inte finns något retryPolicy objekt använder default utlösaren eller åtgärden å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

   Fastighet	Värde	Typ	beskrivning
   type	< omförsökspolicytyp>	Sträng	Den principtyp för återförsök som ska användas: default, none, fixedeller exponential
   count	< försök igen>	Heltal	För fixed och exponential principtyper, 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>	Sträng	För fixed och exponential principtyper, återförsöksintervallvärdet i ISO 8601-format. exponential Fö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

   Fastighet	Värde	Typ	beskrivning
   maximumInterval	< maximalt intervall>	Sträng	exponential Fö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>	Sträng	exponential Fö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

Anslutningsåtgärder som stöder återförsöksprinciper använder standardprincipen 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

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

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.

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.

Hantera beteendet "kör efter"

När du lägger till åtgärder i arbetsflödesdesignern deklarerar du implicit sekvensen 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. Med andra ord måste föregående åtgärd först avslutas med någon av de tillåtna statusarna innan efterföljande åtgärd kan köras.

Som standard körs en åtgärd som du lägger till i designern endast om föregående åtgärd slutförs med statusen Lyckades . Detta kör efter funktionen anger den exakta körningsordningen för åtgärder i ett arbetsflöde.

I designern kan du ändra standardbeteendet "kör efter" för en åtgärd genom att redigera åtgärdens kör efter-inställning. Den här inställningen är endast tillgänglig för efterföljande åtgärder som följer den första åtgärden i ett arbetsflöde. Den första åtgärden i ett arbetsflöde körs alltid när utlösaren har körts. Därför är inställningen Kör efter inte tillgänglig och gäller inte för den första åtgärden.

I en åtgärds underliggande JSON-definition är inställningen Kör efter samma som egenskapen runAfter . Den här egenskapen anger en eller flera föregående åtgärder som först måste slutföras med de specifika tillåtna statusarna innan efterföljande åtgärd kan köras. Egenskapen runAfter är ett JSON-objekt som ger flexibilitet genom att du kan ange alla föregående åtgärder som måste slutföras innan efterföljande åtgärd körs. Det här objektet definierar också en matris med godkända statusar.

Om du till exempel vill att en åtgärd ska köras efter att åtgärd A har slutförts och även när åtgärd B har slutförts eller misslyckas när du arbetar med en åtgärds JSON-definition, konfigurerar du följande runAfter egenskap:

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

"Kör efter"-beteende för felhantering

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.

Ändra beteendet "kör efter" i designern

1. Öppna logikappresursen i Azure Portal.

2. I resurslisten följer du de här stegen för att öppna arbetsflödesdesignern baserat på logikappen:

   • Förbrukning: Under Utvecklingsverktyg väljer du designern för att öppna arbetsflödet.

   • Standard

     1. Välj Arbetsflöden under Arbetsflöden i sidofältet för resursen.

     2. På sidan Arbetsflöden väljer du ditt arbetsflöde.

     3. Under Verktyg väljer du designern för att öppna arbetsflödet.

3. På utlösaren eller åtgärden där du vill ändra beteendet "kör efter" följer du dessa steg för att öppna åtgärdens inställningar:

   1. Välj åtgärden i designern.

   2. I åtgärdsinformationsfönstret väljer du Inställningar.

      Avsnittet Kör efter innehåller listan Välj åtgärder , som visar tillgängliga föregående åtgärder för den aktuella åtgärden, till exempel:

      

   3. Under listan Välj åtgärder expanderar du den aktuella föregående åtgärden, som är HTTP i det här exemplet:

      

      Som standard är statusen "kör efter" inställd på Lyckades. Det här värdet innebär att föregående åtgärd måste slutföras innan den aktuella åtgärden kan köras.

      

4. Om du vill ändra beteendet "kör efter" till de statusar som du vill använda väljer du dessa statusar.

   Följande exempel väljer Har misslyckats.

   

5. Om du vill ange att den aktuella åtgärden endast körs när föregående åtgärd slutförs med statusen Har misslyckats, Hoppas över eller Har tidsgränsstatus väljer du dessa statusar och avmarkerar sedan standardstatusen, till exempel:

   

   Kommentar

   Innan du rensar standardstatusen måste du först välja en annan status. Du måste alltid ha minst en status vald.

6. Om du vill kräva att flera föregående åtgärder körs och slutförs, där varje åtgärd har sina egna "kör efter"-status, följer du dessa steg:

   1. Öppna listan Välj åtgärder och välj de föregående åtgärder som du vill använda.

   2. Välj statusen "kör efter" för varje åtgärd.

   

7. När du är klar stänger du åtgärdsinformationsfönstret.

Ändra beteendet "kör efter" i kodvisningsredigeraren

1. I resurspanelen följer du de här stegen för att öppna kodvisningsredigeraren baserat på logikappen:

   • Förbrukning: Under Utvecklingsverktyg väljer du kodvy för att öppna arbetsflödet i JSON-redigeraren.

   • Standard

     1. Under Arbetsflöden väljer du Arbetsflöden.

     2. På sidan Arbetsflöden väljer du ditt arbetsflöde.

     3. Under Verktyg väljer du kodvy för att öppna arbetsflödet i JSON-redigeraren.

2. I åtgärdens JSON-definition redigerar du runAfter egenskapen, som har följande syntax:

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

3. I det här exemplet ändrar du egenskapen runAfter från Succeeded till 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. Om du vill ange att åtgärden ska köras om föregående åtgärd har markerats som Failed, Skipped eller TimedOut, 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.

Konfigurera ett omfång med "kör efter" för undantagshantering

1. Öppna logikappresursen och arbetsflödet i designern i Azure Portal.

   Arbetsflödet måste redan ha en utlösare som startar arbetsflödet.

2. I designern följer du de här allmänna stegen för att lägga till en kontrollåtgärd med namnet Omfång i arbetsflödet.

3. I omfångsåtgärden följer du dessa allmänna steg för att lägga till åtgärder som ska köras, till exempel:

   

   I följande lista visas några exempelåtgärder som du kan inkludera i en omfångsåtgärd :

   • Hämta data från ett API.
   • Bearbeta data.
   • Spara data i en databas.

4. Definiera nu reglerna "kör efter" för att köra åtgärderna i omfånget.

   1. I designern väljer du omfångsrubriken. När informationsfönstret för omfånget öppnas väljer du Inställningar.

   2. Om du har fler än en föregående åtgärd i arbetsflödet väljer du åtgärden som du vill köra omfångsåtgärderna efter i listan Välj åtgärder .

   3. För den valda åtgärden väljer du alla åtgärdsstatusar som kan köra de begränsade åtgärderna.

      Med andra ord leder någon av de valda statusar som är resultatet av den valda åtgärden till att åtgärderna i omfånget körs.

      I följande exempel körs de begränsade åtgärderna när HTTP-åtgärden har slutförts med någon av de valda statusarna:

      

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.

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:

1. 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')

2. Villkoret för filtermatrisen är alla @result() objekt som har statusen lika med Failed. Det här villkoret filtrerar matrisen som har alla åtgärdsresultat från My_Scope ned till en matris med endast misslyckade åtgärdsresultat.

3. Utför en For_each loopå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_each bara en gång. Flera misslyckade åtgärder orsakar en åtgärd per fel.

4. Skicka ett HTTP POST på objektets For_each svarstext, vilket är uttrycket @item()['outputs']['body'] .

   Objektformen @result() är samma som @actions() formen och kan parsas på samma sätt.

5. 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.

Relaterat innehåll

• Exempel och scenarier i Azure Logic Apps