Uno de sus empresas cliente solicitó a Snoop Consulting su ayuda para poder resolver un problema que a primera vista no tenía solución.
La empresa es una sociedad agroindustrial argentina que originalmente centraba sus actividades como ingenio azucarero y luego se diversifica incorporando líneas de producción de papel, frutas, jugos cítricos, cereales, alcohol y bioetanol.
El Desafío
El área de inteligencia de negocios de la empresa provee a sus usuarios, alrededor de trescientos, información mediante reportes generados mediante la herramienta MicroStrategy. Se generan aproximadamente cien mil reportes por mes que son enviados vía correo electrónico personalizado a cada uno de los usuarios. Estos reportes se generan durante el día en diferentes momentos para no sobrecargar la línea de datos, se envían con frecuencias diarias, semanales o mensuales y a diferentes horarios. El problema que planteó el cliente era que desconocía la eficiencia de estos envíos, ya que no podía saber si los usuarios que lo recibían leían esos reportes, ni siquiera si abrían los mails. La falta de información sobre la utilización efectiva de los reportes para los días y horarios prefijados, no permitía que éste proceso pudiera ser mejorado balanceando la carga de generación y envío, provocando un desaprovechamiento de los recursos existentes.
La solución
Se propuso una solución mediante la utilización principalmente de AWS SES y AWS Lambda. Mediante SES se interceptaron los mails enviados por MicroStrategy para incorporar ciertas modificaciones mediante un conjunto de Lambdas. A medida que se interceptan los mails y se procesan se guardan en Amazon S3, para luego enviarlos al destinatario original.
Mediante las Lambdas se modifica el mail agregando un píxel invisible de forma que al abrirlo se realice una petición GET con un ID único como query param al Amazon API Gateway. De este modo, cuando el usuario abre el mail se ejecuta una Lambda que obtiene el ID único (uuid) para poder identificarlo. Ya sabemos quien abre el mail.
Los attachments del mail son removidos del mismo y subidos a Amazon S3. En su lugar, en el mail se incluye un link para descargar los archivos. Así, cuando el usuario decide efectuar la descarga, ésta acción también es detectable. Ya sabemos quién descarga los reportes.
Luego del procesamiento de la información, los resultados se publican en un endpoint de SAP para poder obtener los informes correspondientes sobre la utilización de los reportes.
Trabajando con AWS Lambda
Los servicios de AWS que fueron utilizados como parte de la solución fueron AWS SES, AWS Lambda, Amazon S3, Amazon Dynamo, AWS SQS y Amazon API Gateway. Se realizaron sesiones técnicas en las cuales se explicó al cliente la solución (serverless y en node.js en gran parte) ya que estas tecnologías era completamente innovadoras para su área.
Fueron desarrolladas siete funciones Lambda, seis en node.js y una en Java, que permitieron crear una solución rápida y efectiva para el tratamiento de un total aproximado de 100000 eventos mensuales (emails)
Con respecto a las políticas IAM (Identity and Access Management), se definieron para las funciones Lambda los permisos necesarios para encolar y desencolar los mensajes de AWS SQS, escribir en AWS Dynamo, AWS SES y para la lectura y escritura de Amazon S3.
El modelo de solución implementado soporta concurrencia, simplemente las funciones Lambda escalan automáticamente. Solamente hubo que implementar un registro de los emails procesados en Dynamo para evitar mensajes repetidos de AWS SQS.
Se hicieron pruebas de rendimiento en el ambiente de test del cliente utilizando MicroStrategy con la solución implementada y los resultados fueron óptimos, lo que rápidamente abrió paso para la puesta en producción que permitió realizar el análisis real de la información que antes era imposible obtener, y luego traducirla en estrategias de generación y distribución de los reportes que mejoraron notablemente la performance del área y la efectividad de las comunicaciones.
