Gestion des erreurs d'appel Data Actions avec chemins de secours

1. Pourquoi une Data Action peut-elle échouer ?

Avant de gérer les erreurs, il est utile de comprendre leurs origines. Un appel de Data Action n'est pas une simple opération interne ; c'est une communication réseau avec un système distant. De nombreux facteurs peuvent entraîner un échec :

• Problèmes réseau : Le service externe est injoignable.
• Erreurs d'authentification ou de permissions : Les identifiants (OAuth client) utilisés pour l'intégration n'ont pas les droits suffisants pour exécuter l'appel API visé.
• Mauvaise requête (Bad Request) : Les données envoyées dans les Inputs de la Data Action sont incorrectes ou incomplètes (par exemple, un ID dans un format non attendu). L'API distante rejette la requête.
• Erreur côté serveur distant : Le service externe rencontre une erreur interne (souvent des erreurs HTTP 5xx).
• Ressource non trouvée : Vous demandez une information qui n'existe pas, comme les données d'un client avec un ID inconnu (erreur HTTP 404).
• Limites de débit (Rate Limiting) : Trop d'appels sont effectués en un court laps de temps, et le service distant refuse temporairement de nouvelles requêtes pour se protéger.
• Timeout : Le service externe met trop de temps à répondre.

Comprendre ces causes nous aide à concevoir des solutions de secours plus pertinentes.

2. Les chemins Failure et Timeout : Anatomie d'une erreur

Dans la leçon précédente, nous avons vu que l'action Call Data Action possède trois sorties. Revoyons en détail le rôle des chemins Failure et Timeout en nous appuyant sur la documentation officielle.

Deux points essentiels ressortent de cette lecture :

1. Le chemin Timeout est déclenché lorsque l'action Architect elle-même atteint son propre délai d'attente sans avoir reçu de réponse du service d'intégration de Genesys Cloud. C'est une sorte de filet de sécurité interne à Architect.
2. Le chemin Failure est le plus courant pour les erreurs. Il est déclenché dans de nombreux cas, y compris lorsque le service externe met trop de temps à répondre et que son propre timeout est atteint, ou lorsqu'il renvoie une réponse d'erreur (comme un code HTTP 404 ou 500).

La bonne nouvelle est que le chemin Failure ne nous laisse pas dans le noir. Il fournit des informations précieuses sur la cause de l'erreur.

3. Capturer les détails de l'erreur

Lorsque l'action prend le chemin Failure, elle met à disposition des sorties spécifiques à l'erreur, les Failure Outputs. Nous pouvons les lier à des variables de flux pour les analyser.

Les sorties d'échec les plus utiles sont :

• failure.outputs.errorCode : Un code d'erreur spécifique à Genesys Cloud.
• failure.outputs.status : Le code de statut HTTP retourné par l'API externe (ex: 404, 500, 403). C'est souvent le plus informatif !
• failure.outputs.message : Un message d'erreur descriptif.

Exercice pratique : Capturer les données d'erreur

Reprenons le flux que vous avez créé dans la leçon précédente.

1. Ouvrez votre flux "Test Data Action" dans Architect.
2. Cliquez sur l'action Call Data Action pour ouvrir son panneau de configuration.
3. Développez la section Failure Outputs.
4. À côté de status, cliquez dans le champ et créez une nouvelle variable de flux nommée Flow.ErrorCodeStatus.
5. À côté de message, créez une nouvelle variable de flux nommée Flow.ErrorMessage.
6. Validez et publiez votre flux.

Désormais, à chaque fois que votre Data Action échouera, le code de statut HTTP et le message d'erreur seront stockés dans ces variables, prêts à être utilisés.

4. Mettre en place des chemins de secours intelligents

Maintenant que nous pouvons savoir pourquoi une action a échoué, nous pouvons créer une logique de secours bien plus fine qu'un simple message d'erreur générique.

La documentation de Genesys Cloud regorge d'exemples qui illustrent d'excellentes pratiques de gestion d'erreurs.

Inspirons-nous de ces exemples pour implémenter des stratégies dans notre propre flux.

