Présentation de la gestion des erreurs

Dans Application Integration, des erreurs peuvent se produire lorsque vous testez et publiez une intégration, ou pendant l'exécution d'une intégration. Ces erreurs peuvent se produire en raison de divers problèmes côté client et côté serveur. Elles sont généralement classées comme suit :

Erreurs permanentes : toutes les erreurs côté client, telles que les échecs d'authentification ou les erreurs de validation des données, sont considérées comme des erreurs permanentes. Les erreurs permanentes entraînent des échecs permanents de la tâche.
Erreurs temporaires : toutes les erreurs côté serveur, telles que les erreurs HTTP 503 (service indisponible) et HTTP 400 (requête incorrecte), sont considérées comme des erreurs temporaires. Les erreurs temporaires entraînent des échecs temporaires de la tâche.

Les messages d'erreur s'affichent aux emplacements suivants :

Page des journaux d'exécution : affiche les erreurs rencontrées lors de l'exécution d'une intégration. Chaque exécution d'une intégration possède une entrée de journal distincte. Pour en savoir plus sur la page des journaux d'exécution, consultez la section Journaux d'exécution.
Page de l'éditeur d'intégrations : affiche les erreurs rencontrées lors de la publication d'une intégration. Les erreurs s'affichent au bas de la page de l'éditeur d'intégrations. Pour en savoir plus sur la page de l'éditeur d'intégrations, consultez la page Éditeur d'intégrations.

Pour en savoir plus sur la liste des codes d'erreur que vous pouvez rencontrer, consultez la section Codes d'erreur.

Méthodes de traitement des erreurs

L'intégration d'applications accepte les méthodes de traitement des erreurs suivantes pour générer, intercepter, relancer et personnaliser les erreurs rencontrées dans votre intégration:

Stratégies de traitement des erreurs: la stratégie de traitement des erreurs d'une tâche spécifie l'action à effectuer si celle-ci échoue en raison d'une erreur temporaire. Vous pouvez spécifier différentes stratégies de traitement des erreurs pour les modes d'exécution synchrone et asynchrone.
Collecteur d'erreurs: le collecteur d'erreurs définit une méthode personnalisée pour gérer l'échec d'un déclencheur, d'une tâche ou d'une condition de périphérie identifiés dans votre intégration. Vous pouvez définir un ou plusieurs systèmes de collecteur d'erreurs dans une même intégration pour gérer les erreurs de tâche et/ou les échecs d'exécution. Chaque collecteur d'erreurs peut être appelé à l'aide d'un déclencheur, nommé déclencheur de collecteur d'erreurs, pour exécuter l'ensemble de tâches d'intégration configurées et personnalisées pour gérer l'erreur.

Vous pouvez utiliser des méthodes de traitement des erreurs pour les modes d'exécution d'intégration à la fois synchrone et asynchrone :

Exécutions synchrones : en mode synchrone, le résultat de l'exécution de l'intégration est disponible peu après l'exécution de l'intégration. Le mode synchrone est utile dans les cas où vous souhaitez que le résultat de l'exécution s'affiche immédiatement après l'exécution de l'intégration. Les déclencheurs qui exécutent l'intégration en mode synchrone incluent les suivants :
- Tester ou publier une intégration
- Appeler l'API projects.locations.integrations.execute
- Appeler l'intégration à partir d'une sous-intégration en mode synchrone
Exécutions asynchrones : les exécutions asynchrones utilisent le modèle "fire and forget". Le mode asynchrone est utile lorsque les intégrations peuvent mettre beaucoup de temps à s'exécuter, ou si le résultat n'est pas requis immédiatement après l'exécution de l'intégration. Les déclencheurs qui exécutent l'intégration en mode asynchrone incluent les suivants :
- Toutes les exécutions qui ne sont pas synchrones sont exécutées en mode asynchrone. Certains des modes asynchrones les plus courants incluent, sans s'y limiter :
- Les exécutions qui sont reprises après une suspension ou une tâche d'approbation sont également exécutées en mode asynchrone, même si l'exécution initiale était en mode synchrone.

Bonne pratique

