Einführung in die Fehlerbehandlung
In Application Integration können Fehler beim Testen und Veröffentlichen einer Integration oder während der Ausführung einer Integration auftreten. Diese Fehler können aufgrund verschiedener clientseitiger und serverseitiger Probleme auftreten und sind grob klassifiziert:
- Permanente Fehler: Alle clientseitigen Fehler wie Authentifizierungsfehler oder Datenvalidierungsfehler werden als permanente Fehler betrachtet. Permanente Fehler führen zu permanenten Aufgabenfehlern.
- Temporäre Fehler: Alle serverseitigen Fehler wie HTTP 503 (Dienst nicht verfügbar), HTTP 400 (Fehlerhafte Anfrage) werden als temporäre Fehler betrachtet. Temporäre Fehler führen zu vorübergehenden Aufgabenfehlern.
Fehlermeldungen werden an den folgenden Stellen angezeigt:
- Seite Ausführungslogs: Zeigt Fehler an, die während der Ausführung einer Integration aufgetreten sind. Jede Ausführung einer Integration hat einen separaten Logeintrag. Informationen zur Seite mit den Ausführungslogs finden Sie unter Ausführungslogs.
- Seite Integrationseditor: Zeigt Fehler an, die beim Veröffentlichen einer Integration aufgetreten sind. Die Fehler werden unten auf der Seite "Integrationseditor" angezeigt. Informationen zur Seite „Integrationseditor“ finden Sie unter Integrationseditor.
Eine Liste der möglichen Fehlercodes finden Sie unter Fehlercodes.
Methoden zur Fehlerbehandlung
Application Integration unterstützt die folgenden Methoden zur Fehlerbehandlung, um die in Ihrer Integration aufgetretenen Fehler auszugeben, abzufangen, zu wiederholen und anzupassen:
- Strategien zur Fehlerbehandlung: Die Strategie zur Fehlerbehandlung für eine Aufgabe legt die Aktion fest, die ausgeführt werden soll, wenn die Aufgabe aufgrund eines temporären Fehlers fehlschlägt. Sie können für den synchronen und den asynchronen Ausführungsmodus verschiedene Strategien zur Fehlerbehandlung festlegen.
- Error Catcher: Ein Error Catcher definiert eine benutzerdefinierte Methode zur Behandlung des Fehlers eines erkannten Triggers, einer Aufgabe oder einer Edge-Bedingung in Ihrer Integration. Sie können einen oder mehrere Error Catcher in einer einzigen Integration definieren, um Aufgabenfehler und/oder Ausführungsfehler zu verarbeiten. Jeder Error Catcher kann über einen Trigger, den sogenannten Error Catcher-Trigger, aufgerufen werden, um die konfigurierten Integrationsaufgaben auszuführen, die für die Behebung des Fehlers angepasst sind.
Sie können Fehlerbehandlungsmethoden für den synchronen und den asynchronen Modus der Integrationsausführung verwenden:
-
Synchrone Ausführungen: Im synchronen Modus ist das Ausführungsergebnis der Integration kurz nach der Ausführung der Integration verfügbar. Der synchrone Modus ist in Szenarien nützlich, in denen Sie das Ausführungsergebnis unmittelbar nach der Ausführung der Integration wünschen. Trigger führen die Integration im synchronen Modus aus:
- Integration testen oder veröffentlichen
projects.locations.integrations.executeAPI aufrufen- Integration aus einer Subintegration im synchronen Modus aufrufen
-
Asynchrone Ausführungen: Asynchrone Ausführungen verwenden das Fire-and-Forget-Modell. Der asynchrone Modus eignet sich für Szenarien, in denen Integrationen sehr lange dauern können oder das Ausführungsergebnis nicht unmittelbar nach Ausführung der Integration erforderlich ist. Zu den Triggern, die die Integration im asynchronen Modus ausführen, gehören:
- Alle nicht synchronen Ausführungen werden im asynchronen Modus ausgeführt. Einige der gängigen asynchronen Modus sind unter anderem:
- Ausführungen, die von einer Sperrung oder einer Genehmigungsaufgabe fortgesetzt werden, werden ebenfalls im asynchronen Modus ausgeführt, selbst wenn die anfängliche Ausführung im synchronen Modus war.
Best Practice
Verwenden Sie sowohl eine Strategie zur Fehlerbehandlung als auch einen Error Catcher in Ihrer Integration. Bei jedem Fehler folgt die Integration der im Abschnitt zur Fehlerbehandlung definierten Strategie. Nachdem die konfigurierten Fehlerbehandlungsstrategien ausgeschöpft sind, wird die Error Catcher-Logik ausgelöst. Verwenden Sie Systemvariablen, um den Wert des Fehlercodes und der Fehlermeldung zu erfassen, die an Ihren Fehlerbehandlungsablauf gesendet werden sollen.
Beispiel
Angenommen, Sie haben einen Integrationsablauf zum Erstellen einer Bestellung. Neue Bestellungen werden in Cloud SQL for MySQL erstellt. Im Ablauf wird eine Connector-Aufgabe (in diesem Beispiel Bestellung erstellen) verwendet, um eine Verbindung zu Cloud SQL for MySQL herzustellen. Bei einem Datenbankausfall gibt die Connector-Aufgabe Fehler aus, wenn neue Bestellungen in die Datenbank eingefügt werden. Als Best Practice sollten Sie sowohl die Fehlerbehandlungsstrategie als auch den Error Catcher in Ihrer Integration verwenden.
Klicken Sie im Integrationsdesigner auf die Connector-Aufgabe, um den Bereich für die Aufgabenkonfiguration zu öffnen. Das folgende Diagramm zeigt die für die Connector-Aufgabe Bestellung erstellen konfigurierte Fehlerbehandlungsstrategie:
Klicken Sie im Integrationsdesigner auf die Aufgabe REST-Endpunkt aufrufen, um den Aufgabenkonfigurationsbereich zu öffnen. Das folgende Diagramm zeigt die für die Aufgabe REST-Endpunkt aufrufen konfigurierte Fehlerbehandlungsstrategie:
Klicken Sie im Integrationsdesigner auf die Aufgabe REST-Endpunkt aufrufen, um den Aufgabenkonfigurationsbereich zu öffnen. Fügen Sie im Bereich Error Catcher die Details zum Error Catcher hinzu. Das folgende Diagramm zeigt den Error Catcher, der für die Aufgabe REST-Endpunkt aufrufen konfiguriert ist:
Fehlercodes
In der folgenden Tabelle werden die möglichen Fehler und die zugehörigen Ursachen beschrieben. Application Integration verwendet die in google.rpc.Code definierten kanonischen Fehlercodes.
Informationen zu Application Integration-Fehlern und verschiedenen Strategien zur Fehlerbehebung finden Sie unter Fehler und Fehlerbehebung.
| Standardausnahmetyp | Kanonischer Code | HTTP-Code | Beschreibung |
|---|---|---|---|
| FailedPreconditionException | FAILED_PRECONDITION |
400 | Die Anfrage kann im aktuellen Systemzustand nicht ausgeführt werden. |
| BadRequestException | INVALID_ARGUMENT |
400 | Der Client hat ein ungültiges Argument angegeben. Weitere Informationen finden Sie in der Fehlermeldung und den Fehlerdetails. |
| UnauthenticatedException | UNAUTHENTICATED |
401 | Die Anfrage konnte aufgrund eines fehlenden, ungültigen oder abgelaufenen OAuth-Tokens nicht authentifiziert werden. |
| ForbiddenException | PERMISSION_DENIED |
403 | Der Client verfügt nicht über die erforderliche Berechtigung. Dies kann passieren, wenn das OAuth-Token nicht über die richtigen Bereiche verfügt, der Client nicht die erforderlichen Berechtigungen hat oder die API nicht aktiviert wurde. |
| NotFoundException | NOT_FOUND |
404 | Eine angegebene Ressource wurde nicht gefunden. |
| AlreadyExistsException | ALREADY_EXISTS |
409 | Die von einem Client zu erstellende Ressource ist bereits vorhanden. |
| InternalError | INTERNAL |
500 | Interner Serverfehler. In der Regel ein Serverprogrammfehler. Das kann passieren, wenn eine der Aufgaben oder Trigger falsch konfiguriert ist. |
| UnimplementedException | UNIMPLEMENTED |
501 | Die API-Methode wurde vom Server nicht implementiert. |
| ServiceUnavailableException | UNAVAILABLE |
503 | Dienst nicht verfügbar. In der Regel ist der Server ausgefallen. |
| AbortedException | ABORTED |
409 | Die Antwort ist zu groß. |