Azure Functions: uso de Singleton para enviar correos con PDF desde Dynamics 365

Cuando se empieza a trabajar con una Azure Function es normal sentirse algo confundido. Lo primero que se ha de tener claro es que permiten crear lógica en la nube sin preocuparse por servidores.

En este artículo te enseño cómo montar una Azure Function que recibe una petición HTTP y envía un correo con un PDF adjunto a través de Dynamics 365. Para su funcionamiento se va a utilizar un patrón sencillo que permite mantener una única conexión al CRM y así evitar autenticaciones innecesarias.

Antes de entrar en la parte más técnica, es necesario entender que esta Azure Function recibe la información de un agente junto con las incidencias que tiene asignadas. Del agente se reciben datos como el nombre completo, identificador y correo electrónico. De la lista de incidencias asociadas al agente se obtiene la información de cada una de ellas, incluyendo su estado, el motivo y, en caso de estar cerrada, la fecha de cierre.

El objetivo de este artículo es que entiendas su funcionamiento para poder aplicarlo en tus propios desarrollos.

A continuación, vamos a ver cómo se organiza la Azure Function. Para poder entender su funcionamiento sin problema se va a dividir en cuatro tareas principales:

• Recibir una petición HTTP: es la forma en la que nos llegarán los datos.
• Procesar los datos: para obtener el contenido del correo.
• Generar un documento PDF: este contendrá la información con los datos procesados.
• Enviar un correo electrónico: este tendrá el asunto correspondiente, el cuerpo y el PDF adjunto.

A nivel técnico hay tres ideas importantes a tener en cuenta.

• Reutilizar la conexión a Dynamics 365: si cada vez que se ejecuta la Azure Function tiene que hacer la conexión a Dynamics esto hará que funcione más lenta. Por eso, en lugar de crear una conexión nueva cada vez, se guarda una única conexión y se reutiliza.
• Separar la lógica de la autenticación del resto del código: esto nos ayudará a que el código se vea menos confuso y por lo tanto más fácil de mantener.
• Separación de responsabilidades: es necesario tener claro qué hace cada parte del código. Se divide en las cuatro tareas principales que hemos comentado anteriormente.

Antes de entrar en la implementación, es importante tener clara la estructura de la solución.

• Program.cs: aquí es donde se crea la conexión a Dynamics 365. Se registra con el patrón Singleton, lo que significa que se crea una sola vez y se reutiliza en todas las ejecuciones.
• Services/ID365MailService.cs: se encarga de todo lo relacionado con enviar correos desde Dynamics 365. Con esto me refiero más concretamente a crear el correo electrónico, adjuntar el archivo PDF y realizar el envío.
• FunctionHTTP.cs: es donde se implementa la Azure Function con el disparador HTTP. Su trabajo es recibir la petición, validar los datos, generar el PDF y llamar a ID365MailService.cs para que realice el envío. Este fichero es el encargado de coordinar todos los procesos.
• Archivos de configuración: los archivos host.json y local.settings.json ajustan el comportamiento de la función y guardan las variables necesarias para conectarse a Dynamics 365 durante el desarrollo y las pruebas.

Además de la estructura de la solución también es necesario mencionar los paquetes NuGet que se utilizan.

• Microsoft.Azure.Functions.Worker.Sdk: permite crear y ejecutar la Azure Function.
• Microsoft.PowerPlatform.Dataverse.Client: se utiliza para conectarse y trabajar con Dynamics 365.
• QuestPDF: se emplea para generar el documento PDF.

Configuración de la Azure Function y uso del patrón Singleton.

Program.cs
Una vez clara la estructura del proyecto, el primer archivo en el que hay que fijarse es Program.cs. Este archivo es el primero que se ejecuta cuando arranca la Azure Function.
Aquí es donde realizaremos la conexión con Dynamics 365. El beneficio principal de hacer la conexión en este archivo es crearla una sola vez y reutilizarla en todas las ejecuciones. Esto es lo que se conoce como patrón Singleton.
En las siguientes imágenes podemos ver cómo se realiza la conexión a Dynamics utilizando una App Registration, haciendo uso directamente del ClientId y ClientSecret.

