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.
# Exercice 1 : créer un robot Amazon Lex à l'aide d'un plan (console)
Dans cet exercice, vous effectuez les opérations suivantes :
+ Créez votre premier bot Amazon Lex et testez-le dans la console Amazon Lex.
Pour cet exercice, vous allez utiliser le **OrderFlowers**plan. Pour obtenir des informations sur les modèles de présentation, consultez [Amazon Lex et AWS Lambda Blueprints](lex-lambda-blueprints.md).
+ Créez une AWS Lambda fonction et testez-la dans la console Lambda. Lors du traitement d'une demande, votre bot appelle cette fonction Lambda. Pour cet exercice, vous allez utiliser un plan Lambda (**lex-order-flowers-python**) fourni dans la AWS Lambda console pour créer votre fonction Lambda. Le code du plan montre comment vous pouvez utiliser la même fonction Lambda pour effectuer l'initialisation et la validation, et pour répondre à l'objectif. `OrderFlowers`
+ Mettez à jour le bot pour ajouter la fonction Lambda comme crochet de code afin de répondre à l'intention. Testez l' end-to-endexpérience.
Les sections suivantes expliquent les modèles.
## Amazon Lex Bot : présentation du plan
Vous utilisez le **OrderFlowers**plan pour créer un robot Amazon Lex. Pour plus d'informations sur la structure d'un bot, consultez. [Amazon Lex : comment ça marche](how-it-works.md) Le bot est préconfiguré comme suit :
+ **Intention** — OrderFlowers
+ **Types d'option** – un type d'option personnalisé appelé `FlowerTypes` avec des valeurs d'énumération : `roses`, `lilies` et `tulips`.
+ **Options** – L'intention nécessite les informations suivantes (c'est à dire des options) pour que le bot puisse traiter l'intention.
+ `PickupTime` (type prédéfini AMAZON.TIME)
+ `FlowerType`(type FlowerTypes personnalisé)
+ `PickupDate` (type prédéfini AMAZON.DATE)
+ **Enoncé** – Les exemples d'énoncés suivants indiquent l'intention de l'utilisateur :
+ « I would like to pick up flowers. »
+ « "I would like to order some flowers. »
+ **Invites** – une fois que le bot a identifié l'intention, il utilise les invites suivantes pour indiquer les options :
+ Invite de l'option `FlowerType` – « Quel type de fleurs souhaitez-vous commander ? »
+ Demande de `PickupDate` créneau — « Quel jour voulez-vous que le \$1FlowerType\$1 soit retiré ? »
+ Demander le `PickupTime` créneau — « À quelle heure voulez-vous que le \$1FlowerType\$1 soit retiré ? »
+ Déclaration de confirmation — « OK, votre \$1FlowerType\$1 sera prêt à être retiré le \$1PickupTime\$1 le \$1PickupDate\$1. Cela vous convient-il ? »
## AWS Lambda Fonction : Résumé du plan
Dans cet exercice, la fonction Lambda exécute à la fois des tâches d'initialisation, de validation et d'exécution. Par conséquent, après avoir créé la fonction Lambda, vous mettez à jour la configuration d'intention en spécifiant la même fonction Lambda en tant que crochet de code pour gérer à la fois les tâches d'initialisation, de validation et d'exécution.
+ En tant que crochet de code d'initialisation et de validation, la fonction Lambda effectue une validation de base. Par exemple, si l'utilisateur indique une heure de retrait en dehors des heures normales de bureau, la fonction Lambda demande à Amazon Lex de lui demander à nouveau l'heure.
+ Dans le cadre du crochet du code d'expédition, la fonction Lambda renvoie un message récapitulatif indiquant que la commande de fleurs a été passée (c'est-à-dire que l'intention a été remplie).
**Étape suivante**
[Étape 1 : créer un robot Amazon Lex (console)](gs-bp-create-bot.md)
# Étape 1 : créer un robot Amazon Lex (console)
Pour cet exercice, créez un bot pour commander des fleurs, appelé OrderFlowersBot.
Pour créer un bot Amazon Lex (console)
1. Connectez-vous à la console Amazon Lex AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/).
1. S'il s'agit de votre premier bot, choisissez **Get Started (Mise en route)**. Sinon, sur la page **Bots**, choisissez **Create (Créer)**.
1. Sur la page **Create your Lex bot**, saisissez les informations suivantes et choisissez **Créer**.
+ Choisissez le modèle **OrderFlowers**.
+ Laissez le nom du bot par défaut (OrderFlowers).
+ Pour **COPPA**, choisissez **No**.
+ Pour le **stockage des énoncés de l'utilisateur**, choisissez la réponse appropriée.
1. Choisissez **Créer**. La console envoie les demandes nécessaires à Amazon Lex pour enregistrer la configuration. La console affiche ensuite la fenêtre d'édition du bot.
1. Attendez la confirmation que le bot a été créé.
1. Testez le bot.
**Note**
Pour ce faire, tapez un texte dans la fenêtre de test ou, pour les navigateurs compatibles, en sélectionnant le micro dans la même fenêtre et en parlant.
Utilisez l'exemple de texte suivant pour engager une conversation avec le bot afin de commander des fleurs :
![\[\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/OrderFlowers-NoLambda.png)
A partir de ces informations, le bot déduit l'intention `OrderFlowers` et vous invite à entrer des données d'option. Lorsque vous fournissez toutes les données d'option requises, le bot traite l'intention (`OrderFlowers`) en renvoyant toutes les informations à l'application cliente (dans ce cas, la console). La console affiche les informations dans la fenêtre de test.
En particulier :
+ Dans la déclaration « What day do you want the roses to be picked up? « , le terme « roses » s'affiche, car le message correspondant à l'option `pickupDate` est configuré à l'aide des substitutions, `{FlowerType}`. Vous pouvez vérifier cela dans la console.
+ La déclaration « Okay, your roses will be ready... » est celle que vous avez configurée comme invite de confirmation.
+ La dernière déclaration (« `FlowerType:roses...` ») correspond simplement aux données d'option qui sont renvoyées au client, dans ce cas, dans la fenêtre de test. Dans l'exercice suivant, vous utiliserez une fonction Lambda pour répondre à l'intention, auquel cas vous recevrez un message indiquant que la commande est exécutée.
**Étape suivante**
[Étape 2 (facultatif) : Vérification des détails du flux d'informations (console)](gs-bp-details-two-runtime-apis.md)
# Étape 2 (facultatif) : Vérification des détails du flux d'informations (console)
Cette section explique le flux d'informations entre un client et Amazon Lex pour chaque entrée utilisateur dans notre exemple de conversation.
L'exemple utilise la fenêtre de test de la console pour la conversation avec le bot.
**Pour ouvrir la fenêtre de test Amazon Lex**
1. Connectez-vous à la console Amazon Lex AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/).
1. Choisissez le bot à tester.
1. Sur le côté droit de la console, choisissez **Tester le chatbot**.
Pour voir le flux d'informations pour le contenu vocal ou écrit, choisissez la rubrique appropriée.
**Topics**
+ [Étape 2a (facultatif) : Vérification des détails du flux d'informations vocales (console)](gs-bp-details-postcontent-flow.md)
+ [Étape 2b (facultatif) : Vérification des détails du flux d'informations saisies (console)](gs-bp-details-part1.md)
# Étape 2a (facultatif) : Vérification des détails du flux d'informations vocales (console)
Cette section explique le flux d'informations entre le client et Amazon Lex lorsque le client utilise la parole pour envoyer des demandes. Pour de plus amples informations, veuillez consulter [PostContent](API_runtime_PostContent.md).
1. L'utilisateur dit : I would like to order some flowers.
1. Le client (console) envoie la demande [PostContent](API_runtime_PostContent.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "audio/x-l16; sample-rate=16000; channel-count=1"
Accept: "audio/mpeg"
Request body
input stream
```
L'URI et le corps de la demande fournissent des informations à Amazon Lex :
+ URI de demande — Fournit le nom du bot (`$LATEST`), son alias () et le nom d'utilisateur (chaîne aléatoire identifiant l'utilisateur). `OrderFlowers` `content`indique qu'il s'agit d'une demande d'`PostContent`API (et non d'une `PostText` demande).
+ En-têtes de demandes
+ `x-amz-lex-session-attributes`— La valeur codée en base64 représente « \$1\$1 ». Lorsque le client effectue la première demande, il n'existe aucun attribut de session.
+ `Content-Type` – Reflète le format audio.
+ Corps de la demande – Le flux audio d'entrée utilisateur (« I would like to order some flowers. »).
**Note**
Si l'utilisateur choisit d'envoyer un texte (« I would like to order some flowers ») à l'API `PostContent` au lieu de parler, le corps de la demande est l'entrée utilisateur. L'en-tête `Content-Type` est défini en conséquence :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "text/plain; charset=utf-8"
Accept: accept
Request body
input stream
```
1. À partir du flux d'entrée, Amazon Lex détecte l'intention (`OrderFlowers`). Il choisit alors l'une des options de l'intention (dans ce cas, `FlowerType`) et l'une de ses invites d'obtention de valeur, puis il envoie une réponse avec les en-têtes suivants :
```
x-amz-lex-dialog-state:ElicitSlot
x-amz-lex-input-transcript:I would like to order some flowers.
x-amz-lex-intent-name:OrderFlowers
x-amz-lex-message:What type of flowers would you like to order?
x-amz-lex-session-attributes:e30=
x-amz-lex-slot-to-elicit:FlowerType
x-amz-lex-slots:eyJQaWNrdXBUaW1lIjpudWxsLCJGbG93ZXJUeXBlIjpudWxsLCJQaWNrdXBEYXRlIjpudWxsfQ==
```
Les valeurs d'en-tête fournissent les informations suivantes :
+ `x-amz-lex-input-transcript` – Fournit la transcription du message audio (entrée utilisateur) à partir de la demande
+ `x-amz-lex-message`— Fournit la transcription de l'audio renvoyé par Amazon Lex dans la réponse
+ `x-amz-lex-slots` – La version encodée en base 64 des options et valeurs :
```
{"PickupTime":null,"FlowerType":null,"PickupDate":null}
```
+ `x-amz-lex-session-attributes` – La version encodée en base 64 des attributs de session (\$1\$1)
Le client lit le message audio dans le corps de réponse.
1. L'utilisateur dit : roses
1. Le client (console) envoie la demande [PostContent](API_runtime_PostContent.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "audio/x-l16; sample-rate=16000; channel-count=1"
Accept: "audio/mpeg"
Request body
input stream ("roses")
```
Le corps de la demande est le flux audio de l'entrée utilisateur (roses). `sessionAttributes` reste vide.
1. Amazon Lex interprète le flux d'entrée dans le contexte de l'intention actuelle (il se souvient qu'il a demandé à cet utilisateur des informations relatives au `FlowerType` slot). Amazon Lex met d'abord à jour la valeur de l'emplacement en fonction de l'intention actuelle. Il choisit ensuite un autre emplacement (`PickupDate`), ainsi que l'un de ses messages invite (When do you want to pick up the roses?), puis renvoie une réponse avec les en-têtes suivants :
```
x-amz-lex-dialog-state:ElicitSlot
x-amz-lex-input-transcript:roses
x-amz-lex-intent-name:OrderFlowers
x-amz-lex-message:When do you want to pick up the roses?
x-amz-lex-session-attributes:e30=
x-amz-lex-slot-to-elicit:PickupDate
x-amz-lex-slots:eyJQaWNrdXBUaW1lIjpudWxsLCJGbG93ZXJUeXBlIjoicm9zaSdzIiwiUGlja3VwRGF0ZSI6bnVsbH0=
```
Les valeurs d'en-tête fournissent les informations suivantes :
+ `x-amz-lex-slots` – La version encodée en base 64 des options et valeurs :
```
{"PickupTime":null,"FlowerType":"roses","PickupDate":null}
```
+ `x-amz-lex-session-attributes` – La version encodée en base 64 des attributs de session (\$1\$1)
Le client lit le message audio dans le corps de réponse.
1. L'utilisateur dit : tomorrow
1. Le client (console) envoie la demande [PostContent](API_runtime_PostContent.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "audio/x-l16; sample-rate=16000; channel-count=1"
Accept: "audio/mpeg"
Request body
input stream ("tomorrow")
```
Le corps de la demande est le flux audio de l'entrée utilisateur (« tomorrow »). `sessionAttributes` reste vide.
1. Amazon Lex interprète le flux d'entrée dans le contexte de l'intention actuelle (il se souvient qu'il a demandé à cet utilisateur des informations relatives au `PickupDate` slot). Amazon Lex met à jour la valeur de slot (`PickupDate`) en fonction de l'intention actuelle. Il choisit ensuite une autre option pour laquelle obtenir une valeur (`PickupTime`) et l'une de ses invites d'obtention de valeur (When do you want to pick up the roses on 2017-03-18?), puis il renvoie une réponse avec les en-têtes suivants :
```
x-amz-lex-dialog-state:ElicitSlot
x-amz-lex-input-transcript:tomorrow
x-amz-lex-intent-name:OrderFlowers
x-amz-lex-message:When do you want to pick up the roses on 2017-03-18?
x-amz-lex-session-attributes:e30=
x-amz-lex-slot-to-elicit:PickupTime
x-amz-lex-slots:eyJQaWNrdXBUaW1lIjpudWxsLCJGbG93ZXJUeXBlIjoicm9zaSdzIiwiUGlja3VwRGF0ZSI6IjIwMTctMDMtMTgifQ==
x-amzn-RequestId:3a205b70-0b69-11e7-b447-eb69face3e6f
```
Les valeurs d'en-tête fournissent les informations suivantes :
+ `x-amz-lex-slots` – La version encodée en base 64 des options et valeurs :
```
{"PickupTime":null,"FlowerType":"roses","PickupDate":"2017-03-18"}
```
+ `x-amz-lex-session-attributes` – La version encodée en base 64 des attributs de session (\$1\$1)
Le client lit le message audio dans le corps de réponse.
1. L'utilisateur dit : 6 pm
1. Le client (console) envoie la demande [PostContent](API_runtime_PostContent.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "text/plain; charset=utf-8"
Accept: "audio/mpeg"
Request body
input stream ("6 pm")
```
Le corps de la demande est le flux audio de l'entrée utilisateur (« 6 pm »). `sessionAttributes` reste vide.
1. Amazon Lex interprète le flux d'entrée dans le contexte de l'intention actuelle (il se souvient qu'il a demandé à cet utilisateur des informations relatives au `PickupTime` slot). Il met d'abord à jour la valeur d'option pour l'intention actuelle.
Amazon Lex détecte désormais qu'il possède des informations pour tous les emplacements. Cependant, l'intention `OrderFlowers` est configurée avec un message de confirmation. Amazon Lex a donc besoin d'une confirmation explicite de la part de l'utilisateur avant de pouvoir réaliser son intention. Il envoie une réponse avec les en-têtes suivants, demandant une confirmation avant de commander les fleurs :
```
x-amz-lex-dialog-state:ConfirmIntent
x-amz-lex-input-transcript:six p. m.
x-amz-lex-intent-name:OrderFlowers
x-amz-lex-message:Okay, your roses will be ready for pickup by 18:00 on 2017-03-18. Does this sound okay?
x-amz-lex-session-attributes:e30=
x-amz-lex-slots:eyJQaWNrdXBUaW1lIjoiMTg6MDAiLCJGbG93ZXJUeXBlIjoicm9zaSdzIiwiUGlja3VwRGF0ZSI6IjIwMTctMDMtMTgifQ==
x-amzn-RequestId:083ca360-0b6a-11e7-b447-eb69face3e6f
```
Les valeurs d'en-tête fournissent les informations suivantes :
+ `x-amz-lex-slots` – La version encodée en base 64 des options et valeurs :
```
{"PickupTime":"18:00","FlowerType":"roses","PickupDate":"2017-03-18"}
```
+ `x-amz-lex-session-attributes` – La version encodée en base 64 des attributs de session (\$1\$1)
Le client lit le message audio dans le corps de réponse.
1. L'utilisateur dit : Yes
1. Le client (console) envoie la demande [PostContent](API_runtime_PostContent.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/content HTTP/1.1
x-amz-lex-session-attributes: "e30="
Content-Type: "audio/x-l16; sample-rate=16000; channel-count=1"
Accept: "audio/mpeg"
Request body
input stream ("Yes")
```
Le corps de la demande est le flux audio de l'entrée utilisateur (« Yes »). `sessionAttributes` reste vide.
1. Amazon Lex interprète le flux d'entrée et comprend que l'utilisateur souhaite poursuivre la commande. L'intention `OrderFlowers` est configurée avec `ReturnIntent` comme activité d'exécution. Cela demande à Amazon Lex de renvoyer toutes les données d'intention au client. Amazon Lex renvoie une réponse contenant les informations suivantes :
```
x-amz-lex-dialog-state:ReadyForFulfillment
x-amz-lex-input-transcript:yes
x-amz-lex-intent-name:OrderFlowers
x-amz-lex-session-attributes:e30=
x-amz-lex-slots:eyJQaWNrdXBUaW1lIjoiMTg6MDAiLCJGbG93ZXJUeXBlIjoicm9zaSdzIiwiUGlja3VwRGF0ZSI6IjIwMTctMDMtMTgifQ==
```
L'en-tête de réponse `x-amz-lex-dialog-state` est défini sur `ReadyForFulfillment`. Le client peut alors traiter l'intention.
1. A présent, retestez le bot. Pour établir un nouveau contexte (nouvel utilisateur), choisissez le lien **Effacer** dans la console. Fournissez des données pour l'intention `OrderFlowers` et incluez des données non valides. Par exemple :
+ 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
Notez que le bot accepte ces valeurs parce que vous n'avez pas de code pour initialiser et valider les données utilisateur. Dans la section suivante, vous allez ajouter une fonction Lambda à cet effet. Notez ce qui suit à propos de la fonction Lambda :
+ Elle valide les données d'option après chaque entrée utilisateur. Elle traite l'intention à la fin. Autrement dit, le bot traite la commande de fleurs et renvoie un message à l'utilisateur au lieu de simplement renvoyer les données d'option au client. Pour de plus amples informations, veuillez consulter [Utilisation des fonctions Lambda](using-lambda.md).
+ Elle définit également les attributs de session. Pour en savoir plus sur les attributs de session, consultez [PostText](API_runtime_PostText.md).
Une fois que vous avez terminé la section de mise en route, vous pouvez faire les exercices suivants ([Exemples supplémentaires : création de robots Amazon Lex](additional-exercises.md) ). [Réservez un voyage](ex-book-trip.md) utilise des attributs de session pour partager des informations entre les intentions afin d'engager une conversation dynamique avec l'utilisateur.
**Étape suivante**
[Étape 3 : Création d'une fonction Lambda (console)](gs-bp-create-lambda-function.md)
# Étape 2b (facultatif) : Vérification des détails du flux d'informations saisies (console)
Cette section décrit le flux d'informations entre le client et Amazon Lex dans lequel le client utilise l'API `PostText` pour envoyer des demandes. Pour de plus amples informations, veuillez consulter [PostText](API_runtime_PostText.md).
1. L'utilisateur tape : 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/4o9wwdhx6nlheferh6a73fujd3118f5w/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 ne comporte aucun crochet de code (c'est-à-dire les fonctions Lambda) pour l'initialisation et la validation des entrées ou du traitement des données par l'utilisateur.
Amazon Lex choisit l'un des emplacements de l'intention (`FlowerType`) pour obtenir la valeur. Il sélectionne aussi l'une des invites d'obtention de valeur pour l'option (toutes faisant partie de la configuration d'intention), puis il renvoie la réponse suivante au client. La console affiche le message dans la réponse à l'utilisateur.
![\[\]](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. L'utilisateur tape : roses
1. Le client (console) envoie la demande [PostText](API_runtime_PostText.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/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 a demandé à l'utilisateur concerné des informations sur le slot. `FlowerType` Amazon Lex met d'abord à jour la valeur de l'emplacement en fonction de l'intention actuelle, puis choisit un autre emplacement (`PickupDate`) avec l'un de ses messages d'invite : quel jour souhaitez-vous que les roses soient récupérées ? — `` pour le slot.
Amazon Lex renvoie ensuite la réponse suivante :
![\[\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-20.png)
Le client affiche le message dans la réponse.
1. L'utilisateur tape : tomorrow
1. Le client (console) envoie la demande [PostText](API_runtime_PostText.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/text
"Content-Type":"application/json"
"Content-Encoding":"amz-1.0"
{
"inputText": "tomorrow",
"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 a demandé à l'utilisateur concerné des informations sur le slot. `PickupDate` Amazon Lex met à jour la valeur de slot (`PickupDate`) en fonction de l'intention actuelle. Il choisit une autre option pour laquelle obtenir une valeur (`PickupTime`). Il renvoie l'une des questions d'identification de valeur : livrer les roses à quelle heure le 05/01/2017 ? — `` au client.
Amazon Lex renvoie ensuite la réponse suivante :
![\[\]](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.
1. L'utilisateur tape : 6 pm
1. Le client (console) envoie la demande [PostText](API_runtime_PostText.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/text
"Content-Type":"application/json"
"Content-Encoding":"amz-1.0"
{
"inputText": "6 pm",
"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 a demandé à l'utilisateur concerné des informations sur le slot. `PickupTime` Amazon Lex met d'abord à jour la valeur de l'emplacement en fonction de l'intention actuelle. Amazon Lex détecte désormais qu'il possède des informations pour tous les emplacements.
L'intention `OrderFlowers` est configurée avec un message de confirmation. Amazon Lex a donc besoin d'une confirmation explicite de la part de l'utilisateur avant de pouvoir réaliser son intention. Amazon Lex envoie le message suivant au client pour lui demander une confirmation avant de commander les fleurs :
![\[\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-40.png)
Le client affiche le message dans la réponse.
1. L'utilisateur tape : Yes
1. Le client (console) envoie la demande [PostText](API_runtime_PostText.md) suivante à Amazon Lex :
```
POST /bot/OrderFlowers/alias/$LATEST/user/4o9wwdhx6nlheferh6a73fujd3118f5w/text
"Content-Type":"application/json"
"Content-Encoding":"amz-1.0"
{
"inputText": "Yes",
"sessionAttributes": {}
}
```
Dans le corps de la demande, `inputText` fournit l'entrée utilisateur. `sessionAttributes` reste vide.
1. Amazon Lex interprète le `inputText` dans le contexte de la confirmation de l'intention actuelle. Il comprend que l'utilisateur souhaite continuer avec la commande. L'`OrderFlowers`intention est configurée `ReturnIntent` comme activité d'exécution (il n'existe aucune fonction Lambda pour répondre à l'intention). Par conséquent, Amazon Lex renvoie les données d'emplacement suivantes au client.
![\[\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs-1-details-50.png)
Amazon Lex a défini le `dialogState` paramètre sur`ReadyForFulfillment`. Le client peut alors traiter l'intention.
1. Maintenant, retestez le bot. Pour ce faire, vous devez choisir le lien **Effacer** dans la console pour établir un nouveau contexte (nouvel utilisateur). A présent, en fournissant des données pour l'intention de commande de fleurs, essayez de fournir des données non valides. Par exemple :
+ 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.
Notez que le bot accepte ces valeurs car vous n'avez aucun code pour les données initialize/validate utilisateur. Dans la section suivante, vous allez ajouter une fonction Lambda à cet effet. Notez ce qui suit à propos de la fonction Lambda :
+ La fonction Lambda valide les données du slot après chaque saisie par l'utilisateur. Elle traite l'intention à la fin. Autrement dit, le bot traite la commande de fleur et renvoie un message à l'utilisateur au lieu de simplement renvoyer des données d'option au client. Pour de plus amples informations, veuillez consulter [Utilisation des fonctions Lambda](using-lambda.md).
+ La fonction Lambda définit également les attributs de session. Pour en savoir plus sur les attributs de session, consultez [PostText](API_runtime_PostText.md).
Une fois que vous avez terminé la section de mise en route, vous pouvez faire les exercices suivants ([Exemples supplémentaires : création de robots Amazon Lex](additional-exercises.md) ). [Réservez un voyage](ex-book-trip.md) utilise des attributs de session pour partager des informations entre les intentions afin d'engager une conversation dynamique avec l'utilisateur.
**Étape suivante**
[Étape 3 : Création d'une fonction Lambda (console)](gs-bp-create-lambda-function.md)
# Étape 3 : Création d'une fonction Lambda (console)
Créez une fonction Lambda (à l'aide du **lex-order-flowers-python**plan) et effectuez un appel de test à l'aide d'exemples de données d'événement dans la console. AWS Lambda
Vous revenez à la console Amazon Lex et vous ajoutez la fonction Lambda comme crochet de code pour répondre à l'`OrderFlowers`objectif `OrderFlowersBot` que vous avez créé dans la section précédente.
**Pour créer une fonction Lambda (console)**
1. Connectez-vous à la AWS Lambda console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. Choisissez **Créer une fonction**.
1. Sur la page **Créer une fonction**, choisissez **Use a blueprint (Utiliser un plan)**. Tapez **lex-** dans la zone de texte du filtre, puis appuyez sur `Enter` pour rechercher et choisir le plan `lex-order-flowers-python`.
Les plans de fonction Lambda sont fournis à la fois dans Node.js et Python. Pour cet exercice, utilisez le modèle basé sur Python.
1. Sur la page **Basic information (Informations de base)**, effectuez les opérations suivantes.
+ Entrez le nom d'une fonction Lambda ()`OrderFlowersCodeHook`.
+ Pour le rôle d'exécution, choisissez **Create a new role with basic Lambda permissions**.
+ Laissez les autres valeurs par défaut.
1. Sélectionnez **Create function** (Créer une fonction).
1. Si vous utilisez une langue autre que l'anglais (États-Unis) (en-US), mettez à jour les noms d'intention comme décrit dans[Mettre à jour un plan pour un environnement régional spécifique](lex-lambda-blueprints.md#blueprint-update-locale).
1. Testez la fonction Lambda.
1. Choisissez **Select a test events (Sélectionner un événement de test)**, **Configure test event (Configurer un événement de test)**.
1. Choisissez **Lex-Order Flowers** dans la liste **Event template (Modèle d'événement)**. Cet exemple d'événement correspond au request/response modèle Amazon Lex (voir[Utilisation des fonctions Lambda](using-lambda.md)). Donnez un nom à l'événement de test (`LexOrderFlowersTest`).
1. Choisissez **Créer**.
1. Choisissez **Test** pour tester le hook de code.
1. Vérifiez que la fonction Lambda s'est correctement exécutée. Dans ce cas, la réponse correspond au modèle de réponse Amazon Lex.
**Étape suivante**
[Étape 4 : ajouter la fonction Lambda en tant que crochet de code (console)](gs-bp-create-integrate.md)
# Étape 4 : ajouter la fonction Lambda en tant que crochet de code (console)
Dans cette section, vous allez mettre à jour la configuration de l' OrderFlowersintention d'utiliser la fonction Lambda comme suit :
+ Utilisez d'abord la fonction Lambda comme crochet de code pour réaliser l'`OrderFlowers`intention. Vous testez le bot et vérifiez que vous avez reçu un message d'expédition de la part de la fonction Lambda. Amazon Lex n'invoque la fonction Lambda qu'une fois que vous avez fourni les données relatives à tous les emplacements requis pour commander des fleurs.
+ Configurez la même fonction Lambda en tant que crochet de code pour effectuer l'initialisation et la validation. Vous testez et vérifiez que la fonction Lambda effectue la validation (lorsque vous fournissez des données d'emplacement).
**Pour ajouter une fonction Lambda en tant que crochet de code (console)**
1. Dans la console Amazon Lex, sélectionnez le **OrderFlowers**bot. La console indique l'**OrderFlowers**intention. Assurez-vous que la version d'intention est définie sur `$LATEST`, car c'est la seule version que nous pouvons modifier.
1. Ajoutez la fonction Lambda comme crochet du code d'expédition et testez-la.
1. Dans l'éditeur, choisissez la **AWS Lambda fonction** **Fulfillment**, puis sélectionnez la fonction Lambda que vous avez créée à l'étape précédente ()`OrderFlowersCodeHook`. Cliquez **sur OK** pour autoriser Amazon Lex à appeler la fonction Lambda.
Vous configurez cette fonction Lambda en tant que crochet de code pour répondre à l'objectif. Amazon Lex n'invoque cette fonction qu'après avoir reçu toutes les données de créneau nécessaires de la part de l'utilisateur pour répondre à son intention.
1. Spécifiez un **message de fin de conversation**.
1. Sélectionnez **Créer**.
1. Testez le bot à l'aide de la conversation précédente.
La dernière déclaration « Merci, votre commande de roses... » est une réponse de la fonction Lambda que vous avez configurée en tant que crochet de code. Dans la section précédente, il n'y avait aucune fonction Lambda. Vous utilisez maintenant une fonction Lambda pour réellement répondre à l'`OrderFlowers`intention.
1. Ajoutez la fonction Lambda en tant que crochet de code d'initialisation et de validation, puis testez.
L'exemple de code de fonction Lambda que vous utilisez peut à la fois valider et exécuter les saisies par l'utilisateur. L'événement d'entrée que reçoit la fonction Lambda comporte un champ (`invocationSource`) que le code utilise pour déterminer la partie du code à exécuter. Pour de plus amples informations, veuillez consulter [Format d'événement et de réponse d'entrée de la fonction Lambda](lambda-input-response-format.md).
1. Sélectionnez la dernière version (\$1LATEST) de l'intention `OrderFlowers`. C'est la seule version que vous pouvez mettre à jour.
1. Dans l'éditeur, choisissez **Initialization and validation** dans **Options**.
1. Sélectionnez à nouveau la même fonction Lambda.
1. Sélectionnez **Créer**.
1. Testez le bot.
Vous êtes maintenant prêt à converser avec Amazon Lex, comme indiqué dans l'image suivante. Pour tester la partie validation, choisissez l'heure 18 h, et votre fonction Lambda renvoie une réponse (« Nos heures d'ouverture sont de 10 h à 17 h ») et vous invite à nouveau. Une fois que vous avez fourni toutes les données d'emplacement valides, la fonction Lambda exécute la commande.
![\[\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/OrderFlowers-FullLambda.png)
**Étape suivante**
[Étape 5 (facultatif) : Vérification des détails du flux d'informations (console)](gs-bp-details-after-lambda.md)
# É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 :
![\[\]](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 :
![\[\]](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 :
![\[\]](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 :
![\[\]](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 :
![\[\]](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)
# Étape 6 : Mise à jour de la configuration de l'intention pour ajouter un énoncé (console)
Le bot `OrderFlowers` est configuré avec seulement deux énoncés. Cela fournit des informations limitées permettant à Amazon Lex de créer un modèle d'apprentissage automatique qui reconnaît les intentions de l'utilisateur et y répond. Essayez de taper « Je veux commander des fleurs », comme dans la fenêtre de test suivante. Amazon Lex ne reconnaît pas le texte et répond par « Je ne vous ai pas compris, que voudriez-vous faire ? » Vous pouvez améliorer le modèle d'apprentissage machine en y ajoutant davantage d'énoncés.
![\[La fenêtre de test indique un énoncé manqué.\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs1-120.png)
Chaque énoncé que vous ajoutez fournit à Amazon Lex davantage d'informations sur la manière de répondre à vos utilisateurs. Il n'est pas nécessaire d'ajouter un énoncé exact, Amazon Lex généralise à partir des exemples que vous fournissez pour reconnaître à la fois les correspondances exactes et les entrées similaires.
**Pour ajouter un énoncé (console)**
1. Ajoutez l'énoncé « Je veux des fleurs » à l'intention en le saisissant dans la section **Exemples d'énoncés** de l'éditeur d'intention, comme dans l'image suivante, puis en cliquant sur l'icône plus à côté du nouvel énoncé.
![\[Éditeur d'intention avec le nouvel énoncé.\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs1-130.png)
1. Compilez le bot pour qu'il applique les modifications apportées. Choisissez **Création**, puis**Création** à nouveau.
1. Testez le bot pour confirmer qu'il reconnaît le nouvel énoncé. Dans la fenêtre de test, comme dans l'image suivante, tapez « Je souhaite commander des fleurs ». Amazon Lex reconnaît la phrase et répond par « Quel type de fleurs souhaitez-vous commander ? ».
![\[L'éditeur d'intention reconnaît le nouvel énoncé.\]](http://docs.aws.amazon.com/fr_fr/lex/latest/dg/images/gs1-140.png)
**Étape suivante**
[Étape 7 (facultatif) : Nettoyage (console)](gs-bp-cleaning-up.md)
# Étape 7 (facultatif) : Nettoyage (console)
Supprimez à présent les ressources que vous avez créées et nettoyez votre compte.
Vous pouvez supprimer uniquement les ressources qui ne sont pas en cours d'utilisation. En règle générale, vous devez supprimer les ressources dans l'ordre suivant :
+ Supprimer les bots pour libérer les ressources d'intention.
+ Supprimer les intentions pour libérer les ressources de type d'option.
+ Supprimer les types d'option en dernier.
**Pour nettoyer votre compte (console)**
1. Connectez-vous à la console Amazon Lex AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/).
1. Dans la liste des robots, cochez la case à côté de **OrderFlowers**.
1. Pour supprimer le bot, choisissez **Supprimer**, puis **Continuer** dans la boîte de dialogue de confirmation.
1. Dans le volet de gauche, choisissez **Intents**.
1. Dans la liste des intentions, choisissez **OrderFlowersIntent**.
1. Pour supprimer l'intention, choisissez **Supprimer**, puis **Continuer** dans la boîte de dialogue de confirmation.
1. Dans le volet de gauche, choisissez **Slot types**.
1. Dans la liste des types d'options, choisissez **Flowers**.
1. Pour supprimer le type d'option, choisissez **Supprimer**, puis **Continuer** dans la boîte de dialogue de confirmation.
Vous avez supprimé toutes les ressources Amazon Lex que vous avez créées et nettoyé votre compte. Si vous le souhaitez, vous pouvez utiliser la [console Lambda](https://console.aws.amazon.com/lambda) pour supprimer la fonction Lambda utilisée dans cet exercice.