Stratégie 1 : Routage de secours contextuel

L'exemple de la recherche client dans Google est très pertinent : si la recherche échoue, l'appel est transféré vers une file "Nouveaux Clients". C'est une hypothèse logique : si on ne trouve pas le client, il est peut-être nouveau.

• Application : Dans votre flux, sous le chemin Failure, au lieu de déconnecter l'appel, vous pourriez ajouter une action Transfer to ACD pour envoyer l'appelant vers une file d'attente spécifique, par exemple "Support Technique".

Stratégie 2 : Messages différenciés pour Failure et Timeout

L'exemple du service météo est excellent car il gère Failure et Timeout différemment :

• Failure : "Nous n'avons pas pu déterminer la météo..."
• Timeout : "Le service météo a mis trop de temps à répondre."

Cela offre une expérience plus transparente à l'appelant.

• Application : Dans votre flux, placez une action Play Audio sous le chemin Timeout qui dit "Le service est momentanément ralenti, veuillez patienter." et qui boucle ou transfère. Sous le chemin Failure, utilisez une autre action Play Audio.

Stratégie 3 : Logique conditionnelle basée sur le code d'erreur

C'est la stratégie la plus avancée et la plus robuste. En utilisant la variable Flow.ErrorCodeStatus que nous avons créée, nous pouvons utiliser une action Decision ou Switch pour réagir différemment selon le type d'erreur.

Exercice guidé :

1. Dans votre flux, supprimez l'action Play Audio générique que vous aviez sous le chemin Failure.
2. Glissez-déposez une action Decision depuis la boîte à outils sous le chemin Failure.
3. Dans l'expression de la Decision, entrez : Flow.ErrorCodeStatus == 404
4. Vous avez maintenant deux sorties pour l'action Decision : Yes (l'erreur est bien une 404) et No.
   • Sous le chemin Yes, ajoutez une action Play Audio avec le message TTS : "Nous n'avons pas trouvé votre dossier. Nous vous mettons en relation avec un conseiller." Suivi d'un transfert vers une file d'attente pour les nouveaux clients.
   • Sous le chemin No, vous pouvez imbriquer une autre décision (par exemple, pour tester les erreurs 5xx) ou simplement mettre une gestion par défaut : ajoutez une action Play Audio avec le message "Une erreur technique est survenue." Suivi d'un transfert vers le support technique.

Ce diagramme illustre le principe d'une gestion d'erreur avancée. L'appel de la Data Action mène à un chemin d'échec, où une action 'Decision' analyse le code d'erreur pour router l'appel vers la ressource la plus appropriée.

Conclusion

Félicitations ! Vous avez terminé ce module sur les Data Actions en maîtrisant non seulement leur appel, mais aussi la gestion robuste des erreurs, une compétence qui distingue les administrateurs expérimentés.

Voici les points clés à retenir :

• Les erreurs de Data Actions sont inévitables et doivent être anticipées lors de la conception des flux.
• Le chemin Failure fournit des informations précieuses via les Failure Outputs, notamment le code de statut HTTP (status) et un message d'erreur.
• Le chemin Timeout est une sécurité interne à Architect, à gérer pour les cas où le service est particulièrement lent.
• En capturant les détails de l'erreur dans des variables, vous pouvez mettre en place des stratégies de secours intelligentes :
  • Routage de secours vers des files d'attente contextuelles.
  • Messages audio différenciés selon la nature du problème.
  • Logique conditionnelle avec des actions Decision ou Switch pour un traitement sur mesure de chaque type d'erreur.

Et après ?

Ce module était une introduction dense mais fondamentale. Dans le prochain module, "Architect : Flux pour Canaux Multiples", nous allons mettre en pratique une grande partie de ce que vous avez appris. Nous verrons comment créer des flux en file d'attente pour jouer des messages dynamiques (par exemple, un temps d'attente estimé récupéré via une... Data Action !), comment implémenter des solutions de rappel (callback), et comment adapter la logique des flux aux canaux digitaux comme l'email et le chat.