Freigeben über

Behandeln von Fehlern und Ausnahmen in Azure Logic Apps

  • Artikel

Gilt für: Azure Logic Apps (Verbrauch + Standard)

Die Art und Weise, wie eine Integrationsarchitektur Ausfallzeiten oder Probleme aufgrund von abhängigen Systemen behandelt, kann eine Herausforderung darstellen. Damit Sie stabile und robuste Integrationen erstellen können, bei denen Probleme und Fehler korrekt behandelt werden, verfügt Azure Logic Apps über eine professionelle Benutzeroberfläche für den Umgang mit Fehlern und Ausnahmen.

Wiederholungsrichtlinien

Für die einfachste Ausnahme- und Fehlerbehandlung können Sie die Wiederholungsrichtlinie verwenden, wenn sie für einen Trigger oder eine Aktion unterstützt wird, z. B. die HTTP-Aktion. Wenn die ursprüngliche Anforderung des Triggers oder der Aktion veraltet ist oder fehlschlägt, was zu einer Antwort 408, 429 oder 5xx führt, gibt die Wiederholungsrichtlinie mittels Richtlinieneinstellungen an, dass der Trigger oder die Aktion die Anforderung erneut senden soll.

Wiederholungsrichtlinienlimits

Weitere Informationen zu Wiederholungsrichtlinien, Einstellungen, Grenzwerten und anderen Optionen, finden Sie unter Grenzwerte von Wiederholungsrichtlinien.

Typen von Wiederholungsrichtlinien

Connectorvorgänge, die Wiederholungsrichtlinien unterstützen, verwenden die Standardrichtlinie, es sei denn, Sie wählen eine andere Wiederholungsrichtlinie aus.

Wiederholungsrichtlinie BESCHREIBUNG
Standard Für die meisten Vorgänge ist die Standardwiederholungsrichtlinie eine Richtlinie mit exponentiellem Intervall, die bis zu vier Wiederholungsversuche mit exponentiell wachsenden Intervallen sendet. Diese Intervalle werden um 7,5 Sekunden skaliert, aber auf einen Wert zwischen 5 und 45 Sekunden begrenzt. Mehrere Vorgänge verwenden eine andere Standardwiederholungsrichtlinie, z. B. eine Richtlinie mit festem Intervall. Weitere Informationen hierzu finden Sie unter Wiederholungsrichtlinientyp „Standard“.
None Die Anforderung wird nicht erneut gesendet. Weitere Informationen hierzu finden Sie unter Keine: Keine Wiederholungsrichtlinie.
Exponentielles Intervall Diese Richtlinie wartet für den Zeitraum eines zufälligen Intervalls, das aus einem exponentiell wachsenden Bereich ausgewählt wird, bevor die nächste Anforderung gesendet wird. Weitere Informationen hierzu finden Sie unter Richtlinientyp „Exponentielles Intervall“.
Festes Intervall Bei dieser Richtlinie wird für den Zeitraum des angegebenen Intervalls gewartet, bevor die nächste Anforderung gesendet wird. Weitere Informationen hierzu finden Sie unter „ „Festes Intervall“.

Ändern des Wiederholungsrichtlinientyps im Designer

  1. Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.

  2. Je nachdem, ob Sie an einem Verbrauchs- oder Standardworkflow arbeiten, öffnen Sie die Einstellungen des Triggers oder der Aktion.

    • Verbrauch (consumption): Öffnen Sie in der Aktion-Form das Menü mit den Auslassungspunkten (...), und wählen Sie Einstellungen aus.

    • Standard (default): Wählen Sie im Designer die Aktion aus. Wählen Sie im Detailbereich Einstellungen aus.

  3. Wenn der Trigger bzw. die Aktion Wiederholungsrichtlinien unterstützt, wählen Sie unter Wiederholungsrichtlinie den gewünschten Richtlinientyp aus.

