Gestionnaires d'état

Les gestionnaires d'état, également appelés gestionnaires, permettent de contrôler la conversation en créant des réponses pour les utilisateurs finaux et/ou en remplaçant la page active. À chaque tour de conversation, les gestionnaires sont évaluées et peuvent affecter la session. Les gestionnaires ont trois types généraux de données :

Terme Définition
Exigences des gestionnaires Il s'agit des exigences qui doivent être satisfaites pour que le gestionnaire ait un effet sur la session. Un gestionnaire est appelé lorsqu'il répond à ses exigences et affecte la session d'une manière ou d'une autre.
Fulfillment du gestionnaire Si un gestionnaire est appelé, un fulfillment facultatif est utilisé pour créer des réponses pour les utilisateurs finaux. Ces réponses sont définies dans les données de l'agent statique ou extraites de manière dynamique à partir de votre service de webhook.
Cible de transition du gestionnaire Si un gestionnaire est appelé, une cible de transition facultative est utilisée pour modifier la page actuelle. La page suivante ne peut être qu'une page d'accueil de flux ou une page du flux actuellement actif.

Il existe deux types de gestionnaires d'état avec des exigences de gestionnaire différentes :

Terme Définition
Routes Les routes sont appelées lorsqu'une entrée de l'utilisateur final correspond à un intent et/ou une condition sur l'état de la session est rempli. Une route avec une exigence d'intent est également appelée route d'intent. Une route ne comportant qu'une exigence requise est également appelée route de condition.
Gestionnaires d'événements Les gestionnaires d'événements sont appelés lorsqu'un événement est appelé. Certains événements intégrés sont déclenchés lorsque des entrées de l'utilisateur final inattendues sont reçues ou lorsqu'une erreur de webhook se produit. Vous pouvez également définir des événements personnalisés que vous appelez lorsqu'un événement se produit en dehors de la conversation.

Le traitement d'un gestionnaire d'état comprend trois étapes :

Terme Définition
1. Champ d'application Un gestionnaire doit figurer dans la portée pour avoir un effet sur la session. La portée est déterminée par l'application d'un gestionnaire à un paramètre de flux, de page ou de formulaire, et si le flux ou la page associés sont actifs ou si l'agent tente actuellement de remplir le paramètre de formulaire associé.
2. Évaluation Chaque gestionnaire dans la portée est évalué dans l'ordre. Si les exigences du gestionnaire sont remplies, il réussit l'évaluation.
3. Appel Si un gestionnaire est dans la portée et réussit l'évaluation, il est appelé. Un fulfillment associé est appelé, et toute cible de transition associée est appliquée à la session.

Champ d'application

Pour qu'un gestionnaire soit évalué, il doit être dans la portée. La portée du gestionnaire est un outil important et puissant qui vous aide à contrôler la conversation. En définissant la portée d'un gestionnaire, vous pouvez contrôler :

X Élément
Quand un intent peut être mis en correspondance.
Quand une condition doit être vérifiée.
Quand un événement peut être géré.
Quand une transition de page peut se produire.
Quand est fournie une réponse de fulfillment statique.
Quand un fulfillment compatible avec le webhook est appelé pour des réponses dynamiques.

La portée est déterminée par l'application d'un gestionnaire à un paramètre de flux, de page ou de formulaire, et si le flux ou la page associés sont actifs ou si l'agent tente actuellement de remplir le paramètre de formulaire associé.

Les règles détaillées de champ d'application sont les suivantes :

  • Routes appliquées au flux actif :
    • Si la page actuelle est la page d'accueil du flux, elles sont couvertes.
    • Si la page actuelle ne correspond pas à la page de démarrage du flux, elles n'entrent dans le champ d'application que si elles possèdent des exigences d'intent.
  • Les routes appliquées à la page actuelle sont dans la portée.
  • Les gestionnaires d'événements appliqués au flux actif sont couverts.
  • Les gestionnaires d'événements appliqués à la page actuelle entrent dans le champ d'application.
  • Les gestionnaires d'événements appliqués à un paramètre de formulaire que l'agent tente actuellement de remplir sont couverts.

Routes

Les routes ont deux exigences, et une ou les deux doivent être fournies. Si les deux exigences sont fournies, elles doivent toutes deux être satisfaites pour appeler la route :