Es importante aclarar que incluir el ClientId y el ClientSecret directamente en el código no es la opción más segura ni la más recomendable, ya que puede suponer un riesgo si el código se comparte. Por este motivo, es preferible almacenarlos en variables de entorno.

ID365MailService

Ya tenemos la conexión a Dynamics configurada, el siguiente paso es crear la parte encargada del envío de correos. Hay que recordar que esta parte del código vamos a crearla aparte para evitar mezclar responsabilidades.

Primero se define la interfaz donde se ve cada una de las partes del correo.

Para poder comunicarse con Dynamics 365, es necesaria una conexión. Como ya la hemos creado anteriormente, en lugar de volver a crearla simplemente se la pasamos.

FunctionHTTP.cs

El siguiente paso es implementar la Azure Function que va a ser la parte encargada de coordinar todo el proceso.

Primero, recibe una petición HTTP POST. Este es el punto donde cada vez que alguien hace una llamada a la URL de la Azure Function aquí empieza el flujo.

Esta petición contiene la información necesaria en formato de un JSON. Para poder leer y manejar ese contenido se convierte el JSON a un objeto.

Ahora que ya tenemos el objeto es momento de validar los datos obtenidos para evitar errores más adelante. A continuación, dejo ejemplos de validaciones.

Con estas validaciones comprobamos que tiene los datos básicos necesarios para comenzar con el proceso y en caso de faltar alguno de ellos, se devuelve un mensaje de error y finaliza el proceso.

Con los datos ya validados correctamente, se procesan los datos según necesite la funcionalidad. En este caso he separado las incidencias abiertas, las cerradas en el último mes y un resumen del número de incidencias que hay por motivo.

Cuando la información está preparada, es el momento de generar el documento PDF. Para ello se utiliza una librería de generación de documentos.

Una vez generado el PDF, este queda listo para ser adjuntado al correo electrónico que se enviará desde Dynamics 365, tal y como se muestra a continuación.

Desde la Azure Function simplemente se llama al servicio encargado del envío de correos, al que se le pasan los datos necesarios, incluyendo el archivo PDF y el nombre del adjunto.

Resumen del proyecto

1. La Azure Function recibe una petición HTTP.
2. Se leen los datos enviados en el cuerpo de la petición.
3. Se valida que la información recibida sea correcta.
4. Se procesan los datos necesarios para el informe.
5. Se genera un documento PDF.
6. Se envía un correo electrónico con el PDF adjunto utilizando Dynamics 365.

Hay que tener en cuenta que para que el envío de correos funcione correctamente, es necesario que Dynamics 365 esté configurado correctamente. El usuario o la cola desde donde se envían los correos debe tener un buzón habilitado y aprobado. Si no está configurado de este modo, el correo se creará correctamente, pero quedará en estado “pendiente de envío”.

La ruta para acceder a los buzones que se deben habilitar es la siguiente: Configuración avanzada -> Configuración de correo electrónico -> Buzones de correo.

Cuando ya tenemos el buzón habilitado y aprobado está listo. Solo queda ver un ejemplo de cómo recibiría el correo el receptor y el documento PDF adjunto.

Hemos visto cómo crear una Azure Function que recibe una petición HTTP, genera un documento PDF y envía un correo electrónico con el archivo adjunto a través de Dynamics 365.

Uno de los puntos a destacar es el uso del patrón Singleton, que permite reutilizar la conexión a Dynamics 365 y evitar realizar autenticaciones innecesarias.

Además de separar el código en diferentes archivos que nos ayuda a que el código sea más claro, ordenado y fácil de entender sobre todo cuando el proyecto en el que se ha implementado crece.

Esta solución puede utilizarse como base para crear funcionalidades similares utilizando Azure Functions y Dynamics 365.