Fehler und bedingte Ausführung
GILT FÜR: Azure Data Factory Azure Synapse Analytics
Tipp
Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!
Bedingte Pfade
Die Orchestrierung von Azure Data Factory und Synapse-Pipeline ermöglicht die Verwendung von bedingter Logik und ermöglicht Benutzer*innen, basierend auf den Ergebnissen einer vorherigen Aktivität einem anderen Pfad zu folgen. Durch die Verwendung verschiedener Pfade können Benutzer robuste Pipelines erstellen und eine Fehlerbehandlung in die ETL/ELT-Logik integrieren. Insgesamt sind vier bedingte Pfade möglich:
Name | Erklärung |
---|---|
Bei Erfolg | (Standardpfad) Diesen Pfad ausführen, wenn die aktuelle Aktivität erfolgreich war |
Bei Fehler | Diesen Pfad ausführen, wenn bei der aktuellen Aktivität ein Fehler aufgetreten ist |
Bei Abschluss | Diesen Pfad nach Abschluss der aktuellen Aktivität ausführen, unabhängig davon, ob sie erfolgreich war oder nicht |
Bei Überspringen | Diesen Pfad ausführen, wenn die Aktivität selbst nicht ausgeführt wurde |
Sie können mehrere Verzweigungen nach einer Aktivität hinzufügen, mit einer Ausnahme: Der Pfad Bei Abschluss kann nicht gleichzeitig mit den Pfaden Bei Erfolg oder Bei Fehler vorhanden sein. Bei jeder Pipelineausführung wird basierend auf dem Ausführungsergebnis der Aktivität höchstens ein Pfad aktiviert.
Fehlerbehandlung
Allgemeiner Fehlerbehandlungsmechanismus
Try-Catch-Block
Bei diesem Ansatz definiert der Kunde die Geschäftslogik und gibt nur den Pfad UponFailure (Bei Fehler) an, um Fehler aus der vorherigen Aktivität abzufangen. In diesem Fall ist die Pipeline erfolgreich, wenn der Pfad UponFailure (Bei Fehler) erfolgreich ist.
Do-If-Else-Block
Bei diesem Ansatz definiert der Kunde die Geschäftslogik und gibt sowohl den Pfad UponFailure (Bei Fehler) als auch den Pfad UponSuccess (Bei Erfolg) an. In diesem Fall ist die Pipeline nicht erfolgreich, auch wenn der Pfad UponFailure (Bei Fehler) erfolgreich ist.
Do-If-Skip-Else-Block
Bei diesem Ansatz definiert der Kunde die Geschäftslogik und gibt den Pfad UponFailure (Bei Fehler) sowie den Pfad UponSuccess (Bei Erfolg) mit einer angefügten Aktivität vom Typ DummyUponSkip (Dummyaktivität bei Überspringen) an. In diesem Fall ist die Pipeline erfolgreich, wenn der Pfad UponFailure (Bei Fehler) erfolgreich ist.
Zusammenfassungstabelle
Vorgehensweise | Definiert | Anzeige für die gesamte Pipeline bei erfolgreicher Aktivität | Anzeige für die gesamte Pipeline bei nicht erfolgreicher Aktivität |
---|---|---|---|
Try-Catch | Nur Pfad UponFailure (Bei Fehler) | Erfolgreich | Erfolgreich |
Do-If-Else | Pfade UponFailure (Bei Fehler) und UponSuccess (Bei Erfolg) | Erfolg | Fehler |
Do-If-Skip-Else | Pfad UponFailure (Bei Fehler) und Pfad UponSuccess (Bei Erfolg) mit DummyUponSkip (Dummyaktivität bei Überspringen) am Ende | Erfolgreich | Erfolgreich |
Ermitteln von Pipelinefehlern
Unterschiedliche Fehlerbehandlungsmechanismen führen jeweils zu einem anderen Status für die Pipeline: einige Pipelines sind erfolgreich, andere nicht. Der Erfolgsstatus von Pipelines wird wie folgt bestimmt:
- Zunächst wird das Ergebnis für alle Aktivitäten auf Blattebene ausgewertet. Wenn eine Blattaktivität übersprungen wurde, wird stattdessen die übergeordnete Aktivität ausgewertet.
- Die Pipeline ist nur erfolgreich, wenn alle Knoten als erfolgreich ausgewertet wurden.
Angenommen, die Aktivität Bei Fehler und die Aktivität DummyUponFailure (Dummyaktivität bei Fehler) sind erfolgreich:
-
- Wenn die vorherige Aktivität erfolgreich ist, wird der Knoten UponFailure (Bei Fehler) übersprungen, und der übergeordnete Knoten ist erfolgreich. Die gesamte Pipeline ist erfolgreich.
- Wenn die vorherige Aktivität nicht erfolgreich ist, wird der Knoten UponFailure (Bei Fehler) angewendet. Die gesamte Pipeline ist erfolgreich.
-
- Wenn die vorherige Aktivität erfolgreich ist, ist der Knoten UponSuccess (Bei Erfolg) erfolgreich, der Knoten UponFailure (Bei Fehler) wird übersprungen, und der zugehörige übergeordnete Knoten ist erfolgreich. Die gesamte Pipeline ist erfolgreich.
- Wenn die vorherige Aktivität nicht erfolgreich ist, wird der Knoten UponSuccess (Bei Erfolg) übersprungen, und der übergeordnete Knoten ist nicht erfolgreich. Die gesamte Pipeline ist nicht erfolgreich.
-
- Wenn die vorherige Aktivität erfolgreich ist, wird der Knoten DummyUponSkip (Dummyaktivität bei Überspringen) übersprungen, und der übergeordnete Knoten UponSuccess (Bei Erfolg) ist erfolgreich. Die andere Aktivität (UponFailure (Bei Fehler)) wird übersprungen, und der übergeordnete Knoten ist erfolgreich. Die gesamte Pipeline ist erfolgreich.
- Wenn die vorherige Aktivität nicht erfolgreich ist, sind der Knoten UponFailure (Bei Fehler) und DummyUponSkip (Dummyaktivität bei Überspringen) erfolgreich. Die gesamte Pipeline ist erfolgreich.
Bedingte Ausführung
Beim Entwickeln komplizierterer und resilienterer Pipelines, ist es manchmal erforderlich, bedingte Ausführungen in unsere Logik einzuführen: Eine bestimmte Aktivität soll nur ausgeführt werden, sofern bestimmte Bedingungen erfüllt sind. Dafür gibt es eine Menge Anwendungsfälle, z. B.:
- Ausführen einer Nachverfolgungsaktivität, z. B. Senden einer E-Mail-Benachrichtigung, wenn vorherige Kopieraufträge erfolgreich waren
- Ausführen eines Fehlerbehandlungsauftrags, wenn bei einer vorherigen Aktivität ein Fehler aufgetreten ist
- Fortfahren mit dem nächsten Schritt, wenn entweder die Aktivität selbst oder die entsprechende Fehlerbehandlungsaktivität erfolgreich ist
- usw.
Hier werden einige gängige Logiken und deren Implementierung in ADF erläutert.
Einfache Aktivität
Im Folgenden finden Sie einige gängige Muster, die einer einzelnen Aktivität folgen. Wir können diese Muster als Bausteine verwenden, um kompliziertere Workflows zu erstellen.
Fehlerbehandlung
Ein Muster ist die am häufigsten verwendete Bedingungslogik in ADF. Eine Fehlerbehandlungsaktivität ist für den „Bei Fehler“-Pfad definiert und wird aufgerufen, wenn die Hauptaktivität fehlschlägt. Es sollte als bewährte Methode für alle unternehmenskritischen Schritte integriert werden, für die Fallbackalternativen oder Protokollierungen erforderlich sind.
Best-Effort-Schritte
Bestimmte Schritte, z. B. die Protokollierung von Informationen, sind weniger wichtig, und ihr Scheitern sollte nicht die gesamte Pipeline blockieren. In solchen Fällen sollten wir die Best-Effort-Strategien anwenden, d. h. wir fügen Folgeschritte zum Pfad „Nach Abschluss“ hinzu, um die Blockade des Workflows aufzuheben.
And
Die wichtigsten und häufigsten Szenarien sind bedingte „und“-Szenarien: Die Pipeline soll fortgesetzt werden, wenn und nur wenn die vorherigen Aktivitäten erfolgreich sind. Beispielsweise müssen zunächst mehrere Kopieraktivitäten erfolgreich sein, bevor zur nächsten Phase der Datenverarbeitung übergegangen wird. In ADF kann ein solches Verhalten problemlos erreicht werden: Deklarieren Sie mehrere Abhängigkeiten für den nächsten Schritt. Grafisch bedeutet dies, dass mehrere Linien auf die nächste Aktivität zeigen. Sie können entweder den „Bei Erfolg“-Pfad auswählen, um sicherzustellen, dass die Abhängigkeit erfolgreich war, oder den „Bei Abschluss“-Pfad, um für eine Best-Effort-Ausführung zu sorgen.
Hier wird die Nachverfolgungswarteaktivität nur ausgeführt, wenn beide Webaktivitäten erfolgreich waren.
Und hier wird die Nachverfolgungswarteaktivität ausgeführt, wenn ActivitySucceeded bestanden und ActivityFailed abgeschlossen ist. Beachten Sie, dass im „Bei Erfolg“-Pfad ActivitySucceeded erfolgreich sein muss, während ActivityFailed im Pfad „Nach Abschluss“-Pfad mit „Best Effort“ ausgeführt wird, d. h. möglicherweise fehlschlagen kann.
oder
Die zweithäufigsten Szenarien sind bedingte „oder“-Szenarien: Eine Aktivität soll ausgeführt werden, wenn eine der Abhängigkeiten erfolgreich ist oder fehlschlägt. Hier müssen wir „Nach Abschluss“-Pfade, eine If Condition-Aktivität und Expression Language verwenden.
Bevor wir uns mit Code beschäftigen, müssen wir uns noch eine weitere Sache klarmachen. Nachdem eine Aktivität ausgeführt und abgeschlossen wurde, können Sie mit @activity('ActivityName').Status auf ihren Status verweisen. Er lautet entweder „Erfolgreich“ oder „Fehlgeschlagen“. Wir verwenden diese Eigenschaft, um eine bedingte „oder“-Logik zu erstellen.
Protokollierungsschritt für die gemeinsame Fehlerbehandlung
In einigen Fällen können Sie einen freigegebenen Fehlerbehandlungs- oder Protokollierungsschritt aufrufen, wenn bei einer der vorherigen Aktivitäten ein Fehler aufgetreten ist. Sie können Ihre Pipeline folgendermaßen erstellen:
- Führen Sie mehrere Aktivitäten parallel aus.
- Fügen Sie eine If-Bedingung hinzu, um die Schritte zur Fehlerbehandlung in die True-Verzweigung aufzunehmen.
- Verbinden Sie Aktivitäten mithilfe des „Nach Abschluss“-Pfads mit der Bedingungsaktivität.
- logischer Ausdruck für Lesevorgänge der Bedingungsaktivität
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Hinweis: Sie müssen sie verketten, oder wenn Sie mehr als zwei Abhängigkeitsaktivitäten haben, z. B.
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Grünes Licht, wenn eine Aktivität erfolgreich war
Wenn alle Ihre Aktivitäten „Best Effort“sind, können Sie mit dem nächsten Schritt fortfahren, sofern eine der vorherigen Aktivitäten erfolgreich war. Sie können Ihre Pipeline folgendermaßen erstellen:
- Führen Sie mehrere Aktivitäten parallel aus.
- Fügen Sie eine If-Bedingung hinzu, um die nächsten Schritte in die True-Verzweigung aufzunehmen.
- Verbinden Sie Aktivitäten mithilfe des „Nach Abschluss“-Pfads mit der Bedingungsaktivität.
- logischer Ausdruck für Lesevorgänge der Bedingungsaktivität
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Hinweis: Das Diagramm sieht genau wie im vorherigen Szenario aus. Der einzige Unterschied ist die verwendete Expression Language.
Komplexe Szenarien
Alle Aktivitäten müssen erfolgreich sein, um fortzufahren
Dieses Muster besteht aus einer Kombination aus bedingter und Fehlerbehandlung. Die Pipeline fährt mit den nächsten Schritten fort, wenn alle weiteren Aktivitäten erfolgreich sind. Ansonsten führt sie einen Protokollierungsschritt für die gemeinsame Fehlerbehandlung aus. Sie können diese Pipeline folgendermaßen erstellen:
- Führen Sie mehrere Aktivitäten parallel aus.
- Fügen Sie eine If-Bedingung hinzu. Fügen Sie die nächsten Schritte in die True-Verzweigung und einen Fehlerbehandlungscode in die False-Verzweigung hinzu.
- Verbinden Sie Aktivitäten mithilfe des „Nach Abschluss“-Pfads mit der Bedingungsaktivität.
- logischer Ausdruck für Lesevorgänge der Bedingungsaktivität
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Allgemeine Muster
Try-Catch-Proceed
Das Muster entspricht einem Try-Catch-Block beim Coding. Eine Aktivität in einer Pipeline kann fehlschlagen. Wenn ein Fehler auftritt, muss der Kunde einen Fehlerbehandlungsauftrag ausführen, um damit umzugehen. Das Fehlschlagen einer einzelnen Aktivität sollte jedoch die nächsten Aktivitäten in der Pipeline nicht blockieren. Beispielsweise versuche ich, einen Kopierauftrag auszuführen und Dateien in den Speicher zu verschieben. Dieser kann jedoch nach der Hälfte fehlschlagen. Und in diesem Fall möchte ich die teilweise kopierten, unzuverlässigen Dateien aus dem Speicherkonto löschen (mein Fehlerbehandlungsschritt). Aber es ist für mich in Ordnung, danach mit anderen Aktivitäten fortzufahren.
So richten Sie das Muster ein
- Hinzufügen der ersten Aktivität
- Hinzufügen von Fehlerbehandlung zum UponFailure-Pfad
- Hinzufügen einer zweiten Aktivität, aber kein Herstellen einer Verbindung mit der ersten Aktivität
- Verbinden der UponFailure- und UponSkip-Pfade von der Fehlerbehandlungsaktivität mit der zweiten Aktivität
Hinweis
Jeder Pfad (UponSuccess, UponFailure und UponSkip) kann auf jede Aktivität verweisen. Mehrere Pfade können auf dieselbe Aktivität verweisen. Beispielsweise kann UponSuccess und UponSkip beide auf eine Aktivität zeigen, während UponFailure auf eine andere zeigt.
Ein Fehlerbehandlungsauftrag wird nur ausgeführt, wenn die erste Aktivität fehlschlägt. Die nächste Aktivität wird unabhängig davon ausgeführt, ob die erste Aktivität erfolgreich ist oder nicht.
Generische Fehlerbehandlung
In der Regel werden in der Pipeline mehrere Aktivitäten sequenziell ausgeführt. Wenn eine davon fehlschlägt, muss ich einen Fehlerbehandlungsauftrag ausführen, um den Zustand zu löschen und/oder den Fehler zu protokollieren. Beispielsweise habe ich sequenzielle Kopieraktivitäten in der Pipeline. Wenn eine davon fehlschlägt, muss ich einen Skriptauftrag ausführen, um den Pipelinefehler zu protokollieren.
So richten Sie das Muster ein
- Erstellen einer sequenziellen Datenverarbeitungspipeline
- Hinzufügen eines generischen Fehlerbehandlungsschritts am Ende der Pipeline
- Verbinden der beiden Pfade „UponFailure“ und „UponSkip“ aus der letzten Aktivität mit der Fehlerbehandlungsaktivität
Der letzte Schritt, die generische Fehlerbehandlung, wird nur ausgeführt, wenn eine der vorherigen Aktivitäten fehlschlägt. Er wird nicht ausgeführt, wenn alle erfolgreich sind.
Sie können mehrere Aktivitäten für die Fehlerbehandlung hinzufügen.