Terme Définition
Exigence d'intent Un intent qui doit correspondre à l'entrée de l'utilisateur final pour le tour de conversation actuel Lorsqu'une route possède une exigence d'intent, elle est appelée route d'intent.
Condition requise Une condition qui doit être remplie. Lorsqu'une route présente des exigences préalables, elle est appelée route de condition.

Vous pouvez appliquer des routes à des flux (routes au niveau du flux) et aux pages (routes au niveau de la page). Par exemple, vous pouvez utiliser des routes dans les cas suivants :

X Élément
Lorsque l'entrée de l'utilisateur final correspond à un intent, la correspondance doit déclencher une réponse de fulfillment statique.
Lorsque l'entrée de l'utilisateur final correspond à un intent, la correspondance doit déclencher un fulfillment compatible avec un webhook pour une réponse dynamique.
Lorsque l'entrée de l'utilisateur final a fourni le dernier paramètre de formulaire requis, une vérification de condition déclenche une transition de session vers une autre page.
Lorsque l'entrée de l'utilisateur final a fourni un paramètre de formulaire spécifique, une vérification de condition déclenche une réponse de fulfillment statique.
Une vérification de condition définie sur true force la transition d'une page.

Propagation de l'intent

Normalement, lorsqu'une route est appelée en raison d'un intent correspondant, l'intent est consommé. Un intent utilisé ne peut pas être mis en correspondance, sauf si une nouvelle entrée de l'utilisateur final déclenche une nouvelle correspondance d'intent. Toutefois, il est possible de propager une correspondance d'intent d'un flux à un autre dans le scénario suivant :

  • Une route dans flow F1 a intent I1 comme exigence et flow F2 comme cible de transition.
  • Flow F2 a une route qui a également intent I1 comme exigence.

Dans ce cas, lorsque la route dans flow F1 est appelée, intent I1 est mis en correspondance deux fois pour une entrée d'utilisateur final unique et les deux routes sont appelées.

La propagation des intents est utile dans les scénarios suivants :

X Élément
Remplacez la page actuelle par une page spécifique dans un autre flux (la route du flux cible de transition a une page cible de transition spécifique).
Créez un message d'entrée pour la page de démarrage d'un flux (la route du flux cible de transition a un fulfillment).

Groupes de routes

Lorsque vous créez un agent, vous pouvez constater que de nombreuses pages ont un ensemble commun de routes. Pour rendre les routes réutilisables, vous pouvez définir des groupes de routes. Vous pouvez créer ces ressources de groupe réutilisables dans le flux ou dans l'ensemble de l'agent.

Par exemple, vous souhaitez que votre flux gère les entrées de l'utilisateur final, telles que "Je veux ajouter un supplément à ma pizza" et "Je veux modifier la taille de ma boisson". Ces entrées doivent être gérées lorsqu'une des pages du flux est active. Vous pouvez définir deux routes avec des intents afin de gérer ces entrées pour toutes les pages pertinentes, mais cela représente beaucoup de travail en double. Vous pouvez définir le groupe de routes une seule fois et ajouter une référence au groupe sur toutes les pages pertinentes.

Groupes de routes au niveau du flux

Les groupes de routes au niveau du flux sont des ressources de groupe de routes créées avec un flux comme parent. Ils sont réutilisables dans le flux.

Groupes de routes au niveau de l'agent

Les groupes de routes au niveau de l'agent sont des ressources de groupe de routes créées avec un agent comme parent. Ils sont réutilisables dans l'ensemble de l'agent, mais n'autorisent pas les routes qui passent à une page non symbolique comme cible.

Routes au niveau du flux

Les routes au niveau du flux sont des routes appliquées à un flux en les ajoutant à la page de démarrage du flux. Ces types de gestionnaires présentent les cas d'utilisation suivants :

X Élément
Gestionnaires avec une exigence d'intent ou de condition pour la page d'accueil du flux
Gestionnaires avec une exigence d'intent sur la portée pour toutes les pages du flux.

Pour créer des routes au niveau du flux à partir de la console:

  1. Ouvrez la page de démarrage du flux.
  2. Cliquez sur le bouton d'ajout sous l'en-tête Routes.
  3. Le panneau de modification de l'itinéraire s'ouvre.
  4. Fournissez des champs d'itinéraire.
  5. Cliquez sur Enregistrer.