Ändern des Wiederholungsrichtlinientyps im Codeansichts-Editor

  1. Überprüfen Sie bei Bedarf, ob der Trigger oder die Aktion Wiederholungsrichtlinien unterstützt, indem Sie die vorherigen Schritte im Designer ausführen.

  2. Öffnen Sie Ihren Logik-App-Workflow im Codeansichts-Editor.

  3. Fügen Sie in der Trigger- oder Aktionsdefinition das JSON-Objekt retryPolicy zu dem inputs-Objekt des Triggers oder der Aktion hinzu. Andernfalls, wenn kein retryPolicy-Objekt vorhanden ist, verwendet der Trigger oder die Aktion die default-Wiederholungsrichtlinie.

    "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": {}

    Erforderlich

    Eigenschaft Wert Typ BESCHREIBUNG
    type <retry-policy-type> String Der Wiederholungsrichtlinientyp, den Sie verwenden möchten: default, none, fixed oder exponential.
    count <retry-attempts> Integer Für die Richtlinientypen fixed und exponential die Anzahl der Wiederholungsversuche, wobei es sich um einen Wert von 1–90 handelt. Weitere Informationen finden Sie unter Festes Intervall und Exponentielles Intervall.
    interval <retry-interval> String Für die Richtlinientypen fixed und exponential der Wert des Wiederholungsintervalls im ISO 8601-Format. Für die exponential-Richtlinie können Sie auch optionale Höchst- und Mindestintervalle angeben. Weitere Informationen finden Sie unter Festes Intervall und Exponentielles Intervall.

    Verbrauch: 5 Sekunden (PT5S) bis 1 Tag (P1D).
    Standard: Für zustandsbehaftete Workflows, 5 Sekunden (PT5S) bis 1 Tag (P1D). Für zustandslose Workflows, 1 Sekunde (PT1S) bis 1 Minute (PT1M).

    Optional

    Eigenschaft Wert Typ BESCHREIBUNG
    maximumInterval <maximum-interval> String Für die exponential-Richtlinie das größte Intervall für das zufällig ausgewählte Intervall im ISO 8601-Format. Der Standardwert ist 1 Tag (P1D). Weitere Informationen finden Sie unter Exponentielles Intervall.
    minimumInterval <minimum-interval> String Für die exponential-Richtlinie das kleinste Intervall für das zufällig ausgewählte Intervall im ISO 8601-Format. Der Standardwert ist 5 Sekunden (PT5S). Weitere Informationen finden Sie unter Exponentielles Intervall.

Standard-Wiederholungsrichtlinie

Connectorvorgänge, die Wiederholungsrichtlinien unterstützen, verwenden die Standardrichtlinie, es sei denn, Sie wählen eine andere Wiederholungsrichtlinie aus. Für die meisten Vorgänge ist die Standardwiederholungsrichtlinie eine Richtlinie mit exponentiellem Intervall, die bis zu vier Wiederholungsversuche mit exponentiell wachsenden Intervallen sendet. Diese Intervalle werden um 7,5 Sekunden skaliert, aber auf einen Wert zwischen 5 und 45 Sekunden begrenzt. Mehrere Vorgänge verwenden eine andere Standardwiederholungsrichtlinie, z. B. eine Richtlinie mit festem Intervall.

In Ihrer Workflowdefinition definiert die Trigger- oder Aktionsdefinition nicht explizit die Standardrichtlinie, aber das folgende Beispiel zeigt, wie sich die Standardwiederholungsrichtlinie für die HTTP-Aktion verhält:

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

Keine – Keine Wiederholungsrichtlinie

Um anzugeben, dass die Aktion bzw. der Trigger für fehlgeschlagene Anforderungen keine Wiederholungsversuche durchführen soll, legen Sie <retry-policy-type> auf none fest.

Wiederholungsrichtlinie mit festem Intervall

Um anzugeben, dass die Aktion bzw. der Trigger für den Zeitraum des angegebenen Intervalls wartet, bevor die nächste Anforderung gesendet wird, legen Sie <retry-policy-type> auf fixed fest.

Beispiel

Bei dieser Wiederholungsrichtlinie wird zwei weitere Male versucht, die aktuellen Neuigkeiten abzurufen, nachdem die erste Anforderung fehlgeschlagen ist, und zwischen den Versuchen wird jeweils eine Verzögerung von 30 Sekunden verwendet:

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

