Freigeben über


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

Screenshot: Die vier Verzweigungen einer Aktivität

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.

Screenshot: Definition und Ergebnis eines Try Catch-Blocks

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.

Screenshot: Definition und Ergebnis eines Do-If-Else-Blocks

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.

Screenshot: Definition und Ergebnis eines Do-If-Skip-Else-Blocks

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:

  • Try-Catch-Ansatz

    • 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.
  • Do-If-Else-Ansatz

    • 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.
  • Do-If-Skip-Else-Ansatz

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

Screenshot, der die Fehlerbehandlung für unternehmenskritische Schritte darstellt.

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.

Screenshot, der einen Best-Effort-Protokollierungsversuch zeigt.

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.

Screenshot, der eine Pipeline zeigt, die nur fortgesetzt wird, wenn beide Webaktivitäten erfolgreich sind.

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.

Screenshot, der eine Pipeline zeigt, die fortgesetzt wird, wenn die erste Webaktivität erfolgreich und die zweite Webaktivität abgeschlossen ist.

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

Screenshot, der das Ausführen eines gemeinsamen Fehlerbehandlungsschritts zeigt, wenn bei einer der vorherigen Aktivitäten ein Fehler aufgetreten ist.

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.

Screenshot, der die Pipeline zeigt, die mit dem nächsten Schritt fortfährt, wenn eine der Aktivitäten erfolgreich ist.

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

Screenshot, der die Pipeline zeigt, die mit dem nächsten Schritt fortfährt, wenn eine der Aktivitäten erfolgreich ist, oder andernfalls einen Fehlerbehandlungscode ausführt.

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.

Screenshot einer Pipeline mit Try-Catch-Block.

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

Screenshot einer Pipeline mit generischer Fehlerbehandlung in einer Pipeline ohne Verzweigungen.

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.

Screenshot einer Pipeline mit generischer Fehlerbehandlung in einer Pipeline ohne Verzweigungen und ohne mehrere Aktivitäten.

Data Factory-Metriken und -Warnungen

Visuelles Überwachen