Si vous utilisez Amazon Lex V2, consultez plutôt le guide Amazon Lex V2.

Si vous utilisez Amazon Lex V1, nous vous recommandons de mettre à niveau vos robots vers Amazon Lex V2. Nous n'ajoutons plus de nouvelles fonctionnalités à la V1 et recommandons vivement d'utiliser la V2 pour tous les nouveaux robots.

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'PostContentAPI, consultezÉtape 2a (facultatif) : Vérification des détails du flux d'informations vocales (console) .

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.

Utilisateur : I would like to order some flowers.
1. Le client (console) envoie la demande PostText 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.
2. À partir duinputText, 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.
  
  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.
3. 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.
  
  Notez ce qui suit :
  - dialogAction.type— En définissant cette valeur surDelegate, 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.
4. Selon ledialogAction.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 :
  
  Le client affiche le message dans la réponse.
Utilisateur : roses
1. Le client envoie la PostText 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.
2. 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 mis à jour le FlowerType slot en roses.
3. Selon la invocationSource valeur deDialogCodeHook, 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.
4. Selon ledialogAction.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 ramassées ? » —pour cet emplacement en fonction de la configuration d'intention, puis renvoie la réponse suivante au client :
  
  Le client affiche simplement le message dans la réponse – « What day do you want the roses to be picked up? ».
Utilisateur : tomorrow
1. Le client envoie la PostText 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.
2. 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.
3. Selon la invocationSource valeur deDialogCodeHook, la fonction Lambda effectue la validation des données utilisateur. Il reconnaît que la valeur de l'PickupDateemplacement 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.
4. Selon ledialogAction.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 :
  
  Le client affiche le message dans la réponse : « Livrez les roses à quelle heure le 05/01/2017 ? »
Utilisateur : 4 pm
1. Le client envoie la PostText 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.
2. 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.
3. Selon la invocationSource valeur deDialogCodeHook, la fonction Lambda effectue la validation des données utilisateur. Il reconnaît que la valeur de l'PickupDateemplacement 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.
4. À 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 :
  
  Le client affiche simplement le message dans la réponse et attend la réponse de l'utilisateur.
Utilisateur : Yes
1. Le client envoie la PostText 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"
    }
}
```
2. 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 surFulfillmentCodeHook, demandant à la fonction Lambda de répondre à l'intention.
  - confirmationStatus – Est défini sur Confirmed.
3. Cette fois, la fonction Lambda répond à l'OrderFlowersintention 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 surClose, 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.
4. Amazon Lex examine le fulfillmentState et renvoie la réponse suivante au client.
  
  Amazon Lex renvoie ensuite ce qui suit au client :
  
  Remarque :
  - dialogState— Amazon Lex définit cette valeur surfulfilled.
  - message— est le même message que celui fourni par la fonction Lambda.
  Le client affiche le message.
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)

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Étape 4 : ajouter la fonction Lambda en tant que crochet de code (console)

Étape 6 : Mise à jour de la configuration de l'intention pour ajouter un énoncé (console)