Wiederholungsrichtlinie mit exponentiellem Intervall

Die Wiederholungsrichtlinie mit exponentiellem Intervall gibt an, dass der Trigger oder die Aktion ein zufälliges Intervall wartet, bevor die nächste Anforderung gesendet wird. Das zufällige Intervall wird aus einem exponentiell wachsenden Bereich ausgewählt. Optional können Sie die standardmäßigen Mindest- und Höchstintervalle außer Kraft setzen, indem Sie ihre eigenen Mindest- und Höchstintervalle angeben, basierend darauf, ob Sie über einen Verbrauchs- oder Standard-Logik-App-Workflow verfügen.

Name Grenzwert für „Verbrauch“ Grenzwert für „Standard“ Hinweise
Minimale Verzögerung Standardwert: 1 Tag Standardwert: 1 Stunde Verwenden Sie zum Ändern des Standardgrenzwerts in einem Logik-App-Verbrauchsworkflow den Wiederholungsrichtlinienparameter.

Informationen zum Ändern des Standardgrenzwerts in einem Logik-App-Standardworkflow finden Sie unter Bearbeiten von Einstellungen für Hosts und Apps für Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten.
Minimale Verzögerung Standardwert: 5 Sekunden Standardwert: 5 Sekunden Verwenden Sie zum Ändern des Standardgrenzwerts in einem Logik-App-Verbrauchsworkflow den Wiederholungsrichtlinienparameter.

Informationen zum Ändern des Standardgrenzwerts in einem Logik-App-Standardworkflow finden Sie unter Bearbeiten von Einstellungen für Hosts und Apps für Logik-Apps in Azure Logic Apps-Instanzen mit einem einzelnen Mandanten.

Bereiche der Zufallsvariablen

In der folgenden Tabelle wird für die Wiederholungsrichtlinie mit exponentiellem Intervall der allgemeine Algorithmus gezeigt, den Azure Logic Apps verwendet, um eine einheitliche Zufallsvariable im angegebenen Bereich für jede Wiederholung zu generieren. Der angegebene Bereich kann bis zur Anzahl der Wiederholungen gehen oder diese auch einschließen.

Wiederholungsanzahl Minimales Intervall Maximales Intervall
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>)
.... .... ....

Verwalten des Verhaltens „Ausführen nach“

Wenn Sie im Workflow-Designer Aktionen hinzufügen, deklarieren Sie implizit die Reihenfolge, in der diese Aktionen ausgeführt werden sollen. Sobald die Ausführung einer Aktion abgeschlossen ist, wird diese Aktion mit einem der folgenden Status markiert: Erfolgreich (Succeeded), Fehlgeschlagen (Failed), Übersprungen (Skipped) oder Timeout (TimedOut). Standardmäßig wird eine Aktion, die Sie im Designer hinzufügen, erst ausgeführt, wenn die vorherige Aktion mit dem Status Erfolgreich abgeschlossen wurde. In der zugrunde liegenden Definition einer Aktion gibt die runAfter-Eigenschaft die Aktion an, die zuvor abgeschlossen sein muss, und welche Status für diese Aktion zulässig sind, damit die nachfolgende Aktion ausgeführt werden darf.

Wenn eine Aktion einen nicht behandelten Fehler oder eine nicht behandelte Ausnahme auslöst, wird die Aktion als Fehlgeschlagen markiert, und alle nachfolgenden Aktionen mit Übersprungen. Wenn dieses Verhalten bei einer Aktion mit parallelen Branches auftritt, folgt die Azure Logic Apps-Engine den anderen Branches, um deren Abschlussstatus zu ermitteln. Wenn ein Branch beispielsweise mit einer Übersprungen-Aktion endet, hängt der Abschlussstatus dieses Branchs vom Status der Aktion ab, die vor dieser übersprungenen Aktion ausgeführt wurde. Nachdem die Ausführung des Workflows abgeschlossen wurde, ermittelt die Engine den Status der gesamten Ausführung, indem die Status aller Branches ausgewertet werden. Wenn irgendein Branch zu einem Fehler geführt hat, wird die gesamte Ausführung des Workflows als Fehlgeschlagen markiert.