Utilisez à la fois une stratégie de gestion des erreurs et un collecteur d'erreurs dans votre intégration. En cas d'erreur, l'intégration suit la stratégie définie dans la section de gestion des erreurs. Une fois la stratégie de traitement des erreurs configurée épuisée, la logique de collecteur d'erreurs est déclenchée. Utilisez des variables système pour capturer la valeur du code d'erreur et du message d'erreur à envoyer à votre flux de détection des erreurs.

Exemple

Imaginons que vous disposiez d'un flux d'intégration pour créer une commande. Les nouvelles commandes sont créées dans Cloud SQL pour MySQL. Le flux utilise une tâche de connecteur (Créer une commande dans cet exemple) pour se connecter à Cloud SQL pour MySQL. En cas d'indisponibilité de la base de données, la tâche du connecteur génère des erreurs lors de l'insertion de nouvelles commandes dans la base de données. Nous vous recommandons d'utiliser à la fois une stratégie de gestion des erreurs et un collecteur d'erreurs dans votre intégration.

Pour ajouter la stratégie de gestion des erreurs, cliquez sur la tâche de connecteur dans le concepteur d'intégration pour ouvrir le volet de configuration de la tâche. Le schéma suivant montre la stratégie de gestion des erreurs configurée pour la tâche de connecteur Créer une commande:

Stratégie de traitement des erreurs pour la tâche "Créer un connecteur de commande"

Pour ajouter la stratégie de gestion des erreurs, cliquez sur la tâche Appeler un point de terminaison REST dans le concepteur d'intégration pour ouvrir le volet de configuration de la tâche. Le diagramme suivant illustre la stratégie de gestion des erreurs configurée pour la tâche Call REST Endpoint (Appeler un point de terminaison REST) :

Stratégie de gestion des erreurs pour la tâche "Appeler un point de terminaison REST"

Pour ajouter le collecteur d'erreurs, cliquez sur la tâche Appeler un point de terminaison REST dans le concepteur d'intégration pour ouvrir le volet de configuration de la tâche. Dans la section Collecteur d'erreurs, ajoutez les détails du collecteur d'erreurs. Le schéma suivant montre le collecteur d'erreurs configuré pour la tâche Appeler le point de terminaison REST:

Collecteur d'erreurs pour la tâche "Appeler un point de terminaison REST"

Codes d'erreur

Le tableau suivant décrit les erreurs susceptibles de se produire et leur origine. Application Integration utilise les codes d'erreur canoniques définis dans google.rpc.Code.

Pour en savoir plus sur les erreurs d'intégration d'applications et les différentes stratégies de traitement des erreurs, consultez la section Erreurs et gestion des erreurs.

Type d'exception standard	Code canonique	Code HTTP	Description
FailedPreconditionException	`FAILED_PRECONDITION`	400	La requête ne peut pas être exécutée dans l'état actuel du système.
BadRequestException	`INVALID_ARGUMENT`	400	Le client a spécifié un argument incorrect. Consultez le message d'erreur et les détails de l'erreur pour plus d'informations.
UnauthenticatedException	`UNAUTHENTICATED`	401	La requête n'a pas été authentifiée en raison d'un jeton OAuth manquant, non valide ou ayant expiré.
ForbiddenException	`PERMISSION_DENIED`	403	Le client ne dispose pas d'une autorisation suffisante. Cela peut se produire si le jeton OAuth ne dispose pas des champs d'application appropriés, si le client ne dispose pas des autorisations requises ou si l'API n'a pas été activée.
NotFoundException	`NOT_FOUND`	404	Une ressource spécifiée est introuvable.
AlreadyExistsException	`ALREADY_EXISTS`	409	La ressource qu'un client a essayé de créer existe déjà.
InternalError	`INTERNAL`	500	Erreur interne au serveur. Généralement un bug de serveur. Cela peut se produire si l'une des tâches ou les déclencheurs sont mal configurés.
UnimplementedException	`UNIMPLEMENTED`	501	Méthode d'API non mise en œuvre par le serveur.
ServiceUnavailableException	`UNAVAILABLE`	503	Service indisponible. Généralement, le serveur est inactif.
AbortedException	`ABORTED`	409	La taille de la réponse est trop importante.