Pour réorganiser les routes au niveau du flux à partir de la console:

  1. Ouvrez la page de démarrage du flux.
  2. Cliquez sur l'en-tête Routes.
  3. Le panneau de liste des itinéraires s'ouvre.
  4. Faites glisser les itinéraires dans l'ordre souhaité. Vous pouvez également cliquer sur le menu d'options , puis sélectionner Déplacer vers.

Pour supprimer des routes au niveau du flux à partir de la console:

  1. Ouvrez la page de démarrage du flux.
  2. Cliquez sur l'en-tête Routes.
  3. Le panneau de liste des itinéraires s'ouvre.
  4. Cliquez sur le menu Option .
  5. Sélectionnez Supprimer.

Routes au niveau de la page

Les routes au niveau de la page sont des routes qui sont appliquées à une page. Ces types de gestionnaires présentent les cas d'utilisation suivants :

X Élément
Gestionnaires avec une exigence d'intent ou de condition dans la portée lorsque des pages spécifiques sont actives.

Pour créer des routes au niveau de la page à partir de la console:

  1. Ouvrez la page (et non la page de démarrage du flux).
  2. Cliquez sur le bouton d'ajout sous l'en-tête Routes.
  3. Le panneau de modification de l'itinéraire s'ouvre.
  4. Fournissez des champs d'itinéraire.
  5. Cliquez sur Enregistrer.

Pour réorganiser les routes au niveau de la page depuis la console:

  1. Ouvrez la page (et non la page de démarrage du flux).
  2. Cliquez sur l'en-tête Routes.
  3. Le panneau de liste des itinéraires s'ouvre.
  4. Faites glisser les routes dans l'ordre souhaité. Vous pouvez également cliquer sur le menu d'options , puis sélectionner Déplacer vers.

Pour supprimer des routes au niveau de la page depuis la console:

  1. Ouvrez la page (et non la page de démarrage du flux).
  2. Cliquez sur l'en-tête Routes.
  3. Le panneau de liste des itinéraires s'ouvre.
  4. Cliquez sur le menu Option .
  5. Sélectionnez Supprimer.

Gestionnaires d'événements

Les gestionnaires d'événements ont besoin d'une exigence pour être appelés :

Terme Définition
Exigence sur l'événement Un événement qui doit être appelé. Les événements sont identifiés par leur nom. Certains événements intégrés sont appelés lorsque des entrées de l'utilisateur final inattendues sont reçues ou lorsqu'une erreur de webhook se produit. Vous pouvez également définir des événements personnalisés que vous appelez lorsqu'un événement se produit en dehors de la conversation.

Vous pouvez appliquer des gestionnaires d'événements aux flux (gestionnaires d'événements au niveau du flux), aux pages (gestionnaires d'événements au niveau de la page) et aux paramètres (gestionnaires d'événements au niveau des paramètres). Par exemple, vous pouvez utiliser des gestionnaires d'événements dans les situations suivantes :

X Élément
Lorsque l'entrée de l'utilisateur final ne correspond à aucun intent, un gestionnaire d'événements sans correspondance fournit une réponse de fulfillment statique spécifique.
Un minuteur expire dans votre système, et vous souhaitez fournir des informations de rappel à l'utilisateur final avec une réponse de fulfillment statique spécifique.

Gestionnaires d'événements au niveau du flux

Les gestionnaires d'événements au niveau du flux sont des gestionnaires d'événements appliqués à un flux. Ces types de gestionnaires présentent les cas d'utilisation suivants :

X Élément
Gestionnaires avec une exigence d'événement dans la portée de la page d'accueil du flux.
Gestionnaires avec une exigence d'événement dans la portée pour toutes les pages du flux.
Gestion des entrées inattendues de l'utilisateur final, partagées par toutes les pages d'un flux
Gestion des erreurs de webhook, partagées par toutes les pages d'un flux
Gestion des événements personnalisés appelés par votre système et partagés par toutes les pages d'un flux

Chaque flux dispose de gestionnaires d'événements pour les événements intégrés no-match et no-input. Ces gestionnaires d'événements sont automatiquement créés lorsque vous créez un flux et ne peuvent pas être supprimés.

Pour créer des gestionnaires d'événements au niveau du flux à partir de la console:

  1. Ouvrez la page de démarrage du flux.
  2. Cliquez sur le bouton d'ajout  sous l'en-tête Gestionnaires d'événements.
  3. Le panneau du gestionnaire d'événements s'ouvre.
  4. Fournissez des champs de gestionnaire d'événements.
  5. Cliquez sur Enregistrer.