Konzeptionelles Diagramm mit Beispielen, die zeigen, wie die Status von Ausführungen ausgewertet werden.

Um sicherzustellen, dass eine Aktion unabhängig vom Status ihrer Vorgängeraktion ausgeführt werden kann, können Sie das Verhalten „Ausführen nach“ einer Aktion anpassen, sodass die nicht erfolgreichen Status der zuvor ausgeführten Aktionen behandelt werden können. Auf diese Weise wird die Aktion ausgeführt, wenn der Status des Vorgängers Erfolgreich, Fehlgeschlagen, Übersprungen, TimedOut oder alle diese Status ist.

Wenn Sie z. B. die Office 365 Outlook-Aktion E-Mail senden ausführen möchten, nachdem die vorangegangene Excel Online-Aktion Zeile in Tabelle einfügen als Fehlgeschlagen gekennzeichnet wurde anstatt als Erfolgreich, ändern Sie das „Ausführen nach“-Verhalten, indem Sie entweder den Designer oder den Codeansichts-Editor verwenden.

Hinweis

Im Designer gilt die Einstellung „Ausführen nach“ nicht für die Aktion, die unmittelbar dem Trigger folgt, da der Trigger erfolgreich ausgeführt werden muss, bevor die erste Aktion ausgeführt werden kann.

Ändern des „Ausführen nach“-Verhaltens im Designer

  1. Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.

  2. Wählen Sie im Designer die Aktion-Form aus. Wählen Sie im Detailbereich Ausführen nach aus.

    Screenshot des Standardworkflow-Designers und des Bereichs mit den Details der aktuellen Aktion und ausgewähltem „Ausführen nach“.

    Im Bereich Ausführen nach wird die Vorgängeraktion für die aktuell ausgewählte Aktion angezeigt.

    Screenshot des Standard-Designers, der aktuellen Aktion und des „Ausführen nach“-Status für eine Vorgängeraktion.

  3. Erweitern Sie den Knoten der Vorgängeraktion, um alle Status von „Ausführen nach“ anzuzeigen.

    Standardmäßig ist der Status von „Ausführen nach“ auf ist erfolgreich festgelegt. Daher muss die Vorgängeraktion erfolgreich ausgeführt werden, bevor die aktuell ausgewählte Aktion ausgeführt werden kann.

    Screenshot des Standard-Designers, der aktuellen Aktion und des Standards von „Ausführen nach“, festgelegt auf „ist erfolgreich“.

  4. Ändern Sie das Verhalten von „Ausführen nach“ in den gewünschten Status. Stellen Sie sicher, dass Sie zuerst eine Option auswählen, bevor Sie die Standardoption löschen. Es muss immer mindestens eine Option ausgewählt sein.

    Im folgenden Beispiel wird ist fehlgeschlagen ausgewählt.

    Screenshot des Standard-Designers, der aktuellen Aktion und „Ausführen nach“, festgelegt auf „ist fehlgeschlagen“.

  5. Wählen Sie einen der anderen Status aus, wenn Sie angeben möchten, dass die aktuelle Aktion ausgeführt wird, wenn die Vorgängeraktion als Fehlgeschlagen, Übersprungen oder TimedOut markiert ist.

    Screenshot des Standard-Designers, der aktuellen Aktion und mehrerer ausgewählter „Ausführen nach“-Status.

  6. Um anzufordern, dass mehr als eine Vorgängeraktionen ausgeführt werden muss, davon jede mit ihrem eigenen „Ausführen nach“-Status, erweitern Sie die Liste Aktionen auswählen. Wählen Sie die gewünschten Vorgängeraktionen aus, und geben Sie deren erforderliche „Ausführen nach“-Status an.

    Screenshot des Standard-Designers, der aktuellen Aktion und mehrerer verfügbarer Vorgängeraktionen.

  7. Wählen Sie abschließend Fertig aus.

