Paso 5 (opcional): revisión de los detalles del flujo de información (consola) - Amazon Lex V1

Si utiliza Amazon Lex V2, consulte la guía de Amazon Lex V2.

 

Si utiliza Amazon Lex V1, le recomendamos que actualice los bots a Amazon Lex V2. Hemos dejado de agregar nuevas características a V1, por lo que recomendamos encarecidamente utilizar V2 para todos los nuevos bots.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Paso 5 (opcional): revisión de los detalles del flujo de información (consola)

En esta sección se explica el flujo de información entre el cliente y Amazon Lex para cada entrada del usuario, incluida la integración de la función de Lambda.

nota

En esta sección se supone que el cliente envía solicitudes a Amazon Lex mediante la API en tiempo de ejecución PostText y se muestran los detalles correspondientes de la solicitud y la respuesta. Para ver un ejemplo de flujo de información entre el cliente y Amazon Lex en el que el usuario usa la API PostContent, consulte Paso 2a (opcional): revisión de los detalles del flujo de información escrita (consola) .

Para obtener más información sobre la API en tiempo de ejecución PostText y detalles adicionales sobre las solicitudes y las respuestas que se muestran en los siguientes pasos, consulte PostText.

  1. Usuario: Me gustaría pedir unas flores.

    1. El cliente (la consola) envía la siguiente solicitud PostText a 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": {} }

      Tanto la URI de la solicitud como el cuerpo proporcionan información a Amazon Lex:

      • URI de la solicitud: proporciona el nombre del bot (OrderFlowers), el alias del bot ($LATEST) y el nombre de usuario (una cadena aleatoria que identifica al usuario). El text de cola indica que se trata de una solicitud de API PostText (no PostContent).

      • Cuerpo de la solicitud: incluye la entrada del usuario (inputText). No hay sessionAttributes. Cuando el cliente realiza la primera solicitud, no existen atributos de la sesión. La función Lambda los inicia más adelante.

    2. Amazon Lex deduce la intención (OrderFlowers) a partir de inputText. Esta intención está configurada con una función de Lambda como enlace de código para las tareas de inicialización y validación de los datos del usuario. Por ello, Amazon Lex invoca la función de Lambda mediante la transferencia de la siguiente información como datos de eventos:

      { "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" } }

      Para obtener más información, consulte Formato del evento de entrada.

      Además de la información que envía el cliente, Amazon Lex también incluye los siguientes datos adicionales:

      • messageVersion: actualmente Amazon Lex solo es compatible con la versión 1.0.

      • invocationSource: indica la finalidad de invocar la función de Lambda. En este caso, es para inicializar y validar los datos del usuario. En este punto, Amazon Lex sabe que el usuario no ha proporcionado todos los datos de ranura necesarios para cumplir la intención.

      • Información de currentIntent con todos los valores de slot establecidos en nulos.

    3. En este momento, todos los valores de slot son nulos. La función de Lambda no tiene que validar nada y devuelve la siguiente respuesta a Amazon Lex:

      { "sessionAttributes": {}, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": null, "PickupDate": null } } }

      Para obtener más información sobre el formato de la respuesta, consulte Formato de respuesta.

      Tenga en cuenta lo siguiente:

      • dialogAction.type: al establecer este valor en Delegate, la función de Lambda delega la responsabilidad de decidir el siguiente procedimiento a Amazon Lex.

        nota

        Si la función de Lambda detecta algo en la validación de los datos de usuario, indica a Amazon Lex el siguiente paso, tal como se muestra a continuación.

    4. De acuerdo con dialogAction.type, Amazon Lex decide cómo continuar. Puesto que ninguno de los slots tiene información, decide obtener el valor del slot FlowerType. Selecciona una de las preguntas para obtener valores para el slot ("¿Qué tipo de flores le gustaría pedir?") y envía la siguiente respuesta al cliente:

      Datos JSON que contienen una solicitud para el slot FlowerType.

      El cliente muestra el mensaje en la respuesta.

  2. Usuario: rosas

    1. El cliente envía la siguiente solicitud PostText a Amazon Lex:

      POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "roses", "sessionAttributes": {} }

      En el cuerpo de la solicitud, inputText proporciona la entrada del usuario. No hay sessionAttributes.

    2. Amazon Lex interpreta primero inputText en el contexto de la confirmación de la intención actual. El servicio recuerda que ha solicitado al usuario específico información acerca del slot FlowerType. Actualiza el valor de la ranura para la intención actual e invoca la función de Lambda con los siguientes datos de evento:

      { "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" } }

      Tenga en cuenta lo siguiente:

      • invocationSource: sigue siendo DialogCodeHook (simplemente validamos los datos de usuario).

      • currentIntent.slots: Amazon Lex ha actualizado la ranura FlowerType con “roses”.

    3. Al establecer el valor invocationSource como DialogCodeHook, la función de Lambda valida los datos del usuario. Reconoce roses como un valor de ranura válido (y establece Price como atributo de la sesión) y devuelve la siguiente respuesta a Amazon Lex.

      { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": null } } }

      Tenga en cuenta lo siguiente:

      • sessionAttributes: la función de Lambda ha agregado Price (de las rosas) como un atributo de la sesión.

      • dialogAction.type: se establece en Delegate. Los datos del usuario son válidos, por lo que la función de Lambda indica a Amazon Lex que decida el siguiente paso.

       

    4. Amazon Lex elige el siguiente paso en función de dialogAction.type. Amazon Lex sabe que necesita más datos de ranura, de modo que elige la siguiente ranura vacía (PickupDate) con la mayor prioridad según la configuración de la intención. Amazon Lex selecciona uno de los mensajes de pregunta ("¿Qué día desea recoger las rosas?") para esta ranura, según la configuración de la intención y, a continuación, envía esta respuesta al cliente:

      Datos JSON enviados al cliente para solicitar el slot PickupData .

      El cliente simplemente muestra el mensaje en la respuesta: "¿Qué día desea recoger las rosas?."

  3. Usuario: mañana

    1. El cliente envía la siguiente solicitud PostText a Amazon Lex:

      POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "tomorrow", "sessionAttributes": { "Price": "25" } }

      En el cuerpo de la solicitud, inputText proporciona la entrada del usuario y el cliente devuelve los atributos de la sesión al servicio.

    2. Amazon Lex recuerda el contexto; es decir, que está obteniendo datos para la ranura PickupDate. En este contexto, sabe que el valor de inputText es para el slot PickupDate. A continuación, Amazon Lex llama la función de Lambda mediante el envío de los siguientes eventos:

      { "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 ha actualizado currentIntent.slots al establecer el valor PickupDate. Además, tenga en cuenta que el servicio pasa sessionAttributes tal cual a la función de Lambda.

    3. Al establecer el valor invocationSource como DialogCodeHook, la función de Lambda valida los datos de usuario. Reconoce que el valor de la ranura PickupDate es válido y devuelve la siguiente respuesta a Amazon Lex:

      { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": "2017-01-05" } } }

      Tenga en cuenta lo siguiente:

      • sessionAttributes: sin cambios.

      • dialogAction.type: se establece en Delegate. Los datos del usuario son válidos, por lo que la función de Lambda indica a Amazon Lex que decida el siguiente paso.

    4. Amazon Lex elige el siguiente paso en función de dialogAction.type. Amazon Lex sabe que necesita más datos de ranura, de modo que elige la siguiente ranura vacía (PickupTime) con la mayor prioridad según la configuración de la intención. Amazon Lex selecciona uno de los mensajes de pregunta (“¿A qué hora quiere que se entreguen las rosas el 05/01/2017?”) para esta ranura, según la configuración de la intención y, a continuación, envía esta respuesta al cliente:

      Datos JSON para solicitar el slot PickupTime.

      El cliente muestra el mensaje en la respuesta: “¿A qué hora quiere que entreguen las rosas el 05/01/2017?”.

  4. Usuario: 16:00 h

    1. El cliente envía la siguiente solicitud PostText a 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" } }

      En el cuerpo de la solicitud, inputText proporciona la entrada del usuario. El cliente pasa los sessionAttributes en la solicitud.

    2. Amazon Lex entiende el contexto. Entiende que estaba obteniendo datos para el slot PickupTime. En este contexto, sabe que el valor inputText es para la ranura PickupTime. A continuación, Amazon Lex llama la función de Lambda mediante el envío de los siguientes eventos:

      { "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 ha actualizado currentIntent.slots al establecer el valor PickupTime.

    3. Al establecer el valor invocationSource como DialogCodeHook, la función de Lambda valida los datos del usuario. Reconoce que el valor de la ranura PickupDate es válido y devuelve la siguiente respuesta a Amazon Lex.

      { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" } } }

      Tenga en cuenta lo siguiente:

      • sessionAttributes: sin cambios en el atributo de la sesión.

      • dialogAction.type: se establece en Delegate. Los datos del usuario son válidos, por lo que la función de Lambda indica a Amazon Lex que decida el siguiente paso.

    4. En este punto, Amazon Lex sabe que dispone de todos los datos de ranura. Esta intención se ha configurado con un mensaje de confirmación. Por lo tanto, Amazon Lex envía la siguiente respuesta al usuario para solicitar su confirmación antes de cumplir con la intención:

      Datos JSON para pedir la confirmación del pedido.

      El cliente simplemente muestra el mensaje en la respuesta y espera la respuesta del usuario.

  5. Usuario: Sí

    1. El cliente envía la siguiente solicitud PostText a 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 interpreta inputText en el contexto de la confirmación de la intención actual. Amazon Lex entiende que el usuario desea continuar con el pedido. Esta vez, Amazon Lex invoca la función de Lambda para cumplir la intención mediante el envío del siguiente evento, que establece invocationSource en FulfillmentCodeHook en el caso de que se envíe a la función. Amazon Lex también establece confirmationStatus en 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" } }

      Tenga en cuenta lo siguiente:

      • invocationSource: esta vez, Amazon Lex configura este valor como FulfillmentCodeHook, por lo que indica a la función de Lambda que cumpla con la intención.

      • confirmationStatus: se establece en Confirmed.

    3. Esta vez, la función de Lambda cumple con la intención OrderFlowers y devuelve la siguiente respuesta:

      { "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" } } }

      Tenga en cuenta lo siguiente:

      • Establece dialogAction.type: la función de Lambda establece este valor en Close para que Amazon Lex no espere una respuesta del usuario.

      • dialogAction.fulfillmentState: se establece en Fulfilled e incluye un message adecuado para transmitir al usuario.

    4. Amazon Lex analiza fulfillmentState y envía la siguiente respuesta de vuelta al cliente:

      A continuación, Amazon Lex devuelve lo siguiente al cliente:

      Datos JSON para la pregunta de confirmación.

      Tenga en cuenta que:

      • dialogState: Amazon Lex establece este valor en fulfilled.

      • message: es el mismo mensaje que ha proporcionado la función de Lambda.

      El cliente muestra el mensaje.

  6. Ahora vuelva a probar el bot. Para establecer un nuevo contexto (usuario), elija el enlace Clear en la ventana de prueba. Ahora proporcione datos de slot no válidos para la intención OrderFlowers. Esta vez, la función de Lambda valida los datos, restablece el valor de los datos de ranura no válidos en nulo y pide a Amazon Lex que solicite al usuario datos válidos. Por ejemplo, pruebe lo siguiente:

    • Jazmín como tipo de flor (este tipo de flor no se admite).

    • Ayer como el día en que desea recoger las flores.

    • Después de realizar el pedido, escriba otro tipo de flores en lugar de responder "sí" para confirmar el pedido. Como respuesta, la función de Lambda actualiza Price en el atributo de la sesión y mantiene un recuento actual de los pedidos de flores.

    La función de Lambda también lleva a cabo la actividad de cumplimiento.

Paso siguiente

Paso 6: actualización de la configuración de la intención para añadir un enunciado (consola)