Pour supprimer des gestionnaires d'événements au niveau du flux depuis la console:

  1. Ouvrez la page de démarrage du flux.
  2. Cliquez sur l'en-tête Gestionnaires d'événements.
  3. Le panneau de la liste des gestionnaires d'événements s'ouvre.
  4. Pointez sur un gestionnaire d'événements, puis cliquez sur le bouton de suppression .

Gestionnaires d'événements au niveau de la page

Les gestionnaires d'événements au niveau de la page sont des gestionnaires d'événements appliqués à une page. Ces types de gestionnaires présentent les cas d'utilisation suivants :

X Élément
Gestionnaires avec une exigence d'événements dans la portée lorsque des pages spécifiques sont actives.
Gestion des entrées inattendues de l'utilisateur final, spécifiques à une page
Gestion des erreurs du webhook, spécifique à une page
Gestion des événements personnalisés appelés par votre système, spécifiques à une page

Pour créer des gestionnaires d'événements au niveau de la page depuis la console:

  1. Ouvrez une page (pas la page de démarrage du flux).
  2. Si l'en-tête Gestionnaires d'événements ne s'affiche pas, cliquez sur Ajouter un gestionnaire d'état, sélectionnez Gestionnaires d'événements, puis cliquez sur Appliquer.
  3. Cliquez sur le bouton d'ajout  sous l'en-tête Gestionnaires d'événements.
  4. Le panneau du gestionnaire d'événements s'ouvre.
  5. Fournissez des champs de gestionnaire d'événements.
  6. Cliquez sur Enregistrer.

Pour supprimer des gestionnaires d'événements au niveau de la page de la console:

  1. Ouvrez une page (pas la page de démarrage du flux).
  2. Cliquez sur l'en-tête Gestionnaires d'événements.
  3. Le panneau de la liste des gestionnaires d'événements s'ouvre.
  4. Pointez sur un gestionnaire d'événements, puis cliquez sur le bouton de suppression .

Gestionnaires d'événements au niveau du paramètre

Les gestionnaires d'événements au niveau des paramètres sont des gestionnaires d'événements appliqués à un paramètre de formulaire. Ils sont également appelés gestionnaires de nouvelles invites. Ces gestionnaires d'événements n'autorisent pas les événements personnalisés, car ils sont spécifiquement destinés à gérer les entrées de l'utilisateur final non valides lors du remplissage du formulaire.

Ces types de gestionnaires présentent les cas d'utilisation suivants :

X Élément
L'utilisateur final n'a pas fourni d'entrée valide lorsqu'il a été invité à renseigner un paramètre de formulaire.

Pour créer des gestionnaires d'événements au niveau des paramètres à partir de la console:

  1. Ouvrez une page contenant des paramètres de formulaire.
  2. Cliquez sur un paramètre.
  3. Le panneau des paramètres s'ouvre.
  4. Faites défiler la page jusqu'à la section Gestionnaires d'événements de nouvelle requête, puis cliquez sur Ajouter un gestionnaire d'événements.
  5. Le panneau du gestionnaire d'événements s'ouvre.
  6. Fournissez des champs de gestionnaire d'événements.
  7. Cliquez sur Enregistrer.

Pour supprimer des gestionnaires d'événements au niveau du paramètre depuis la console:

  1. Ouvrez une page contenant des paramètres de formulaire.
  2. Cliquez sur un paramètre.
  3. Le panneau des paramètres s'ouvre.
  4. Faites défiler la page jusqu'à la section Gestionnaires d'événements de nouvelle invite.
  5. Pointez sur un gestionnaire d'événements, puis cliquez sur le bouton de suppression .

Événements intégrés

Les événements suivants sont intégrés et sont appelés par les agents de conversation (Dialogflow CX). Certains événements sont limités à certains niveaux.

Nom de l'événement
 Au niveau du flux Au niveau de la page Au niveau du paramètre Appelé lorsque
sys.no-match-default ✔ ✔ ✔
  • Au niveau du flux ou de la page: l'entrée de l'utilisateur final ne correspond à aucun intent pour les gestionnaires dans la portée.
  • Au niveau du paramètre: l'entrée de l'utilisateur final ne satisfait pas au paramètre de formulaire.