Ändern des „Ausführen nach“-Verhaltens im Codeansichts-Editor

  1. Öffnen Sie im Azure-Portal Ihren Logik-App-Workflow im Codeansichts-Editor.

  2. Bearbeiten Sie in der JSON-Definition der Aktion die Eigenschaft runAfter, die folgende Syntax aufweist:

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

  3. Ändern Sie für dieses Beispiel die runAfter-Eigenschaft von Succeeded in 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. Wenn Sie angeben möchten, dass die Aktion ausgeführt wird, wenn die Vorgängeraktion als Failed, Skipped oder TimedOut markiert ist, fügen Sie die anderen Status hinzu:

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

Auswerten von Aktionen mit Bereichen und ihren Ergebnissen

Ähnlich wie beim Ausführen von Schritten nach einzelnen Aktionen mit der „Ausführen nach“-Eigenschaft können Sie Aktionen innerhalb eines Bereichs (scope) gruppieren. Sie können Bereiche verwenden, wenn Sie Aktionen logisch gruppieren, den Aggregatstatus des Bereichs feststellen und basierend auf diesem Status Aktionen ausführen möchten. Nachdem die Ausführung aller Aktionen in einem Bereich beendet ist, erhält der Bereich selbst seinen eigenen Status.

Zum Überprüfen des Status eines Bereichs können Sie die gleichen Kriterien wie zum Überprüfen des Ausführungsstatus eines Workflows verwenden, z. B. Erfolgreich, Fehlerhaft usw.

Bei erfolgreicher Ausführung aller Aktionen des Bereichs wird der Status des Bereichs als Erfolgreich gekennzeichnet. Wenn die letzte Aktion in einem Bereich als Fehlerhaft oder Abgebrochen markiert wird, wird der Status des Bereichs als Fehlerhaft gekennzeichnet.

Zum Abfangen von Ausnahmen in einem als Fehlerhaft gekennzeichneten Bereich und zum Ausführen von Aktionen, die diese Fehler behandeln, können Sie die „Ausführen nach“-Einstellung dieses Fehlerhaften Bereichs verwenden. Auf diese Weise können Sie, wenn eine beliebige Aktion im Bereich fehlschlägt, und Sie die „Ausführen nach“-Einstellung für diesen Bereich verwenden, eine einzelne Aktion zum Abfangen von Fehlern erstellen.

Grenzwerte für Bereiche finden Sie unter Grenzwerte und Konfiguration.

Abrufen von Kontext und Ergebnissen auf Fehler

Das Abfangen der Fehler aus einem Bereich ist zwar nützlich, doch häufig wäre auch mehr Kontext hilfreich, um genau zu verstehen, welche Aktionen fehlgeschlagen und welche Fehler aufgetreten sind bzw. welche Statuscodes zurückgegeben wurden. Die result()-Funktion gibt die Ergebnisse der Aktionen auf oberster Ebene in einer bereichsbezogenen Aktion zurück. Diese Funktion akzeptiert den Namen des Bereichs als einzelnen Parameter und gibt ein Array mit den Ergebnissen dieser Aktionen auf oberster Ebene zurück. Diese Aktionsobjekte besitzen dieselben Attribute, die auch von der actions()-Funktion zurückgegeben werden, z. B. Start- und Endzeit der Aktion, Status, Eingaben, Korrelations-IDs und Ausgaben.

Hinweis

Die result()-Funktion gibt nur die Ergebnisse der Aktionen der obersten Ebene zurück, keine aus tiefer geschachtelten Aktionen wie Schalter- oder Bedingungsaktionen (switch/condition).

Um Kontextinformationen zu den in einem Bereich fehlgeschlagenen Aktionen zu erhalten, können Sie den @result()-Ausdruck mit dem Namen des Bereichs und der „Ausführen nach“-Einstellung verwenden. Um das zurückgegebene Array nach Aktionen zu filtern, die den Status Fehlgeschlagen aufweisen, können Sie die Aktion Array filtern hinzufügen. Zum Ausführen einer Aktion für eine zurückgegebene Aktion, bei der ein Fehler aufgetreten ist, wenden Sie eine For each-Schleife auf das zurückgegebene gefilterte Array an.

Das folgende JSON-Beispiel sendet eine HTTP POST-Anforderung mit dem Antworttext für alle fehlgeschlagenen Aktionen in der Bereichsaktion My_Scope. Auf das Beispiel folgt eine detaillierte Erklärung.

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

