Intégration et exploitation des Data Actions dans Architect

1. L'action "Call Data Action" : le pont vers vos données

Dans la boîte à outils d'Architect, l'action qui nous permet d'exécuter une Data Action s'appelle logiquement Call Data Action. Elle se trouve dans la catégorie "Data". C'est cette action qui va servir de pont entre la logique de votre flux et le monde extérieur.

Pour bien comprendre son rôle, lisez l'introduction de la documentation Genesys Cloud.

Comme l'indique la documentation, l'action Call Data Action exécute l'appel, mais c'est à vous de décider quoi faire avec les données reçues en utilisant d'autres actions (comme Decision ou Play Audio).

2. Intégrer et configurer la Data Action dans un flux

Passons maintenant à la pratique. Nous allons créer un flux d'appel entrant simple qui appellera notre Data Action Récupérer infos utilisateur.

Exercice guidé :

1. Dans Genesys Cloud, allez dans Admin > Architect.
2. Créez un nouveau flux d'appel entrant (Inbound Call Flow). Donnez-lui un nom, par exemple "Test Data Action".
3. Dans la tâche de démarrage (Start), sous la section "Toolbox", développez la catégorie Data et glissez-déposez une action Call Data Action dans l'éditeur de flux.

Vous avez maintenant une action Call Data Action vide dans votre flux. Cliquons dessus pour la configurer.

Voici les étapes de configuration :

1. Category : Sélectionnez l'intégration que vous avez créée dans une leçon précédente (par ex., Intégration pour API Publiques).
2. Data Action : Choisissez la Data Action que nous avons préparée, Récupérer infos utilisateur.

Une fois la Data Action sélectionnée, deux nouvelles sections apparaissent : Inputs et Success Outputs. C'est ici que la magie opère et que les contrats que vous avez définis prennent tout leur sens.

• Inputs : Cette section affiche les paramètres du contrat d'entrée. Vous devriez voir userId. C'est ici que vous fournirez la donnée à envoyer à l'API. Pour notre test, nous allons utiliser une valeur fixe.

  • Cliquez dans le champ à côté de userId.
  • Sélectionnez le type Literal.
  • Entrez la valeur 1.

• Success Outputs : Cette section montre les données que l'action renverra en cas de succès, conformément à votre contrat de sortie. Vous devriez voir name et email. Nous devons maintenant stocker ces valeurs dans des variables de flux pour pouvoir les utiliser plus tard.

  • À côté de name, cliquez dans le champ et tapez Flow.UserName. Appuyez sur Entrée. Architect vous proposera de créer cette nouvelle variable. Acceptez.
  • Faites de même pour email, en créant une variable Flow.UserEmail.

Votre action est maintenant configurée pour appeler l'API avec l'ID utilisateur 1 et pour stocker le nom et l'email retournés dans deux variables de flux.

3. Exploiter la réponse : les chemins Succès, Échec et Timeout

Une fois l'action configurée, vous remarquerez qu'elle se divise en trois branches (ou "chemins") distincts. C'est un concept fondamental de la robustesse des flux Architect.

Pour comprendre la signification de chaque chemin, retournons à la documentation.

Maintenant, appliquons cela à notre flux :

• Chemin Success : C'est le cas idéal. L'API a répondu correctement. Nous pouvons utiliser les variables Flow.UserName et Flow.UserEmail.

  • Sous le chemin Success, ajoutez une action Play Audio.
  • Dans la configuration de Play Audio, utilisez la fonction Text-to-Speech (TTS) pour lire un message qui utilise nos variables. Par exemple : Concat("Bonjour ", Flow.UserName, ". L'email que nous avons est ", Flow.UserEmail).
  • Après le Play Audio, ajoutez une action Disconnect pour terminer l'appel.

• Chemin Failure : Une erreur s'est produite. L'API a peut-être renvoyé une erreur (ex: utilisateur non trouvé), ou la configuration est incorrecte.

  • Sous le chemin Failure, ajoutez une action Play Audio et faites-lui dire "Désolé, une erreur technique est survenue."
  • Ensuite, vous pourriez ajouter une action Transfer to ACD pour transférer l'appelant vers une file d'attente d'agents qui pourront l'aider manuellement. Pour cet exercice, ajoutez simplement une action Disconnect.

• Chemin Timeout : L'API n'a pas répondu dans le temps imparti (par défaut, 5 secondes).

  • La gestion est souvent similaire à celle de l'échec. Sous le chemin Timeout, ajoutez également une action Play Audio avec un message d'erreur, suivie d'un Disconnect.

4. Démonstration vidéo

Pour consolider tout ce que nous venons de voir, regardez cette démonstration pratique réalisée par la communauté Genesys. Elle montre comment un développeur intègre une Data Action dans un flux de chat, configure les sorties et gère les différents chemins. Les principes sont identiques pour un flux d'appel.

Après avoir suivi ces étapes, n'oubliez pas de Valider puis de Publier votre flux. Il est maintenant prêt à être associé à un numéro de téléphone pour être testé en conditions réelles.

Conclusion

Félicitations ! Vous avez réalisé une étape majeure en connectant la logique de routage d'Architect à une source de données externe. Vous ne vous contentez plus de router des appels sur la base d'informations statiques ; vous pouvez désormais enrichir vos flux avec des données dynamiques en temps réel.

Voici les points clés à retenir :

• L'action Call Data Action est l'élément qui permet d'exécuter une Data Action depuis un flux Architect.
• La configuration de l'action se fait en sélectionnant l'intégration et l'action, puis en mappant les entrées (Inputs) et les sorties (Outputs) avec des variables ou des valeurs littérales.
• Il est crucial de gérer les trois chemins de sortie : Success, Failure, et Timeout, pour garantir que votre flux se comporte de manière prévisible et robuste en toutes circonstances.
• Les données récupérées sur le chemin Success sont stockées dans des variables et peuvent être utilisées dans n'importe quelle action subséquente du flux (lecture audio, décisions de routage, etc.).

Prochaine leçon :

Dans cette leçon, nous avons traité les chemins Failure et Timeout de manière simple. Dans la prochaine et dernière leçon de ce module, nous allons approfondir ce sujet. Nous verrons comment gérer les erreurs d'appel de Data Actions avec des chemins de secours plus intelligents, en analysant les codes d'erreur pour prendre des décisions plus fines que simplement "transférer à un agent".