sys.no-match-[1-6] ✔ ✔ ✔ Si vous fournissez des gestionnaires pour l'un de ces événements triés par ordre numérique, ils sont appelés à la place de sys.no-match-default et dans l'ordre suivant : sys.no-match-1, sys.no-match-2, ...
sys.no-input-default ✔ ✔ ✔ L'entrée de l'utilisateur final n'a pas été reçue. Cette méthode peut être appelée dans les cas suivants :
  • Les agents de conversation (Dialogflow CX) reçoivent une entrée texte d'utilisateur final vide.
  • Les agents de conversation (Dialogflow CX) reçoivent une entrée audio d'utilisateur final vide ou une entrée audio sans mots reconnus.
  • Un délai d'inactivité de voix expire avant que l'entrée audio d'utilisateur final ne contienne des mots reconnus.
sys.no-input-[1-6] ✔ ✔ ✔ Si vous fournissez des gestionnaires pour l'un de ces événements triés par ordre numérique, ils sont appelés à la place de sys.no-input-default et dans l'ordre suivant : sys.no-input-1, sys.no-input-2, ...
sys.invalid-parameter ✔ Appelé lorsqu'une réponse de webhook invalide le paramètre en définissant WebhookResponse.pageInfo.formInfo.parameterInfo.state sur INVALID.
sys.long-utterance ✔ ✔ ✔ L'entrée de l'utilisateur final dépasse la longueur maximale autorisée (256 caractères) correspondant à des intents non génératifs ou à des paramètres. Si aucune valeur n'est fournie, les agents de conversation (Dialogflow CX) traitent l'énoncé de l'utilisateur en tant que no-match. Pour les entrées audio en streaming, cet événement ne se déclenche qu'après la fermeture du flux audio par le client.
webhook.error ✔ ✔ L'appel du webhook a renvoyé une erreur. Cet événement n'est appelé que dans les cas suivants: 1) s'il n'existe pas de gestionnaire d'événements webhook précis (par exemple, webhook.error.timeout) correspondant au code d'erreur du webhook ; 2) s'il n'existe pas de cible de transition définie dans l'itinéraire d'origine qui a appelé le traitement avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
webhook.error.timeout ✔ ✔ L'appel du webhook a expiré. Un événement de webhook n'est appelé que si aucune cible de transition n'est définie dans la route d'origine qui a appelé l'exécution avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
webhook.error.bad-request ✔ ✔ Le webhook a renvoyé 400 Bad Request. Un événement de webhook n'est appelé que si aucune cible de transition n'est définie dans la route d'origine qui a appelé l'exécution avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
webhook.error.rejected ✔ ✔ Le webhook a renvoyé 401 Unauthorized (Opération non autorisée) ou 403 Forbidden (Accès refusé). Un événement de webhook n'est appelé que si aucune cible de transition n'est définie dans la route d'origine qui a appelé l'exécution avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
webhook.error.unavailable ✔ ✔ Le webhook a renvoyé 503 Service Unavailable (503 Service indisponible). Un événement de webhook n'est appelé que si aucune cible de transition n'est définie dans la route d'origine qui a appelé l'exécution avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
webhook.error.not-found ✔ ✔ L'appel du webhook a échoué, car l'URL du webhook n'était pas joignable. Un événement de webhook n'est appelé que si aucune cible de transition n'est définie dans la route d'origine qui a appelé l'exécution avec le webhook défaillant. Pour en savoir plus, consultez la section Ordre d'évaluation.
flow-cancelled ✔ ✔ L'utilisateur final a demandé l'annulation du flux. Cet événement est déclenché par la page "End Flow With Cancellation" (Mettre fin au flux avec une annulation). Consultez la cible de transition symbolique END_FLOW_WITH_CANCELLATION.
flow-failed ✔ ✔ Ce flux n'a pas pu effectuer la tâche donnée. Cet événement est déclenché par la page "End Flow With Failure" (Mettre fin au flux en cas d'échec). Consultez la cible de transition symbolique END_FLOW_WITH_FAILURE.
flow-failed-human-escalation ✔ ✔ L'utilisateur final a demandé à parler à des agents humains. Cet événement est déclenché par la page "End Flow With Human Escalation" (Mettre fin au flux avec escalade manuelle). Consultez la cible de transition symbolique END_FLOW_WITH_HUMAN_ESCALATION.

Événements personnalisés

