En el anterior post conté cómo crear el skill y su interaction model usando la Alexa Developer Console. Con esa parte tenemos construida la interfaz de voz con la cual va a interactuar un usuario. Ahora tenemos que conectar esa parte "cliente" con un endpoint, que tendrá el conocimiento necesario para manejar las peticiones que nos lleguen. Eso es lo que veremos en este post.

AWS Lambda

Hasta ahora había escuchado mucho sobre serverless y algo había leído pero no había jugado con nada. Esta era la oportunidad perfecta ya que los skills de Alexa se integran a las mil maravillas con un AWS Lambda. Puedes elegir un web service propio por HTTP pero yo quería algo simple y, de paso, aprender algo sobre esto de serverless.

Para poder configurar el endpoint del skill desde la consola primero tendrás que crear la lambda. Sobre AWS Lambda hay mucha documentación porque no es nada nuevo y se usa para otras muchas cosas pero yo, sin leer demasiado, pude crear lo necesario para el skill. Además con la opción gratis tenemos más que suficiente para lo que queremos.

Os recomiendo varios recursos:

• La charla de Iván de la Commit Conf 2018 donde hace un repaso de lo necesario para poner la lambda a punto.
• El post de Javier Campos sobre cómo gestionar tu lambda para su evolución con versionado. Ya me hubiera gustado haberlo leído a mí al empezar porque no fui muy cuidadoso. Ahora me he creado una lambda nueva para futuras certificaciones de mi skill y ya lo tengo más organizado con versiones y alias.
• La charla de German, Amazon Alexa Evangelist, donde cuenta también la creación de un skill con AWS Lambda pero con Node.js

Yo voy a repetir algunas cosas con capturas y sin muchos detalles para mostrar todos los pasos.

Configuración básica de la lambda

Lo primero que tenemos que hacer es crear la lambda desde la consola correspondiente.

En mi caso elegí Java 8 como runtime pero puedes elegir entre muchos otros como Node.js, Python, Go... Recordad que Java 8 es sólo un runtime pero no estamos forzamos a usar Java sino que podemos usar otras alternativas como Kotlin o Groovy. Acabaré migrando lo que hice en Java 8 a Kotlin y lo contaré por si resulta útil.

Con respecto al role, yo creé uno propio básico. Aquí la verdad que no lo tenía muy claro y opté por ahí pero quizás haya alguno predefinido que ya sea válido. Mi role lo único que tiene es el acceso al tema logs. Es lo básico que te ofrece por defecto.

Una vez creada la lambda llegaremos al dashboard desde donde gestionaremos todo. Aquí os recomiendo seguir los pasos que cuenta Javier en su post. Al final tendréis algo con la siguiente pinta:

En la imagen podemos ver:

• La parte de admin de la lambda, ahora seleccionada, que nos permitirá la gestión del código que ejecutará.
• El trigger de Alexa Skills.
• El trigger de los logs (hablaré más sobre logs en otro post).

Y si creáis el tema del versionado tendréis al menos un alias configurado contra su respectiva versión de la lambda.

Ahora ya tenemos lo mínimo necesario para conectar el skill con la lambda.

Conectando el skill y la lambda

Hay que conectar ambas cosas, en dos pasos, cada uno desde su consola. El orden importa porque no podréis guardar la configuración del endpoint en el skill sin haber configurado primero la conexión de la lambda con Alexa.

Necesitarás dos datos:

• ARN de la lambda para ponerlo en el skill. El ARN lo podrás copiar de la consola de gestión de tu lamdba.

• Skill id para ponerlo en la configuración de la lambda. Lo puedes copiar desde la zona de configuración del endpoint de la consola.

Conectando la lambda con el skill

Con el skill id de la imagen anterior podremos configurar la integración en la lambda. Desde el trigger que habíamos añadido podemos indicar nuestro skill id de forma que verificamos la conexión. Recordad guardar la configuración una vez añadido el id. Será necesario para la correcta configuración del skill con la lambda.

Conectando el skill con la lambda

Desde la Alexa Developer Console de nuestro skill podremos configurar el endpoint. Es la misma pantalla desde donde cogimos el skill id.

Lo único que hay que indicar es el tipo de endpoint, AWS Lambda en mi caso, y el ARN del mismo. Tened en cuenta que el ARN será el de la versión que hayáis creado si lo estáis haciendo así. Si no, cogerá la última versión de la lambda siempre por defecto y será más complicado de gestionar una vez hayáis certificado y esté publicada. Mi consejo es usar el sistema de versionado.

Sólo nos queda guardar la configuración del endpoint. La consola realiza una validación de la configuración entre skill y lambda y nos hará saber si todo está correcto o tenemos algún problema.

Show me the code

Todo este trabajo anterior de fontanería es necesario para que el skill acabe hablando con el código que vamos a desplegar en la lambda. Había pensado explicar en este post también el código pero creo que va a quedar demasiado largo y lo contaré mejor en el siguiente. Dejo aquí el link del repo de GitHub donde voy subiendo lo que hago para que lo podáis consultar, y si tenéis alguna pregunta podéis escribirme aquí un comentario o por twitter.

Resumen rápido:

• El punto de entrada es la clase UpcomingMoviesStreamHandler donde se registran todos los handles para los intents definidos en el interaction model.
• Le he dado muy poco cariño al código, la verdad (nula gestión de ramas, cero tests, etc). Mi primer objetivo era certificar una primera versión del skill y a partir de ahí estoy mejorando cosas. Además temas como el testing creo que serán interesantes de ver y de contar.
• El listado de estrenos de cine que consulta el skill está como un fichero csv en el propio lambda, no he usado ninguna API por el momento aunque alguna tengo localiza para el futuro.
• La clase que tiene más miga es NewReleasesIntentHandler donde manejo el intent principal de mi skill y el slot de fechas.

Profundizaré en el código en el siguiente post :)