Avis de fin de support : le 15 septembre 2025, le support pour Amazon Lex V1 AWS sera interrompu. Après le 15 septembre 2025, vous ne pourrez plus accéder à la console Amazon Lex V1 ni aux ressources Amazon Lex V1. Si vous utilisez Amazon Lex V2, consultez plutôt le [guide Amazon Lex V2](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html). Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Étape 5 (facultatif) : Vérification des détails du flux d'informations (console) Cette section explique le flux d'informations entre le client et Amazon Lex pour chaque entrée utilisateur, y compris l'intégration de la fonction Lambda. **Note** La section part du principe que le client envoie des demandes à Amazon Lex à l'aide de l'API `PostText` d'exécution et affiche les détails des demandes et des réponses en conséquence. Pour un exemple du flux d'informations entre le client et Amazon Lex dans lequel le client utilise l'`PostContent`API, consultez[Étape 2a (facultatif) : Vérification des détails du flux d'informations vocales (console)](gs-bp-details-postcontent-flow.md). Pour plus d'informations sur l'API d'exécution `PostText`, et obtenir des détails supplémentaires sur les demandes et les réponses illustrées dans les étapes suivantes, consultez [PostText](API_runtime_PostText.md). 1. Utilisateur : I would like to order some flowers. 1. Le client (console) envoie la demande [PostText](API_runtime_PostText.md) suivante à Amazon Lex : ``` POST /bot/{{OrderFlowers}}/alias/{{$LATEST}}/user/{{ignw84y6seypre4xly5rimopuri2xwnd}}/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "I would like to order some flowers", "sessionAttributes": {} } ``` L'URI et le corps de la demande fournissent des informations à Amazon Lex : + URI de demande — Fournit le nom du bot (`OrderFlowers`), l'alias du bot (`$LATEST`) et le nom d'utilisateur (chaîne aléatoire identifiant l'utilisateur). Le code `text` de fin indique qu'il s'agit d'une demande d'API `PostText` (et non `PostContent`). + Corps de la demande – Inclut l'entrée utilisateur (`inputText`) et un champ `sessionAttributes` vide. Lorsque le client effectue la première demande, il n'existe aucun attribut de session. La fonction Lambda initiera ces attributs ultérieurement. 1. À partir du`inputText`, Amazon Lex détecte l'intention (`OrderFlowers`). Cette intention est configurée avec une fonction Lambda en tant que crochet de code pour l'initialisation et la validation des données utilisateur. Amazon Lex invoque donc cette fonction Lambda en transmettant les informations suivantes sous forme de données d'événement : ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": {}, "bot": { "name": "OrderFlowers", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": null, "PickupDate": null }, "confirmationStatus": "None" } } ``` Pour de plus amples informations, veuillez consulter [Format d'un événement d'entrée](lambda-input-response-format.md#using-lambda-input-event-format). Outre les informations envoyées par le client, Amazon Lex inclut également les données supplémentaires suivantes : + `messageVersion`— Actuellement, Amazon Lex ne prend en charge que la version 1.0. + `invocationSource`— Indique l'objectif de l'appel de la fonction Lambda. Dans ce cas, il s'agit d'effectuer l'initialisation et la validation des données utilisateur. À l'heure actuelle, Amazon Lex sait que l'utilisateur n'a pas fourni toutes les données de créneau conformément à son intention. + Informations `currentIntent`, pour lesquelles toutes les valeurs d'option sont définies sur null. 1. Pour l'instant, toutes les valeurs d'option sont null. La fonction Lambda n'a rien à valider. La fonction Lambda renvoie la réponse suivante à Amazon Lex : ``` { "sessionAttributes": {}, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": null, "PickupDate": null } } } ``` Pour plus d'informations sur le format de réponse, consultez [Format de la réponse](lambda-input-response-format.md#using-lambda-response-format). Notez ce qui suit : + `dialogAction.type`— En définissant cette valeur sur`Delegate`, la fonction Lambda délègue la responsabilité de décider de la prochaine ligne de conduite à Amazon Lex. **Note** Si la fonction Lambda détecte un élément lors de la validation des données utilisateur, elle indique à Amazon Lex la marche à suivre, comme indiqué dans les étapes suivantes. 1. Selon le`dialogAction.type`, Amazon Lex décide de la prochaine ligne de conduite. Comme aucune des options n'est remplie, il décide d'obtenir la valeur pour l'option `FlowerType`. Il sélectionne aussi l'une des invites d'obtention de valeur (« What type of flowers would you like to order? ») pour l'option, puis il renvoie la réponse suivante au client : ![Données JSON contenant une demande pour l'option FlowerType.](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-10.png) Le client affiche le message dans la réponse. 1. Utilisateur : roses 1. Le client envoie la [PostText](API_runtime_PostText.md) demande suivante à Amazon Lex : ``` POST /bot/{{OrderFlowers}}/alias/{{$LATEST}}/user/{{ignw84y6seypre4xly5rimopuri2xwnd}}/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "roses", "sessionAttributes": {} } ``` Dans le corps de la demande, `inputText` fournit l'entrée utilisateur. `sessionAttributes` reste vide. 1. Amazon Lex interprète d'abord le `inputText` dans le contexte de l'intention actuelle. Le service se souvient qu'il avait demandé à cet utilisateur des informations sur l'option `FlowerType`. Il met à jour la valeur du slot dans l'intention actuelle et appelle la fonction Lambda avec les données d'événement suivantes : ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": {}, "bot": { "name": "OrderFlowers", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": null }, "confirmationStatus": "None" } } ``` Notez ce qui suit : + `invocationSource` – Continue d'être `DialogCodeHook` (nous validons simplement les données utilisateur). + `currentIntent.slots`— Amazon Lex a changé le `FlowerType` slot en roses. 1. Selon la `invocationSource` valeur de`DialogCodeHook`, la fonction Lambda effectue la validation des données utilisateur. Elle la reconnaît `roses` comme une valeur d'emplacement valide (et la définit `Price` comme un attribut de session) et renvoie la réponse suivante à Amazon Lex. ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": null } } } ``` Notez ce qui suit : + `sessionAttributes`— La fonction Lambda a ajouté `Price` (des roses) en tant qu'attribut de session. + `dialogAction.type` – Est défini sur `Delegate`. Les données utilisateur étant valides, la fonction Lambda indique à Amazon Lex de choisir le plan d'action suivant.   1. Selon le`dialogAction.type`, Amazon Lex choisit la prochaine ligne de conduite. Amazon Lex sait qu'il a besoin de plus de données d'emplacement. Il choisit donc le prochain emplacement vide (`PickupDate`) ayant la priorité la plus élevée en fonction de la configuration prévue. Amazon Lex sélectionne l'un des messages d'incitation à valeur ajoutée : « Quel jour voulez-vous que les roses soient cueillies ? » —pour cet emplacement en fonction de la configuration d'intention, puis renvoie la réponse suivante au client : ![Données JSON envoyées au client pour demander l'option PickupData .](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-20.png) Le client affiche simplement le message dans la réponse – « What day do you want the roses to be picked up? ». 1. Utilisateur : tomorrow 1. Le client envoie la [PostText](API_runtime_PostText.md) demande suivante à Amazon Lex : ``` POST /bot/{{OrderFlowers}}/alias/{{$LATEST}}/user/{{ignw84y6seypre4xly5rimopuri2xwnd}}/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "tomorrow", "sessionAttributes": { "Price": "25" } } ``` Dans le corps de la demande, `inputText` fournit l'entrée utilisateur ; le client retransmet les attributs de session au service. 1. Amazon Lex se souvient du contexte, à savoir qu'il s'agissait de collecter des données pour le slot. `PickupDate` Dans ce contexte, il sait que la valeur `inputText` est pour l'option `PickupDate`. Amazon Lex invoque ensuite la fonction Lambda en envoyant l'événement suivant : ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "None" } } ``` Amazon Lex a mis à jour le en `currentIntent.slots` définissant la `PickupDate` valeur. Notez également que le service transmet le `sessionAttributes` tel quel à la fonction Lambda. 1. Selon la `invocationSource` valeur de`DialogCodeHook`, la fonction Lambda effectue la validation des données utilisateur. Il reconnaît que la valeur de l'`PickupDate`emplacement est valide et renvoie la réponse suivante à Amazon Lex : ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": "2017-01-05" } } } ``` Notez ce qui suit : + `sessionAttributes` – Pas de modification. + `dialogAction.type` – Est défini sur `Delegate`. Les données utilisateur étaient valides et la fonction Lambda indique à Amazon Lex de choisir le plan d'action suivant. 1. Selon le`dialogAction.type`, Amazon Lex choisit la prochaine ligne de conduite. Amazon Lex sait qu'il a besoin de plus de données d'emplacement. Il choisit donc le prochain emplacement vide (`PickupTime`) ayant la priorité la plus élevée en fonction de la configuration prévue. Amazon Lex sélectionne l'un des messages d'invite (« Livrez les roses à quelle heure le 05/01/2017 ? ») pour cet emplacement en fonction de la configuration d'intention et renvoie la réponse suivante au client : ![Données JSON pour demander le PickupTime slot.](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-30.png) Le client affiche le message dans la réponse : « Livrez les roses à quelle heure le 05/01/2017 ? » 1. Utilisateur : 4 pm 1. Le client envoie la [PostText](API_runtime_PostText.md) demande suivante à Amazon Lex : ``` POST /bot/{{OrderFlowers}}/alias/{{$LATEST}}/user/{{ignw84y6seypre4xly5rimopuri2xwnd}}/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "4 pm", "sessionAttributes": { "Price": "25" } } ``` Dans le corps de la demande, `inputText` fournit l'entrée utilisateur. Le client transmet les attributs de session (`sessionAttributes`) dans la demande. 1. Amazon Lex comprend le contexte. Il comprend qu'il obtenait des données pour l'option `PickupTime`. Dans ce contexte, il sait que la `inputText` valeur est pour le `PickupTime` slot. Amazon Lex invoque ensuite la fonction Lambda en envoyant l'événement suivant : ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "None" } } ``` Amazon Lex a mis à jour le en `currentIntent.slots` définissant la `PickupTime` valeur. 1. Selon la `invocationSource` valeur de`DialogCodeHook`, la fonction Lambda effectue la validation des données utilisateur. Il reconnaît que la valeur de l'`PickupDate`emplacement est valide et renvoie la réponse suivante à Amazon Lex. ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" } } } ``` Notez ce qui suit : + `sessionAttributes` – Aucune modification dans l'attribut de session. + `dialogAction.type` – Est défini sur `Delegate`. Les données utilisateur étant valides, la fonction Lambda indique à Amazon Lex de choisir le plan d'action suivant. 1. À l'heure actuelle, Amazon Lex sait qu'il dispose de toutes les données relatives aux emplacements. Cette intention est configurée avec un message de confirmation. Amazon Lex envoie donc la réponse suivante à l'utilisateur pour lui demander une confirmation avant de réaliser son intention : ![Données JSON pour demander la confirmation de la commande.](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-45.png) Le client affiche simplement le message dans la réponse et attend la réponse de l'utilisateur. 1. Utilisateur : Yes 1. Le client envoie la [PostText](API_runtime_PostText.md) demande suivante à Amazon Lex : ``` POST /bot/{{OrderFlowers}}/alias/{{$LATEST}}/user/{{ignw84y6seypre4xly5rimopuri2xwnd}}/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "yes", "sessionAttributes": { "Price": "25" } } ``` 1. Amazon Lex interprète le `inputText` dans le contexte de la confirmation de l'intention actuelle. Amazon Lex comprend que l'utilisateur souhaite poursuivre la commande. Cette fois, Amazon Lex invoque la fonction Lambda pour répondre à son intention en envoyant l'événement suivant, qui définit `invocationSource` le `FulfillmentCodeHook` to dans l'événement envoyé à la fonction Lambda. Amazon Lex définit également la valeur `confirmationStatus` à`Confirmed`. ``` { "messageVersion": "1.0", "invocationSource": "FulfillmentCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "Confirmed" } } ``` Notez ce qui suit : + `invocationSource`— Cette fois, Amazon Lex a défini cette valeur sur`FulfillmentCodeHook`, demandant à la fonction Lambda de répondre à l'intention. + `confirmationStatus` – Est défini sur `Confirmed`. 1. Cette fois, la fonction Lambda répond à l'`OrderFlowers`intention et renvoie la réponse suivante : ``` { "sessionAttributes": { "Price": "25" }, "dialogAction": { "type": "Close", "fulfillmentState": "Fulfilled", "message": { "contentType": "PlainText", "content": "Thanks, your order for roses has been placed and will be ready for pickup by 16:00 on 2017-01-05" } } } ``` Notez ce qui suit : + Définit le `dialogAction.type` — La fonction Lambda définit cette valeur sur`Close`, indiquant à Amazon Lex de ne pas s'attendre à une réponse de l'utilisateur. + `dialogAction.fulfillmentState` – Est défini sur Fulfilled et inclut un `message` approprié à transmettre à l'utilisateur. 1. Amazon Lex examine le `fulfillmentState` et renvoie la réponse suivante au client. Amazon Lex renvoie ensuite ce qui suit au client : ![Données JSON pour l'invite de confirmation.](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-48.png) Remarque : + `dialogState`— Amazon Lex définit cette valeur sur`fulfilled`. + `message`— est le même message que celui fourni par la fonction Lambda. Le client affiche le message. 1. Maintenant, retestez le bot. Pour établir un nouveau contexte (nouvel utilisateur), choisissez le lien **Effacer** dans la fenêtre de test. A présent, fournissez des données d'option non valides pour l'intention `OrderFlowers`. Cette fois, la fonction Lambda effectue la validation des données, rétablit la valeur nulle des données d'emplacement non valide et demande à Amazon Lex de demander à l'utilisateur de fournir des données valides. Par exemple, essayez ce qui suit : + Jasmine comme type de fleur (ce n'est pas l'un des types de fleur pris en charge). + Yesterday comme jour pendant lequel vous souhaitez récupérer les fleurs. + Après avoir passé votre commande, entrez un autre type de fleur au lieu de répondre « yes » pour confirmer la commande. En réponse, la fonction Lambda met à jour l'attribut `Price` in the session, en conservant le total cumulé des commandes de fleurs. La fonction Lambda exécute également l'activité d'exécution. **Étape suivante** [Étape 6 : Mise à jour de la configuration de l'intention pour ajouter un énoncé (console)](gs-bp-utterance.md)