Cómo configurar un entorno de pruebas local para las Skills de Alexa | 2 de 2
Este artículo es la continuación del post original con el mismo nombre que puedes encontrar en este enlace.
Creación del grupo y usuario de pruebas
Como mencionaba anteriormente, es necesario definir un grupo y un usuario de pruebas locales. Este proceso se realiza igualmente en el servicio IAM de AWS. El procedimiento recomendado para la creación de estos nuevos elementos es el siguiente:
1- El Grupo
En la consola de AWS es necesario ubicar el servicio IAM en la sección de Seguridad.
Ir a la opción “Groups” y crear un grupo nuevo. El primer paso de la creación del grupo implica asignar un nombre. En mi caso, he llamado a mi grupo localAlexaDebugging. El segundo paso requiere asociar políticas al grupo. En este caso he asociado AmazonDynamoDBFullAccess y CloudWatchLogsFullAccess.
En el ejemplo anterior he elegido unas políticas más amplias de las que realmente necesito para mi Skill actual. Estoy asumiendo que probablemente tendré otros usuarios como parte del grupo de pruebas que puedan necesitar políticas un poco más flexibles.
2- El Usuario
En la misma sección de la consola de AWS realizaremos el proceso de cuatro pasos para crear el nuevo usuario y asignarlo al grupo adecuado.
En primer lugar procedemos a asignar un nombre al usuario y nos aseguramos de indicar que el tipo de acceso otorgado será programático.
El siguiente paso consiste en asignar el usuario al grupo que hemos creado en el paso anterior. De este modo el usuario heredará los permisos que hemos asignado al grupo.
Luego procedemos a verificar los datos y confirmar la creación del usuario de pruebas.
Finalmente — y como hemos indicado que daremos al usuario acceso programático — nos aseguramos de descargar el archivo “credentials.csv” creado automáticamente por el sistema. En este fichero tendremos datos sensibles (AWS Access Key y AWS Secret Key) necesarios para la conexión segura desde el equipo local de pruebas.
Es necesario, una vez creado el usuario, copiar y guardar el valor del ARN del usuario (no del grupo) para su uso posterior.
3- El Accesso “Assume Role”
Una vez creados el grupo y el usuario, es necesario otorgar al usuario la política conocida dentro de IAM como Assume Role. Esta política le garantiza al usuario la posibilidad de heredar el rol básico de ejecución que hemos creado para la función Lambda.
Para realizar este proceso debemos ir a la opción Roles del menú principal, seleccionar nuestro rol creado previamente y activar la pestaña Trust relationships para poder editar las relaciones de confianza.
En el editor debemos agregar una línea adicional y pegar el valor del ARN del usuario que hemos copiado al final del paso 2.
Una vez actualizada la política podremos observar que nuestro usuario de pruebas local ha sido añadido a las entidades de confianza del rol de ejecución.
En este momento es necesario copiar el valor ARN del rol (no del usuario o del grupo) para incluirlo en nuestro fichero “main.js” en la línea #18 del ejemplo. La línea correspondiente a la variable roleArn.
En este paso también es posible aprovechar y asignar el valor correcto a la variable region, justo debajo de roleArn. Posiblemente, dependiendo del fichero de ejemplo que se esté utilizando, el valor de esta variable sea ‘us-east-1’ y para el caso de Europa, la región correspondiente es realmente ‘eu-west-1’.
Configuración con las llaves AWS para el entorno de pruebas
Una vez finalizada la actualización de los valores correspondientes a las variables roleArn y region, debemos configurar el entorno local de línea de comandos ASW CLI con las credenciales descargadas en el paso 2 de la sección anterior.
En el terminal interno de Visual Studio ejecutamos el comando “aws configure” y procedemos a introducir los datos solicitados, copiando y pegando desde el fichero “credentials.csv.”
Adicionalmente a las llaves de acceso, debemos confirmar los valores por defecto de nuestra región y formato de salida. En este caso “eu-west-1” y “json”. Estos dos últimos valores se confirmarán solo la primera vez que se realice el proceso. En ocasiones posteriores simplemente se confirmará que siguen siendo las opciones por defecto deseadas.
Adaptar “input.json” para tu Skill de Alexa
Para que las pruebas puedan funcionar es necesario editar el fichero input.json de modo que contenga los datos reales asociados con nuestra Skill de Alexa. Los datos básicos necesarios son:
- session.application.applicationId
- user.userId
- request.intent.name
Vamos a ver un poco más en detalle como podemos modificar estos valores para realizar pruebas simples con nuestro Skill desde el entorno local.
session.application.applicationId
Para obtener el primer valor solicitado (applicationId) debemos dirigirnos a la consola de desarrolladores de Amazon Alexa y seleccionar la opción Endpoint del menú bajo la pestaña Build de la Skill. Justo debajo de la sección Service Endpoint Type ubicarás el ID de tu aplicación/skill.
user.userId
Este valor realmente no necesita tener ningún formato específico y puede ser creado en el momento para las pruebas básicas de este ejemplo. Es importante recordar que a través de este valor Alexa identifica cuentas asociadas a un dispositivo. En el caso de estar almacenando valores de un usuario en particular, sería necesario cambiar el valor para simular diferentes usuarios en diferentes escenarios.
Para obtener más información sobre el formato necesario para el valor de userId puedes visitar la página oficial de referencia del ASK (Alexa Skills Kit).
Para mis pruebas he utilizado el valor que genera la consola Skill I/O del simulador de Alexa, ubicado en la ventana JSON Input de la consola de desarrolladores.
request.intent.name
El caso más básico para cualquier Skill que creemos probablemente será el LaunchIntent. Este Intent nos permite comprobar que nuestra Skill está siendo convocada correctamente.
Para realizar la prueba básica de lanzamiento de nuestro Skill y depurar cualquier posible problema, es necesario realizar una configuración inicial del depurador que consiste en:
1- Ir a la sección Debug de Visual Studio.
2- Generar el archivo de configuración (sólo la primera vez).
3- Configurar la ruta correcta para ubicar el fichero main.js.
Con esta configuración inicial estamos listos para realizar la primera prueba local de nuestra Skill de Alexa.
Como en todo entorno de depuración, es necesario indicar al sistema donde queremos detenernos para examinar más de cerca. En este ejemplo he creado un breakpoint inicial en la línea #38 de mi fichero index.js y verificar que se están tomando todas las preguntas correctamente de mi fichero local questions.js.
Como podemos ver en la imagen, el entorno de pruebas funciona correctamente. La llamada a mi Skill se ha realizado correctamente y el breakpoint me permite detenerme a observar los valores actuales de mis variables (en el panel a la izquierda). A su vez he aprovechado para agregar algunas estructuras de datos a la sección WATCH, y así poder hacer un seguimiento más de cerca de las variables que me interesa observar.
Al igual que sucede en cualquier entorno de pruebas en un IDE moderno, es posible controlar la ejecución del programa con los típicos controles para continuar, detener, saltar o reiniciar la ejecución.
El siguiente paso lógico es empezar a experimentar con distintos tipos de eventos y depurar los casos más complejos de nuestra Skill.
Jugar con el contenido de input.json nos permite probar de forma programática cada uno de los Intents que hemos configurado para nuestra Skill. Dicho esto, tener que editar el contenido de este archivo cada vez que queremos hacer una prueba distinta puede llegar a ser una tarea tediosa. Mucho más interesante sería poder hacer tests de regresión a un grupo de archivos de este tipo. Cada uno con una prueba diferente.
La consola de desarrolladores tiene información útil sobre como realizar pruebas desde la pestaña Test para nuestra Skill de Alexa, pero vamos a entrar en detalle sobre como podemos usar una característica en particular para generar fácilmente el código de los casos de prueba.
En mi Skill de ejemplo, luego del Intent inicial utilizado para invocar el Test de Nacionalidad Española (y así generar la primera pregunta del examen), el Intent destinado a gestionar una respuesta del usuario (AnwerIntent) es el siguiente más relevante, y el que me interesa depurar cuando realizo cambios en la lógica de mi función Lambda.
La forma más sencilla de generar un fichero JSON de entrada es utilizando el Simulador de Alexa en la pestaña de pruebas, escribir una respuesta, y copiar el contenido de JSON Input.
El siguiente paso es crear un archivo adicional, al que en este caso he llamado answer.json, y pegar el contenido copiado de la consola para realizar la prueba.
Una vez creado el fichero para la nueva prueba solo queda modificar main.js para configurar el evento que deseamos depurar y repetir el proceso que realizamos anteriormente con input.json.
Una vez configurados los nuevos breakpoints de interés y ejecutado el depurador podemos detenernos y observar los distintos valores que nuestra interacción con el AnswerIntent está devolviendo.
Este mismo proceso puede ser repetido tantas veces sea necesario con ficheros de datos locales y sin poner en riesgo el código existente en nuestro entorno de producción. Una vez realizadas todas las pruebas, podemos actualizar sin problemas nuestra función Lambda de producción con los errores corregidos o las nuevas funcionalidades de nuestra Skill.
¿Y qué sucede con el Objeto Context?
A este punto es probable que hayas notado que de momento no hemos tocado para nada uno de los tres archivos iniciales requeridos para la prueba: context.json. Este archivo contiene la información necesaria para configurar el contexto en el cual se ejecuta nuestra función Lambda.
Para el caso de ejemplo que estamos utilizando no es necesario editar este fichero con datos adicionales, aunque siempre es necesario contar con él para poder crear el objeto context desde el fichero main.js.
Es posible conseguir más información relacionada al objeto context de Node.js en la página oficial de AWS Lambda de Amazon.
Reflexiones y Comentarios Finales
- La introducción de una nueva plataforma de voz como Alexa trae consigo innumerables oportunidades para crear soluciones basadas en un paradigma distinto: la voz.
- Personalmente me encanta la idea de poder enfocarme en diseñar para la voz y proveer valor basado en funcionalidad. El no tener que competir en el plano de diseño visual es un gran alivio para los que no tenemos el talento y las dotes gráficas de primer nivel.
- De la misma forma, esta nueva familia de productos representa un cambio en la forma en la que desarrollamos aplicaciones tradicionalmente, obligándonos a buscar formas creativas para adaptar nuestro entorno y procesos a las necesidades que dictan los fabricantes.
- La arquitectura serverless está aquí para quedarse. La tendencia gira rápidamente hacia los contenedores efímeros aún cuando sabemos que las técnicas de micro-servicios y contenedores apenas se están adoptando en algunos entornos. El mundo BaaS se mueve rápido y Amazon, con servicios como Alexa, quiere llevar la batuta.
- Contar con un entorno seguro de pruebas es un requerimiento básico para todo equipo de desarrollo. Las funciones Lambda de Amazon se encuentran disponibles directamente en producción y realizar cambios “en caliente” es una terrible opción si queremos garantizar que la experiencia del usuario sea la mejor posible.
- Quizás Amazon en el futuro cercano nos permita tener una versión DEV de nuestra función Lambda para realizar pruebas directamente en sus servidores sin afectar al usuario final. Algo similar a lo que podemos hacer hoy fácilmente en el desarrollo de aplicaciones web o móviles con distintas técnicas de profiling.
- Tutoriales en inglés muy valiosos — en algún caso alguno un poco desactualizado — que me han servido para aprender estas técnicas, así como crear este tutorial se pueden encontrar en el blog oficial de Amazon y en el canal de YouTube de SleepyDevelopers.
Todos los comentarios, mejoras a las soluciones propuestas y feedback en general son siempre bienvenid@s.
Gracias por leer,
Juan.
Diseñando para la Voz es una iniciativa personal de Juan González Ponce que trae contenido relacionado al mundo del desarrollo de Alexa Skills para el servicio de Amazon, en Castellano, con la finalidad de compartir ideas y lecciones aprendidas en el camino.
