Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Umgang mit Fehlern in Step Functions Functions-Workflows In allen Zuständen, mit Ausnahme `Pass` `Wait` von Staaten, kann es zu Laufzeitfehlern kommen. Fehler können aus verschiedenen Gründen auftreten, unter anderem aus den folgenden: + **Probleme mit der Definition von Zustandsmaschinen**, z. B. ein Auswahlstatus ohne passende Regel + **Fehler bei Aufgaben**, z. B. eine Ausnahme in einer AWS Lambda Funktion + **Vorübergehende Probleme** — wie Netzwerkpartitionsereignisse Wenn ein Status einen Fehler meldet, schlägt Step Functions standardmäßig die **gesamte** State-Machine-Ausführung fehl. Step Functions bietet auch erweiterte Funktionen zur Fehlerbehandlung. Sie können Ihre Zustandsmaschine so einrichten, dass sie Fehler abfängt, fehlgeschlagene Zustände wiederholt und Fehlerbehandlungsprotokolle ordnungsgemäß implementiert. Step Functions Functions-Catcher sind für den Status **Task**, **Parallel** und **Map** verfügbar, jedoch nicht für Fehler bei der Ausführung von Zustandsmaschinen auf oberster Ebene. Um Ausführungen zu verarbeiten, von denen Sie erwarten, dass sie fehlschlagen könnten, kann Ihr Aufrufer den Fehler behandeln, oder Sie können diese Ausführungen in untergeordneten Workflows verschachteln, um Fehler in Ihrem übergeordneten Workflow abzufangen. Alternativ können Sie sich dafür entscheiden, `TIMED_OUT` Ereignisse aus Standard-Workflows mit einem EventBridge Bus abzuhören und eine Aktion zur Behandlung der fehlgeschlagenen Ausführung aufzurufen. **Praktische Beispiele für den Umgang mit Fehlern** Ein Beispiel für einen Workflow, der Fehlerbehandlung beinhaltet, finden Sie im [Behandlung von Fehlerbedingungen in einer Step Functions Functions-Zustandsmaschine](tutorial-handling-error-conditions.md) Tutorial in diesem Handbuch und unter [Fehlerbehandlung](https://catalog.workshops.aws/stepfunctions/handling-errors) in *The AWS Step Functions Workshop*. ## Namen der Fehler Step Functions identifiziert Fehler mithilfe von Zeichenketten, bei denen Groß- und Kleinschreibung beachtet wird, die als *Fehlernamen* bezeichnet werden. Die Amazon States Language definiert eine Reihe von integrierten Zeichenketten, die bekannte Fehler benennen, die alle mit dem `States.` Präfix beginnen. Zustände können Fehler mit anderen Namen melden. Die Fehlernamen dürfen jedoch nicht mit dem `States.` Präfix beginnen. Stellen Sie sicher, dass Ihr Produktionscode AWS Lambda Serviceausnahmen (`Lambda.ServiceException`und`Lambda.SdkClientException`) verarbeiten kann. Weitere Informationen finden Sie unter *Bewährte Methoden*. [Behandeln Sie vorübergehende Lambda-Serviceausnahmen](sfn-best-practices.md#bp-lambda-serviceexception) ** `States.ALL` ** Ein Platzhalter, der mit jedem bekannten Fehlernamen übereinstimmt. Der `States.ALL` Fehlertyp muss alleine in a vorkommen `Catcher` und kann den `States.DataLimitExceeded` Terminalfehler oder die `Runtime` Fehlertypen nicht abfangen. Weitere Informationen erhalten Sie unter [`States.DataLimitExceeded`](#error-data-limit-exceed) und [`States.Runtime`](#states-runtime-error). ** `States.DataLimitExceeded` ** Ein Terminalfehler, der nicht durch den `States.ALL` Fehlertyp abgefangen werden kann. Aufgrund der folgenden Bedingungen gemeldet: + Die Ausgabe eines Connectors übersteigt das Kontingent für die Payload-Größe. + Die Ausgabe eines Zustands ist größer als das Kontingent für die Nutzdatengröße. + Nach der `Parameters` Verarbeitung ist die Eingabe eines Zustands größer als das Payload-Größenkontingent. Weitere Informationen zu Kontingenten finden Sie unter[Step Functions Servicequotas](service-quotas.md). **`States.ExceedToleratedFailureThreshold`** Ein `Map` Status ist fehlgeschlagen, weil die Anzahl der ausgefallenen Elemente den in der Zustandsmaschinen-Definition angegebenen Schwellenwert überschritten hat. Weitere Informationen finden Sie unter [Festlegung von Ausfallschwellenwerten für Distributed Map-Zustände in Step Functions](state-map-distributed.md#maprun-fail-threshold). ** `States.HeartbeatTimeout` ** Ein `Task` Status konnte für einen Zeitraum, der länger als der `HeartbeatSeconds` Wert war, keinen Heartbeat senden. `HeartbeatTimeout`ist in den `Retry` Feldern `Catch` und verfügbar. ** `States.Http.Socket` ** Tritt auf, wenn bei einer HTTP-Aufgabe nach 60 Sekunden eine Zeitüberschreitung eintritt. Siehe [Kontingente im Zusammenhang mit HTTP-Tasks](service-quotas.md#service-limits-http-task). **`States.ItemReaderFailed`** Ein `Map` Status ist fehlgeschlagen, weil er nicht aus der im `ItemReader` Feld angegebenen Elementquelle lesen konnte. Weitere Informationen finden Sie unter `ItemReader (Karte)`. ** `States.Permissions` ** Ein `Task` Status schlug fehl, weil er nicht über ausreichende Rechte verfügte, um den angegebenen Code auszuführen. **`States.ResultWriterFailed`** Ein `Map` Status ist fehlgeschlagen, weil er keine Ergebnisse in das im `ResultWriter` Feld angegebene Ziel schreiben konnte. Weitere Informationen finden Sie unter `ResultWriter (Karte)`. **`States.Runtime`** Eine Ausführung ist aufgrund einer Ausnahme fehlgeschlagen, die nicht verarbeitet werden konnte. Oft werden diese durch Laufzeitfehler verursacht, z. B. durch den Versuch, `InputPath` oder `OutputPath` auf eine JSON-Nutzlast gleich Null anzuwenden. Ein `States.Runtime` Fehler kann nicht behoben werden und führt immer dazu, dass die Ausführung fehlschlägt. Ein erneuter Versuch oder ein catch On `States.ALL` deckt keine `States.Runtime` Fehler ab. ** `States.TaskFailed` ** Ein `Task`-Zustand ist während der Ausführung fehlgeschlagen. Wenn es in einem Wiederholungsversuch oder catch verwendet wird, `States.TaskFailed` fungiert es als Platzhalter, der jedem bekannten Fehlernamen entspricht, mit Ausnahme von. `States.Timeout` ** `States.Timeout` ** Wird gemeldet, wenn ein `Task` Status länger als der `TimeoutSeconds` Wert ist oder wenn für einen Zeitraum, der länger als der Wert ist, kein Heartbeat gesendet wurde. `HeartbeatSeconds` Wenn ein *verschachtelter Zustandsmaschine* einen auslöst`States.Timeout`, erhält der übergeordnete Computer eine Fehlermeldung. `States.TaskedFailed` Ein `States.Timeout` Fehler wird auch gemeldet, wenn die Ausführung einer gesamten Zustandsmaschine länger dauert als der angegebene `TimeoutSeconds` Wert. **Anmerkung** Unbehandelte Fehler in Lambda-Laufzeiten wurden in der Vergangenheit nur als gemeldet. `Lambda.Unknown` In neueren Laufzeiten werden Timeouts wie `Sandbox.Timedout` in der Fehlerausgabe gemeldet. Wenn Lambda die maximale Anzahl von Aufrufen überschreitet, wird der gemeldete Fehler angezeigt. `Lambda.TooManyRequestsException` Stimmt auf`Lambda.Unknown`, und ab`Sandbox.Timedout`, `States.TaskFailed` um mögliche Fehler zu behandeln. Sie können es auch verwenden`States.ALL`, aber es muss alleine und am Ende der Liste stehen. Weitere Informationen zu Lambda `Handled` und `Unhandled` Fehlern finden Sie `FunctionError` im [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax). ## Erneuter Versuch nach einem Fehler `Task``Parallel`, und `Map` Staaten können ein benanntes Feld haben`Retry`, dessen Wert ein Array von Objekten sein muss, die als *Retrier* bezeichnet werden. Eine einzelner Retrier steht für eine bestimmte Anzahl von erneuten Versuchen, in der Regel in zunehmenden Zeitintervallen. Wenn einer dieser Zustände einen Fehler meldet und es ein `Retry` Feld gibt, durchsucht Step Functions die Retrier in der Reihenfolge, die im Array aufgeführt ist. Wenn der Name des Fehlers im Wert eines `ErrorEquals` Retrier-Felds erscheint, versucht die State Machine erneut, wie im Feld definiert. `Retry` Wenn Ihre redriven Ausführung einen[Workflow-Status der Aufgabe](state-task.md), [Status des parallelen Workflows](state-parallel.md) oder [Inline-Map-Status](state-map-inline.md) wiederholt, für den Sie Wiederholungen definiert haben, wird die Anzahl der [Wiederholungsversuche](#error-handling-retrying-after-an-error) für diese Zustände auf 0 zurückgesetzt, um die maximale Anzahl von Versuchen zu ermöglichen. redrive Bei einer redriven Ausführung können Sie einzelne Wiederholungsversuche in diesen Zuständen mithilfe der Konsole verfolgen. Weitere Informationen finden Sie unter [Versuchen Sie, das Verhalten von Ausführungen zu wiederholen redriven](redrive-executions.md#redrive-retry-behavior) in [State-Machine-Ausführungen mit redrive In-Step-Funktionen neu starten](redrive-executions.md). Ein Retrier enthält die folgenden Felder: ** `ErrorEquals` (Erforderlich)** Ein nicht leeres Array von Zeichenfolgen, die mit Fehlernamen übereinstimmen. Wenn ein Bundesstaat einen Fehler meldet, durchsucht Step Functions die Retrier. Wenn der Fehlername in diesem Array erscheint, implementiert es die in diesem Retrier beschriebene Wiederholungsrichtlinie. ** `IntervalSeconds` (Optional)** Eine positive Ganzzahl, die die Anzahl der Sekunden vor dem ersten Wiederholungsversuch darstellt (`1`standardmäßig). `IntervalSeconds`hat einen Höchstwert von 99999999. ** `MaxAttempts` (Optional)** Eine positive Ganzzahl, die die maximale Anzahl von erneuten Versuchen angibt (standardmäßig `3`). Wenn der Fehler öfter als angegeben erneut auftritt, erfolgen keine erneuten Versuche und die normale Fehlerbehandlung wird fortgesetzt. Ein Wert von `0` gibt an, dass der Fehler nie erneut versucht wird. `MaxAttempts`hat einen Höchstwert von 99999999. ** `BackoffRate` (Optional)** Der Multiplikator, um den sich das mit bezeichnete Wiederholungsintervall nach jedem Wiederholungsversuch erhöht. `IntervalSeconds` Standardmäßig erhöht sich der `BackoffRate`-Wert um `2.0`. Nehmen wir zum Beispiel an, Ihr Wert `IntervalSeconds` ist 3, ist 3 und `MaxAttempts` ist 2. `BackoffRate` Der erste Wiederholungsversuch erfolgt drei Sekunden nach dem Auftreten des Fehlers. Der zweite Versuch erfolgt sechs Sekunden nach dem ersten Wiederholungsversuch. Während der dritte Wiederholungsversuch 12 Sekunden nach dem zweiten Wiederholungsversuch stattfindet. ** `MaxDelaySeconds` (Optional) ** Eine positive Ganzzahl, die den Höchstwert in Sekunden festlegt, bis zu dem ein Wiederholungsintervall verlängert werden kann. Es ist hilfreich, dieses Feld zusammen mit dem `BackoffRate` Feld zu verwenden. Der Wert, den Sie in diesem Feld angeben, begrenzt die exponentiellen Wartezeiten, die sich aus dem Multiplikator für die Backoff-Rate ergeben, der auf jeden aufeinanderfolgenden Wiederholungsversuch angewendet wird. Sie müssen einen Wert größer als 0 und kleiner als 31622401 für angeben. `MaxDelaySeconds` Wenn Sie diesen Wert nicht angeben, begrenzt Step Functions die Wartezeiten zwischen Wiederholungsversuchen nicht. ** `JitterStrategy` (Optional) ** Eine Zeichenfolge, die bestimmt, ob Jitter in die Wartezeiten zwischen aufeinanderfolgenden Wiederholungsversuchen einbezogen werden soll oder nicht. Jitter reduziert gleichzeitige Wiederholungsversuche, indem diese über ein zufälliges Verzögerungsintervall verteilt werden. Diese Zeichenfolge akzeptiert `FULL` oder `NONE` als ihre Werte. Der Standardwert ist `NONE`. Nehmen wir zum Beispiel an, Sie haben den Wert `MaxAttempts` als 3, `IntervalSeconds` als 2 und `BackoffRate` als 2 festgelegt. Der erste Wiederholungsversuch erfolgt zwei Sekunden nach dem Auftreten des Fehlers. Der zweite Wiederholungsversuch erfolgt vier Sekunden nach dem ersten Wiederholungsversuch und der dritte Wiederholungsversuch acht Sekunden nach dem zweiten Wiederholungsversuch. Wenn Sie den `JitterStrategy` Wert als festlegen`FULL`, wird das erste Wiederholungsintervall zufällig zwischen 0 und 2 Sekunden, das zweite Wiederholungsintervall zufällig zwischen 0 und 4 Sekunden und das dritte Wiederholungsintervall zufällig zwischen 0 und 8 Sekunden. **Anmerkung** Wiederholungen werden als Zustandsübergänge behandelt. Informationen darüber, wie sich Statusübergänge auf die Abrechnung auswirken, finden Sie unter [Step Functions — Preisgestaltung](https://aws.amazon.com/step-functions/pricing/). ### Feldbeispiele erneut versuchen Dieser Abschnitt enthält die folgenden `Retry` Feldbeispiele. + [Retry with BackoffRate](#retrybackoffrate) + [Retry with MaxDelaySeconds](#retrymaxdelayseconds) + [Retry all errors except States.Timeout](#retrytimeout) + [Complex retry scenario](#complexretryeg) **Beispiel 1 — Versuchen Sie es erneut mit BackoffRate** Das folgende Beispiel für a `Retry` führt zwei Wiederholungsversuche durch, wobei der erste Versuch nach einer Wartezeit von drei Sekunden erfolgt. Je nachdem, was `BackoffRate` Sie angeben, erhöht Step Functions das Intervall zwischen den einzelnen Wiederholungsversuchen, bis die maximale Anzahl von Wiederholungsversuchen erreicht ist. Im folgenden Beispiel beginnt der zweite Wiederholungsversuch, nachdem nach dem ersten Versuch drei Sekunden gewartet wurden. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 2, "BackoffRate": 1 } ] ``` **Beispiel 2 — Versuchen Sie es erneut mit MaxDelaySeconds** Im folgenden Beispiel werden drei Wiederholungsversuche durchgeführt und die daraus resultierende Wartezeit `BackoffRate` auf 5 Sekunden begrenzt. Der erste Wiederholungsversuch erfolgt nach einer Wartezeit von drei Sekunden. Der zweite und dritte Wiederholungsversuch finden nach einer Wartezeit fünf Sekunden nach dem vorherigen Wiederholungsversuch statt, da die maximale Wartezeit von `MaxDelaySeconds` festgelegt ist. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 3, "BackoffRate":2, "MaxDelaySeconds": 5, "JitterStrategy": "FULL" } ] ``` Ohne `MaxDelaySeconds` würde der zweite Wiederholungsversuch sechs Sekunden nach dem ersten Versuch stattfinden, und der dritte Wiederholungsversuch würde 12 Sekunden nach dem zweiten Versuch stattfinden. **Beispiel 3 — Alle Fehler mit Ausnahme von States.Timeout wiederholen** Der reservierte Name `States.ALL`, der im Feld `ErrorEquals` eines Retriers angezeigt wird, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array `ErrorEquals` erscheinen und er muss im letzten Retrier im Array `Retry` erscheinen. Der Name dient `States.TaskFailed` auch als Platzhalter und entspricht allen Fehlern mit Ausnahme von. `States.Timeout` Das folgende Beispiel für ein `Retry` Feld wiederholt jeden Fehler mit Ausnahme von. `States.Timeout` ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "MaxAttempts": 0 }, { "ErrorEquals": [ "States.ALL" ] } ] ``` **Beispiel 4 — Komplexes Wiederholungsszenario** Die Parameter eines Retriers gelten für alle Besuche des Retriers im Kontext einer einzelnen Zustandsausführung. Beachten Sie den folgenden `Task`-Zustand. ``` "X": { "Type": "Task", "Resource": "arn:aws:states:{{region}}:123456789012:task:X", "Next": "Y", "Retry": [ { "ErrorEquals": [ "ErrorA", "ErrorB" ], "IntervalSeconds": 1, "BackoffRate": 2.0, "MaxAttempts": 2 }, { "ErrorEquals": [ "ErrorC" ], "IntervalSeconds": 5 } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Z" } ] } ``` Diese Aufgabe schlägt viermal hintereinander fehl und gibt die folgenden Fehlernamen aus:`ErrorA`, `ErrorB``ErrorC`, und. `ErrorB` Infolgedessen geschieht Folgendes: + Die ersten beiden Fehler stimmen mit dem ersten Abruf überein und führen zu Wartezeiten von ein bis zwei Sekunden. + Der dritte Fehler entspricht dem zweiten Retrier und führt zu einer Wartezeit von fünf Sekunden. + Der vierte Fehler entspricht auch dem ersten Retrier. Für diesen bestimmten Fehler wurde jedoch bereits das Maximum von zwei Wiederholungen (`MaxAttempts`) erreicht. Daher schlägt dieser Retrier fehl und die Ausführung leitet den Workflow über das Feld in den `Z` Status um. `Catch` ## Fallback-Zustände `Task`, `Map` und `Parallel` Staaten können jeweils ein `Catch` benanntes Feld haben. Der Wert dieses Felds muss eine Reihe von Objekten sein, die als *Catcher* bekannt sind. Ein Catcher enthält die folgenden Felder. ** `ErrorEquals` (Erforderlich)** Ein nicht leeres Array von Zeichenfolgen, das mit Fehlernamen übereinstimmt, genauso angegeben wie bei dem Retrier-Feld desselben Namens. ** `Next` (Erforderlich)** Eine Zeichenfolge, die mit genau einem der Zustandsnamen des Zustandsautomaten übereinstimmen muss. ** `ResultPath`(JSONPath, Fakultativ)** Ein [Pfad](concepts-input-output-filtering.md), der bestimmt, welche Eingabe der Catcher an den im `Next` Feld angegebenen Status sendet. Wenn ein Status einen Fehler meldet und entweder kein `Retry` Feld vorhanden ist oder wenn der Fehler durch erneute Versuche nicht behoben werden kann, durchsucht Step Functions die Catcher in der Reihenfolge, die im Array aufgeführt ist. Wenn der Fehlername im Feld `ErrorEquals` eines Catchers erscheint, wechselt der Zustandsautomat in den Zustand, der im Feld `Next` genannt ist. Der reservierte Name `States.ALL`, der im Feld `ErrorEquals` des Catchers erscheint, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array `ErrorEquals` erscheinen und er muss im letzten Catcher im Array `Catch` erscheinen. Der Name dient `States.TaskFailed` auch als Platzhalter und entspricht allen Fehlern mit Ausnahme von. `States.Timeout` Im folgenden Beispiel wechselt ein `Catch`-Feld in den Zustand mit dem Namen `RecoveryState`, wenn eine Lambda-Funktion eine nicht behandelte Java-Ausnahme ausgibt. Andernfalls wechselt das Feld in den Zustand `EndState`. ``` "Catch": [ { "ErrorEquals": [ "java.lang.Exception" ], "ResultPath": "$.error-info", "Next": "RecoveryState" }, { "ErrorEquals": [ "States.ALL" ], "Next": "EndState" } ] ``` **Wie viele Fehler kann ein Catcher catch?** Jeder Catcher kann **mehrere Fehler** angeben, die behandelt werden sollen. ### Fehlerausgabe Wenn Step Functions in den in einem Fangnamen angegebenen Status übergeht, enthält das Objekt normalerweise das Feld`Cause`. Der Wert dieses Felds ist eine für Menschen lesbare Beschreibung des Fehlers. Das Objekt ist als *Fehlerausgabe* bekannt. Im vorherigen JSONPath Beispiel enthält der erste Catcher ein `ResultPath` Feld. Dies funktioniert ähnlich wie ein `ResultPath`-Feld im obersten Level eines Zustands, wodurch sich zwei Möglichkeiten ergeben: + Überschreiben Sie anhand der Ergebnisse der Ausführung dieses Zustands entweder die gesamte Eingabe des Zustands oder einen Teil davon. + Nimmt die Ergebnisse und fügt sie der Eingabe hinzu. Im Falle eines Fehlers, der von einem Catcher behandelt wird, ist das Ergebnis der Ausführung des Zustands die Fehlerausgabe. Für den ersten Catcher im Beispiel fügt der Catcher der Eingabe also die Fehlerausgabe als Feld mit dem Namen hinzu, `error-info` falls es nicht bereits ein Feld mit diesem Namen in der Eingabe gibt. Dann sendet der Catcher die gesamte Eingabe an`RecoveryState`. Beim zweiten Catcher überschreibt die Fehlerausgabe die Eingabe und der Catcher sendet nur die Fehlerausgabe an`EndState`. Wenn Sie bei JSONPath Workflows das `ResultPath` Feld nicht angeben, wird standardmäßig der Wert verwendet`$`, wodurch die gesamte Eingabe ausgewählt und überschrieben wird. Wenn ein Status `Retry` sowohl als auch `Catch` Felder enthält, verwendet Step Functions zuerst alle geeigneten Retrier. Wenn die Wiederholungsrichtlinie den Fehler nicht beheben kann, wendet Step Functions den passenden Catcher-Übergang an. ### Verursacht Payloads und Serviceintegrationen Ein Catcher gibt eine Zeichenketten-Payload als Ausgabe zurück. Wenn Sie mit Serviceintegrationen wie Amazon Athena oder arbeiten AWS CodeBuild, möchten Sie die `Cause` Zeichenfolge möglicherweise in JSON konvertieren. Das folgende Beispiel für einen `Pass` Status mit systemeigenen Funktionen zeigt, wie eine `Cause` Zeichenfolge in JSON konvertiert wird. ``` "Handle escaped JSON with JSONtoString": { "Type": "Pass", "Parameters": { "Cause.$": "States.StringToJson($.Cause)" }, "Next": "Pass State with Pass Processing" }, ``` ## Beispiele für Zustandsmaschinen mit Retry und Catch Die in den folgenden Beispielen definierten Zustandsmaschinen setzen die Existenz von zwei Lambda-Funktionen voraus: eine, die immer fehlschlägt, und eine, die lange genug wartet, bis ein in der Zustandsmaschine definierter Timeout eintritt. Dies ist eine Definition einer Lambda-Funktion von Node.js, die immer fehlschlägt und die Nachricht `error` zurückgibt. In den folgenden State-Machine-Beispielen wird diese Lambda-Funktion benannt`FailFunction`. Informationen zum Erstellen einer Lambda-Funktion finden Sie [Schritt 1: Erstellen einer Lambda-Funktion](tutorial-creating-lambda-state-machine.md#create-lambda-function) im Abschnitt. ``` exports.handler = (event, context, callback) => { callback("error"); }; ``` Dies ist eine Definition einer Lambda-Funktion von Node.js, die 10 Sekunden lang in den Ruhemodus wechselt. In den folgenden State-Machine-Beispielen wird diese Lambda-Funktion benannt`sleep10`. ``` exports.handler = (event, context, callback) => { setTimeout(function(){ }, 11000); }; ``` **Timeout-Einstellungen für die Funktion** Denken Sie beim Erstellen der Lambda-Funktion für die Beispiele daran, den `Timeout` Wert in den erweiterten Einstellungen auf 11 Sekunden festzulegen. ### Behandlung eines Fehlers mit Retry Dieser Zustandsautomat verwendet ein `Retry`-Feld, das eine fehlgeschlagene Funktion erneut versucht und den Fehlernamen `HandledError` ausgibt. Diese Funktion wird zweimal wiederholt, wobei zwischen den Wiederholungen ein exponentieller Backoff auftritt. ``` { "Comment": "A Hello World example invoking Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["HandledError"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` Diese Variante verwendet den vordefinierten Fehlercode`States.TaskFailed`, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["States.TaskFailed"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` **Bewährte Methoden für den Umgang mit Lambda-Ausnahmen** Aufgaben, die auf eine Lambda-Funktion verweisen, sollten Lambda-Serviceausnahmen behandeln. Weitere Informationen finden Sie unter [Behandeln Sie vorübergehende Lambda-Serviceausnahmen](sfn-best-practices.md#bp-lambda-serviceexception) Bewährte Methoden. ### Behandlung eines Fehlers mit Catch In diesem Beispiel wird ein `Catch`-Feld verwendet. Wenn eine Lambda-Funktion einen Fehler ausgibt, fängt sie den Fehler ab und die Zustandsmaschine wechselt in den `fallback` Status. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["HandledError"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` Diese Variante verwendet den vordefinierten Fehlercode`States.TaskFailed`, der jedem Fehler entspricht, den eine Lambda-Funktion ausgibt. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["States.TaskFailed"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` ### Behandlung eines Timeouts mithilfe von Retry Diese Zustandsmaschine verwendet ein `Retry` Feld, um einen `Task` Status, bei dem das Timeout überschritten wurde, erneut zu versuchen, basierend auf dem in angegebenen Timeout-Wert. `TimeoutSeconds` Step Functions wiederholt den Lambda-Funktionsaufruf in diesem `Task` Zustand zweimal, mit einem exponentiellen Backoff zwischen den Wiederholungen. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:sleep10", "TimeoutSeconds": 2, "Retry": [ { "ErrorEquals": ["States.Timeout"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` ### Behandlung eines Timeouts mit Catch In diesem Beispiel wird ein `Catch`-Feld verwendet. Wenn ein Timeout aufgetreten ist, wechsel der Zustandsautomat in den Zustand `fallback`. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:sleep10", "TimeoutSeconds": 2, "Catch": [ { "ErrorEquals": ["States.Timeout"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` **Beibehaltung von Statuseingaben und Fehlern in JSONPath** JSONPathIn können Sie die Statuseingabe und den Fehler beibehalten, indem Sie `ResultPath` Siehe [Wird verwendet ResultPath , um sowohl Fehler als auch Eingaben in eine `Catch`](input-output-resultpath.md#input-output-resultpath-catch).