Vous pouvez créer des événements et des gestionnaires d'événements personnalisés. Les événements personnalisés permettent de gérer les événements qui se produisent en dehors de la conversation avec l'utilisateur final. Par exemple, l'utilisateur final a cliqué sur un bouton, un certain temps s'est écoulé, l'inventaire disponible a changé au cours de la conversation, etc.

Les événements sont simplement identifiés par un nom. Vous devez éviter d'utiliser des noms d'événements commençant par sys. ou webhook. pour éviter tout conflit avec les événements intégrés.

Pour appeler un événement avec l'API, consultez le champ queryInput.event de la méthode detectIntent pour le type Session.

Sélectionnez un protocole et une version pour la référence de session :

Protocole V3 V3beta1
REST Ressource de session Ressource de session
RPC Interface de session Interface de session
C++ SessionsClient Non disponible
C# SessionsClient Non disponible
Go SessionsClient Non disponible
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP Non disponible Non disponible
Python SessionsClient SessionsClient
Ruby Non disponible Non disponible

Ordre d'évaluation

Les gestionnaires sont évalués dans un ordre spécifique. Les règles générales suivantes s'appliquent :

  1. Seuls les gestionnaires dans la portée sont évalués.
  2. Seuls les gestionnaires dont les exigences sont satisfaites peuvent être appelés.
  3. Si un gestionnaire sans cible de transition est appelé, l'évaluation de la liste des gestionnaires se poursuit. En raison de cette règle, plusieurs fulfillments peuvent ajouter plusieurs messages à la file d'attente de réponses.
  4. Si un gestionnaire avec une cible de transition est appelé, l'évaluation de la liste des gestionnaires se termine.
  5. Si un gestionnaire avec le fulfillment est appelé et que le fulfillment génère une erreur webhook :
    • Si une cible de transition est définie pour le gestionnaire, le webhook échoue silencieusement.
    • Si un gestionnaire d'événements relève de la portée de l'événement, il gère l'événement et l'évaluation de la liste des gestionnaires.
    • Si aucun gestionnaire d'événements n'est dans le champ d'application de l'événement, le webhook échoue silencieusement.
  6. Lorsqu'une exigence d'intent est satisfaite, l'intent est consommé. Ainsi, seul le premier gestionnaire de routage trouvé pour l'intent peut être appelé (consultez la section Propagation de l'intent pour connaître les exceptions).
  7. Lorsqu'une exigence de condition est satisfaite, la condition n'est pas consommée. Vous pouvez donc appeler plusieurs routes avec la condition.
  8. Lorsqu'une exigence d'événement est satisfaite, l'événement est consommé. Ainsi, seul le premier gestionnaire d'événements trouvé pour l'événement peut être appelé.
  9. La pile d'appel du gestionnaire peut affecter l'ordre d'évaluation.

L'évaluation comporte trois phases :

  1. Les routes présentant une exigence d'intent sont évaluées dans l'ordre suivant :
    1. Au niveau de la page : routes individuelles appliquées à la page actuelle, dans l'ordre indiqué.
    2. Groupes au niveau de la page : groupes de routes appliqués à la page active, dans l'ordre indiqué.
    3. Au niveau du flux : routes appliquées au flux actif, dans l'ordre indiqué.
    4. Groupes au niveau du flux : groupes de routes appliqués au flux actif, dans l'ordre indiqué.
  2. Les routes avec seulement une exigence de condition sont évaluées dans l'ordre suivant :
    1. Au niveau de la page : routes individuelles appliquées à la page actuelle, dans l'ordre indiqué.
    2. Groupes au niveau de la page : groupes de routes appliqués à la page active, dans l'ordre indiqué.
    3. Au niveau du flux (uniquement si la page actuelle est la page d'accueil du flux) : routes appliquées au flux actif, dans l'ordre indiqué.
    4. Groupes au niveau du flux (uniquement si la page actuelle est la page d'accueil du flux) : groupes de routes appliqués au flux actif, dans l'ordre indiqué.
  3. Les gestionnaires d'événements sont évalués dans l'ordre suivant :
    1. Au niveau du paramètre : gestionnaires d'événements appliqués au paramètre de formulaire de la page actuelle que l'agent tente de remplir (gestionnaires de nouvelles), dans l'ordre indiqué
    2. Au niveau de la page : gestionnaires d'événements appliqués à la page active, dans l'ordre indiqué
    3. Au niveau du flux : gestionnaires d'événements appliqués au flux actif, dans l'ordre indiqué

Cibles de transition symboliques

Lorsque vous saisissez une cible de transition pour un gestionnaire, vous pouvez entrer des flux ou des pages spécifiques, mais vous pouvez également saisir des cibles de transition symboliques :

Cible de transition symbolique
 Description
START_PAGE Passe à la page de démarrage du flux actif portant le même nom
END_FLOW Termine le flux actuellement actif et revient à la page qui a provoqué une transition vers le flux actuel Consultez également la section Pile d'appels du gestionnaire et limite de pile de flux.
END_FLOW_WITH_CANCELLATION Termine le flux actuellement actif et revient à la page qui a provoqué une transition vers le flux actuel La page appelante peut gérer cette transition avec l'événement intégré flow-cancelled. Consultez également la section Pile d'appels du gestionnaire et limite de pile de flux.
END_FLOW_WITH_FAILURE Termine le flux actuellement actif et revient à la page qui a provoqué une transition vers le flux actuel La page appelante peut gérer cette transition avec l'événement intégré flow-failed. Consultez également la section Pile d'appels du gestionnaire et limite de pile de flux.
END_FLOW_WITH_HUMAN_ESCALATION Termine le flux actuellement actif et revient à la page qui a provoqué une transition vers le flux actuel La page appelante peut gérer cette transition avec l'événement intégré flow-failed-human-escalation. Consultez également la section Pile d'appels du gestionnaire et limite de pile de flux.
END_SESSION Effacez la session en cours et passez à la page spéciale nommée END_SESSION. La prochaine entrée utilisateur redémarrera la session sur la page d'accueil du flux de démarrage par défaut.
PREVIOUS_PAGE Transition vers la page précédente ayant provoqué une transition vers la page actuelle L'état de la page précédente sera restauré après la transition.
CURRENT_PAGE Revient à la page actuelle. Cela peut être utile si vous voulez que l'agent répète quelque chose.

Pile d'appels du gestionnaire et limite de la pile de flux

Lorsqu'une session passe d'un flux à un autre avec des cibles de transition spécifiques, chaque flux est ajouté à la pile de flux.

Pile d'appels du gestionnaire

Lorsqu'une session passe à END_FLOW, elle revient à la page d'appel qui a provoqué une transition vers le flux terminé. Dans ce cas, la pile d'appels du gestionnaire est conservée. Tous les gestionnaires qui ont été évalués précédemment à partir de la page d'appel sont ignorés, et les gestionnaires restants sont évalués dans l'ordre.

Exemple :

  1. La page P comporte trois gestionnaires dans cet ordre : H1, H2, H3.
  2. H1 est évalué, mais ne provoque pas de transition.
  3. H2 est évalué, ce qui entraîne une transition vers le flux F.
  4. Une page du flux F effectue une transition vers END_FLOW.
  5. La session revient à la page P, qui redevient active avec un état préservé.
  6. L'évaluation par le gestionnaire de la page P se poursuit à partir de l'état préservé, ce qui signifie que H3 est évalué.

Limite de la pile de flux

La limite maximale de la pile de flux est de 25. Si vous dépassez la limite maximale de la pile, des flux peuvent être supprimés de la pile, ce qui entraîne un comportement inattendu lors de l'utilisation de la transition END_FLOW. Pour éviter ces problèmes potentiels, réduisez le nombre de transitions de flux à flux précédant la transition END_FLOW.

Si la pile de flux est vide, la transition END_FLOW met fin à la session.

Définir des conditions

Pour définir des conditions avec la console, vous devez fournir des règles de condition avec l'une des trois options logiques suivantes :

  • Correspondance avec AU MOINS UNE règle (OR)
  • Correspondance avec TOUTES les règles (AND)
  • Personnaliser l'expression

Pour plus de commodité, vous pouvez utiliser les options AND/OR pour créer des conditions simples ou composées pour les valeurs de paramètres.

Vous pouvez utiliser le formulaire gratuit Personnaliser l'expression pour tous les types de conditions, y compris : Fonctions système et Constantes booléennes.

Par exemple, pour définir une condition ayant 10 % de chances de réussir l'évaluation, sélectionnez Personnaliser l'expression puis saisissez $sys.func.rand() < 0.1 dans le champ Condition :

Capture d&#39;écran de la définition d&#39;une condition personnalisée

Précédent
Pages
Suivant
Intents