Die folgenden Schritte beschreiben, was in diesem Beispiel geschieht:

  1. Um das Ergebnis aller Aktionen in My_Scope abzurufen, wird für die Aktion Array filtern dieser Filterausdruck verwendet: @result('My_Scope').

  2. Die Bedingung für Array filtern ist ein beliebiges @result()-Element, dessen Status Failed lautet. Mit dieser Bedingung wird das Array mit allen Aktionsergebnissen aus My_Scope bis hinab zu einem Array gefiltert, dass nur die fehlerhaften Aktionen als Ergebnisse enthält.

  3. Führen Sie eine For_each-Schleifenaktion für die Ausgaben gefilterter Arrays aus. In diesem Schritt wird eine Aktion für jedes Ergebnis einer fehlgeschlagenen Aktion durchgeführt, das zuvor gefiltert wurde.

    Wenn eine einzelne Aktion im Bereich fehlgeschlagen ist, werden die Aktionen in der For_each-Schleife nur einmal ausgeführt. Mehrere Aktionen mit Fehler lösen eine Aktion pro Fehler aus.

  4. Senden Sie HTTP POST für den For_each-Elementantworttext. Dies ist der Ausdruck @item()['outputs']['body'].

    Die @result()-Elementform ist mit der @actions()-Form identisch und kann auch genauso analysiert werden.

  5. Binden Sie zwei benutzerdefinierte Header mit dem Namen der fehlerhaften Aktion (@item()['name']) und der Clientnachverfolgungs-ID der fehlerhaften Ausführung (@item()['clientTrackingId']) ein.

Zu Referenzzwecken ist hier ein Beispiel für ein einzelnes @result()-Element angegeben, das die Eigenschaften name, body und clientTrackingId enthält, die im vorherigen Beispiel analysiert werden. Außerhalb einer For_each-Aktion, gibt @result() ein Array dieser Objekte zurück.

{
   "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"
}

Sie können die oben in diesem Artikel beschriebenen Ausdrücke verwenden, um unterschiedliche Muster für die Ausnahmebehandlung zu nutzen. Außerdem können Sie die Entscheidung treffen, eine einzelne Aktion für die Ausnahmebehandlung außerhalb des Bereichs durchzuführen, bei der das gesamte gefilterte Array mit Fehlern akzeptiert wird, und die For_each-Aktion zu entfernen. Darüber hinaus können Sie noch andere nützliche Eigenschaften aus der \@result()-Antwort einfügen, wie zuvor beschrieben.

Einrichten von Azure Monitor-Protokollen

Die vorherigen Muster sind nützliche Methoden zum Behandeln von Fehlern und Ausnahmen, die innerhalb einer Ausführung auftreten. Sie können jedoch auch Fehler identifizieren und darauf reagieren, die unabhängig von der Ausführung auftreten. Sie können die Protokolle und Metriken für Ihre Ausführungen überwachen oder mit einem von Ihnen bevorzugten Überwachungstool veröffentlichen, um jeweils den Ausführungsstatus auszuwerten.

Beispielsweise bietet Azure Monitor eine optimierte Möglichkeit zum Senden aller Workflowereignisse, einschließlich aller Ausführungs- und Aktionsstatus, an ein Ziel. Sie können Warnungen für bestimmte Metriken und Schwellenwerte in Azure Monitor einrichten. Sie können Workflowereignisse auch an einen Log Analytics-Arbeitsbereich oder ein Azure-Speicherkonto senden. Sie können auch alle Ereignisse über Azure Event Hubs in Azure Stream Analytics streamen. In Stream Analytics können Sie Liveabfragen auf der Grundlage von Anomalien, Mittelwerten oder Fehlern aus den Diagnoseprotokollen schreiben. Sie können Stream Analytics zum Senden von Informationen an andere Datenquellen verwenden, etwa an Warteschlangen, Themen, SQL, Azure Cosmos DB oder Power BI.

Weitere Informationen finden Sie unter Einrichten von Azure Monitor-Protokollen und Sammeln von Diagnosedaten für Azure Logic Apps.

Nächste Schritte