Georeferencias en Azure SQL y mapas en PowerBI (Azure Maps)

Al trabajar con datos geográficos, para quienes no están especializados en el tema puede llegar a ser un tema bastante oscuro, y en ciertas ocasiones puede llegar a ser frustrante no tener información conceptual clara de los conceptos básicos. Para mostrar este tema de una forma sencilla les acerco una capacitación que di recientemente, donde vemos algunas definiciones elementales de cartografía, manejo de tipos geográficos en Azure SQL, cálculos de distancias e inclusión en polígonos, además de algunos ejemplos de representación en mapas como en Azure Maps.

Suscripción a eventos por Azure Event Grid

Un tema recurrente al diseñar los ETL, pieza fundamental de todo data warehouse, es la programación de lectura de orígenes de datos. Al trabajarlos especialmente desde sistemas transaccionales la frecuencia de lanzamiento no siempre es claramente pautada, generando una incertidumbre que atenta contra la rutina de horas específicas preestablecidas. El camino más fácil, y del que se abusa innecesariamente, es la ejecución iterativa dentro de periodos muy cortos de tiempo, algo que anteriormente comenté que es la salida más nefasta, la que causa más dolores de cabeza y sobrecostos evitables. Evaluemos este tema y una alternativa saludable para tomar de modelo dentro de una arquitectura de micro servicios en la nube.

Antes que nada, voy a fundamentar las principales desventajas de los procesos iterativos, además del evidente del costo extra de tener procesos haciendo comprobaciones o directamente leyendo una y otra vez las mismas fuentes al no poder detectar la llegada de información nueva. Consideremos que el enfoque más moderno de un data warehouse se basa en modelos multidimensionales, cuyas relaciones entre dimensiones y hechos obligan a leer los datos con un cierto orden. Sin hay incertidumbre sobre cuándo aparecen las novedades en los diferentes orígenes la orquestación basada en procesos iterativos se hace directamente inviable. Si a esto agregamos que se da cierto margen entre iteraciones, con un enfoque económico de una o dos veces a la hora, la orquestación de ejecuciones multiplicará la latencia entre las mismas por la cantidad de orígenes diferentes, llegando a tener horas de retraso por suma de tiempos muertos, y probablemente ello atente contra la oportuna disponibilidad de la información final. Finalmente el control de secuencialidad entre los procesos se hace tan engorroso que debilita la solución tanto por errores de detección como por solapamientos indeseados inevitables en este tipo de soluciones.

Ahora veamos una mejor alternativa, quienes programan aplicaciones modernas están familiarizados con el concepto de “eventos” que en un primer momento podría considerarse opuesta a la secuencialidad mencionada, sin embargo no son excluyentes. La idea es lograr la secuencialidad orquestada por eventos, e independizando todo lo posible los acoplamientos para minimizarlos. Cuando trabajamos en la nube de Azure, la herramienta más apropiada para integrar información es el Data Factory, sucesor natural de los servicios de integración de SQL aunque admita un motor de compatibilidad para permitir usarlos en los casos cuya funcionalidad aún no está cubierta por este nuevo producto. Aunque una de las ventajas que le hace ganar puntos es la facilidad de suscribir ejecuciones gatilladas por eventos (trigger).

Una posibilidad que aprovecho con frecuencia es la de detectar cambios en los blob de Azure Storage, principalmente la carga de un archivo que de manera inmediata ejecuta el proceso de integración por la canalización (pipeline). Si logramos que el sistema proveedor de los datos, o persona si es carga manual, deje el archivo a integrar en el storage tenemos resuelto el primer gran paso. Al final de cada bloque de integración se puede verificar en una tabla de SQL, o table storage alternativamente, los pasos que debe seguir ejecutando a continuación si un conjunto de archivos termina de completarse. Con esto se puede tener una orquestación que controle perfectamente el paralelismo.

Un segundo escenario se presenta cuando no tenemos la amable posibilidad de que nos alcancen los archivos en storage y debamos buscarlos. Esto es muy común en el ámbito financiero donde los bancos trabajan antiguos sistemas de mainframe que no acompañan los sistemas más modernos, y a duras penas disponibilizan carpetas FTP. Como en el caso de la integración desde una casilla de correo de un artículo anterior, las aplicaciones lógicas de Azure nos pueden auxiliar con la detección. Un paso detecta la llegada de un archivo nuevo a la carpeta ftp controlada y lanza un evento a la grilla personalizada a la que está suscrita la canalización del DataFactory.

Detección de eventos a través del Azure Event Grid

El método que utiliza es exponer webhooks que enlazan los eventos entre ambos sistemas. La canalización recibe el mensaje a través del callback, donde se le indica los datos de identificación del archivo detectado y su ruta dentro del FTP, para que pueda integrarlo inequívocamente. El éxito de las operaciones se puede monitorear dentro del módulo de administración del Event Grid como se muestra en la imagen anterior, aunque como en muchos otros servicios que utilizo jamás extravió o tuvo excepciones el gatillazo de un evento. En la parte inferior se muestran los distintos webhook que aprovechan los sistemas, algunos desde aplicaciones C# en servidores on-premise, siendo el último el dedicado a la detección de llegadas de archivos por FTP. El mismo evento puede estar asociado a diferentes tipos de archivos, y cada uno de ellos lanzará la respectiva canalización de DataFactory que los integra. Un ejemplo de estas secuencias la vemos en la siguiente imagen, desde el monitor de procesos del DataFactory:

Monitor de ejecución de canalizaciones en DataFactory

Como se puede apreciar en la secuencia, para la gran mayoría el orden diario de las ejecuciones no siempre es el mismo, dado que las integraciones de archivos desde el FTP dependen de la llegada desordenada de archivos a integrar. Para que se lancen las canalizaciones independientes en forma certera, hay un paso previo que es la copia del archivo desde el FTP a una carpeta auxiliar en blob storage, para lograr un mejor rendimiento copiando el archivo íntegramente para posteriormente integrarlo con su canalización dedicada.

Resumiendo, con un esquema de este tipo podemos aprovechar los recursos de microservicios en Azure de la mejor manera posible y para lo que cada uno esta especializado: Logics Apps para detectar colocación de archivos en FTP, Event Grid para transmitir por evento la identificación del archivo, y DataFactory para copiar e integrar los archivos desde Blob Storage a SQL a otros destinos (por ejemplo Azure SQL y/o Table Storage).

Como de costumbre, como puede haber más de un tipo de solución combinando microservicios, pueden dejar sus comentarios describiendo otras arquitecturas que les hayan dado resultado para solucionar casos similares.

Posibilidad de instalar una instancia de Reporting Services (SSRS) en la nube

Para no generar falsas expectativas con el título, debo anticipar que el producto en sí de SQL Reporting Services no admite su instalación cloud, sin embargo hay dos métodos alternativos que pueden prolongar la vida del producto soportado en la nube por varios años más. De hecho, a pesar de todos los rumores y recomendaciones en off de pasar a PowerBI como reemplazo, se siguen versionando junto al motor de base de datos (actualmente la 2022) y no hay planes a la vista de discontinuidad total del producto.

La primera explicación es quedar toda duda de su incompatibilidad con las tecnologías de nube: Reporting Services tiene casi 20 años de antigüedad y se desarrolló en una época en que el XML era un estándar muy aceptado, de hecho se usan rutinas programadas como extensión del lenguaje llamada XMLA, hoy en día considerado de hecho como algo obsoleto para nuevos desarrollos y con cero compatibilidad con los servicios cloud. Además de esto, su sistema de servidor trabaja como servicio local del sistema operativo de windows, interactuando de esa manera entre su portal web y la base de datos dedicada; de esta manera no hay plataforma dentro del ecosistema de micro servicios Azure que permita una arquitectura de ese estilo.

Descartada esta posibilidad, el único remedio que queda es crear una máquina virtual como servidor donde instalarlo, y publicar su portal desde dicho entorno. La máxima flexibilidad que nos da esta situación en la nube es poder asociar un directorio de autenticación Azure AD, y explorar las limitaciones que pueda tener este conjunto. En mi caso, enfrenté el tema con la situación poco feliz de no contar con autenticación Active Directory para los usuarios, sino que el log a los sistemas se hacen con autenticación por servicios de Google. Por favor no me critiquen por eso, no fue una decisión propia la de usar este esquema híbrido y tampoco lo recomiendo especialmente.

Ahora bien, con estos limitantes tenemos por un lado una máquina virtual servidor con autenticación básica por SQL a nivel de datos y cuenta de servicio de sistema operativo local para Reportes, mientras por el otro hay todo un ejercito de usuarios tratando a de acceder con sus cuentas Google. Pero a no desesperar que todavía existe una posibilidad y es la que vengo usando con éxito desde hace dos años: desarrollar un sitio web (intranet) como interfaz (o proxy si le cabe esta definición).

En efecto, se trata de un sitio de servicio o Aplicación Web de Azure, desarrollado para autenticar por Google, con autorización por roles y una series de páginas que muestran embebidos los reportes del SSRS. La tecnología de la intranet es ASPX con .NET 4.8/C#, dado que nos provee de un control nativo de SSRS para poder mostrar estos reportes (tanto en forma de frame como de página completa) ocultando la dirección original del servidor de reportes mejorando la seguridad. El servidor de reportes queda así protegido y pueden cerrarse todos los puertos que no provengan de la red virtual de Azure, siendo accedido solo desde a través de su ip interna en red virtual. En el caso que no pueda conectarse a través de la red interna, igualmente el firewall puede cerrar todos los puertos a orígenes que no sean del servicio de intranet. Esta aplicación web puede probarse sin inconvenientes en su versión de desarrollo que es gratuita, y si no es muy exigente el uso del sitio puede mantenerse definitivamente en ese nivel de servicio lo que abarata el costo del workaround.

Esta arquitectura tiene una serie de configuraciones qué hay que cuidar con sumo detalle para que funcione armoniosamente, pero nada que investigando un poco en la web no se pueda resolver. Tengamos en cuenta que tratamos de forzar un producto a entornos y plataformas en la nube nuevas que ni siquiera se soñaban en su época de desarrollo. Una alternativa a los sitios ASPX que también se están dejando de lado (se incentiva el uso de core 6/7 para servicios de Aplicaciones Web que tienen un mejor manejo de los nuevos modelos de programación basados en Inyección de Dependencias integrados a entornos cloud), es crear sitios web basados en Blazor. Estimo por lo que investigué que la versión que mejor acomoda es la de servidor (Blazor Server), sin embargo no hay controles nativos que permitan integrar Reporting Services en forma más o menos transparente, y usar los iframe francamente son un agujero de seguridad importante. Existen productos de terceros de pago que equivalen al componente de SSRS, pero mientras podamos usar ASPX no debería interesarnos, y hasta quizás haya otras y mejores alternativas para cuando debamos migrar obligatoriamente este esquema de solución a futuro. Ir migrando todo lo permisible a PowerBI es siempre una buena idea, para minimizar el esfuerzo de adaptar aquellos reportes que hoy nos impliquen sacrificar funcionalidades de cara al usuario por no tener equivalentes en PowerBI.

Para tener una idea de como opera el conjunto, podemos echar un vistazo al monitoreo de Application Insights:

Solución de Reporting Services combinado con un portal de autenticación Google.

En la figura, la instancia central representa al sitio web de la Intranet, una Web Application en su modo básico de configuración, que se conecta a un servicio de SQL Azure (en rojo) y usa internamente el servicio de sistema de claves (Key Vault) y Azure Active Directory (ambos en azul) para su funcionamiento. La autenticación por Google, al ser un servicio externo, no queda monitoreada por este esquema. Finalmente en amarillo se muestran dos conexiones al mismo servidor donde se encuentra instalado Reporting Services, una para el portal (protocolo http) y la otra a su servicio web gracias al cual el componente embebido recupera la información a desplegar de los reportes. Este último servicio web accede además al servidor de SQL señalado en rojo, pero que no puede monitorear el servicio de Insights por obvias razones.

Como pueden apreciar la solución se comporta perfectamente y la menor incidencia de errores que apenas se ve como el mínimo punto rojo en la instancia del sitio web, es debida a timeout por tiempos muertos en explorador de las páginas o al exportar grandes archivos a excel o PDF generalmente, lo cual es permisible y no generan reportes de incidencias específicamente por parte de los usuarios. Espero que el ejemplo les ayude a resolver situaciones similares, y con tan buenos resultados como los que obtuve apoyado en este esquema.

Una solución sencilla de integración poco ortodoxa por Aplicaciones Lógicas (Azure)

Un tema que será recurrente cuando describa arquitecturas distribuidas en la nube es el uso de micro servicios acoplados para otorgar esquemas simples y mantenibles de soluciones. El caso que abordamos hoy es el de una integración desde una entidad externa, un proveedor cuyo único medio que nos otorga para enviar datos transaccionales es el correo electrónico. Desde mi experiencia es la primera vez que me presentan un escenario de este estilo, y seguramente muchos profesionales que lean esto jamás se encuentren en su vida con una situación semejante. Pero lo interesante de todo esto es que los servicios en la nube nos dan todo lo necesario para resolverla.

El problema de interpretar el texto del cuerpo del correo no es relevante para estudiar el caso, en definitiva se trata de hacer una extracción de conocimiento de un texto. Para mi ejemplo el que tenga un formato generado automáticamente simplifica mucho hacer el análisis y extracción de información relevante, pero aunque sea texto libre que deba interpretarse por rutinas de IA no habrá ninguna diferencia, dado que lo podemos trabajar desde una rutina en una función Azure en Core 7, con toda la libertad que nos da el C# para realizar la tarea. El centro del problema es el detectar la oportuna llegada del correo, para iniciar la secuencia programada.

Particularmente soy adverso a crear rutinas de ejecución recurrente cada cierto tiempo, por lo engorroso de monitorear este tipo de procesos y especialmente porque genera muchas veces un sobrecosto innecesario desde el punto de vista de mejor aprovechamiento de recursos. Como expliqué en artículos anteriores toda ejecución en la nube implica un costo que se debe minimizar o aplicar a procesos útiles, y las rutinas iterativas con aprovechamiento mínimo entre serie de ejecuciones atenta contra una solución razonable en este tipo de entornos y solo debe recurrirse a ellas en casos que no haya más alternativa.

En este sentido las Aplicaciones Lógicas de Azure nos dan la posibilidad de suscribirse a eventos de llegada de correos electrónicos, no importa si el proveedor es Office365, Exchange o Google. En estricto rigor, el chequeo de recepción de correos se hace internamente a una frecuencia programable, en mi caso de 3 minutos, pero lo interesante de esto es que esa revisión periódica se hace en forma trasparente sin llegar a disparar el proceso de ejecución. La aplicación las lista en forma independiente como ejecuciones “omitidas”, dejando el monitoreo basado solamente en ejecuciones de procesamiento reales simplificando en gran forma el seguimiento y revisión posterior. El esquema comienza con este sencillo paso, y el diagrama de solución queda como muestra la imagen siguiente:

Detalle del diseño de una rutina de App Logic (Azure)

El módulo detecta y lee los datos del correo, incluyendo sus propiedades, pemitiendo como en el ejemplo guardarlos en una tabla de SQL auxiliados por un procedimiento almacenado, que dejará la auditoría del procesamiento y estados del cada registro accesibles para su control eventual. A continuación y orquestados por la misma aplicación lógica se inicia la ejecución de una Función Azure (otro micro servicio independiente) que hará el trabajo pesado en Core 7/C# basado en los registros de la tabla en SQL Azure. Para finalizar, en caso de éxito, se elimina el correo electrónico recibido. Esta solución básica dio un excelente resultado, y a pesar de contar con rutinas que la puede complementar con el manejo de excepciones en cada uno de los pasos, durante el año y medio que viene ejecutando jamás tuvo una situación de error, y este proceso no es tan crítico como para necesitarlas.

Como toda solución, hay muchas alternativas para abordarlas, reemplazar las tablas SQL por una cola o tablas en Storage por ejemplo, pero dentro del marco de soluciones entrelazadas existentes que aprovechan estos datos para diferentes contextos y contando con una base operativa de SQL funcionando como ODS (Operational Data Store) es la opción más sencilla que cumple funcionalmente la necesidad, y además la más económica (una batería de 10 Logic Apps de régimen similar 24×7 están generando actualmente un costo mensual inferior a los 15 U$S).

Para finalizar dejo un listado de ejecuciones tal y como lo muestra el servicio, que registra los pasos de ejecución y estados, como se ven en la figura superior. Espero que estos tips ayuden a orientar sobre el uso en el mundo real de micro servicios, y por supuesto cualquier experiencia similar que quieran compartir en los comentarios será bienvenida para dar más opciones.

Historial de ejecuciones y resultado de las mismas

Metaindicadores: asegurando la calidad de la información en sistemas de Inteligencia de Negocios

Los sistemas de Inteligencia de Negocios integrados en las organizaciones se vuelven una herramienta que pasan rápidamente de brindar un panorama estadístico a constituir el principal referente para el gobierno de la empresa. De hecho esta es la finalidad, y para que realmente sea efectiva no solo es requisito la oportunidad de la información que entrega, sino que

Integración de Sharepoint 2010 y Visual Studio 2010

En esta ponencia, desde la jornada de la Alm’09 sessions de Microsoft en Madrid, se muestran los avances para trabajar el desarrollo en Sharepoint ahora posible en un entorno de Visual Studio, y con todas las ventajas de ahorro de tiempo y esfuerzo respecto a sus versiones previas bastante rudimentarias:

El Datawarehouse dentro del enfoque de la Inteligencia de Negocios

esquema básico de BI

El desafío inicial de los almacenes de datos o datawarehouse era contar con la capacidad suficiente de almacenamiento como para albergar la totalidad de operaciones de una organización. Con el tiempo y el abaratamiento de los servidores y hardware dedicado (discos duros tradicionales o de estado sólido, storage, etc.) el siguiente gran desafío era integrar los distintos sistemas para alimentar el datawarehouse corporativo, batalla que se está ganando exitosamente. Pero un tema primordial y que ahora tiene mayor relevancia es saber qué hacer con todo este bagaje de datos; como explotar u obtener conocimiento aprovechable de ellos.

Manejo de errores en capa de presentación web

En términos ideales los errores en aplicaciones no deben producirse, pero esto es inevitable y tarde o temprano suceden. En el ámbito web donde la mayoría de las aplicaciones apuntan a usuarios externos o casuales, los errores internos de las aplicaciones suelen presentarse con una información detallada que si bien es de gran ayuda a un programador, en realidad están volcando datos sensibles de la infraestructura interna del sitio y sus componentes. Esta información, inservible para la mayoría de los usuarios casuales, es buscada deliberadamente por hackers o delincuentes digitales quienes hacen caer a propósito los sitios para obtener datos y afinar sus ataques o accesos no autorizados. Por ello es sumamente importante tener en cuenta las recomendaciones para evitar estas filtraciones.

Azure SQL Services: Una completa aplicación de base de datos en línea

bases de datos en la nube

Completando las pruebas de los servicios de SQL Azure en el sitio que implementé hace algunas semanas; debo decir que realmente cumplió con lo prometido, y su programación es trasparente para cualquier desarrollador que haya trabajado anteriormente con .Net y SQL Server. De más está decir que el rendimiento en la fase CTP (esto es, con pocos usuarios y bases de datos pequeñas) es óptimo, por lo que a continuación voy a comentar sobre ciertos aspectos a considerar antes de decidir su adopción.

Evitando campos de tipo bit en tablas SQL Server 2008

evaluando usar el bit como tipo de dato

Muchas veces tendemos a almacenar registros con ciertos campos que ofician de “banderas” (flags) para representar información que solo tienen dos estados posibles (sí-no; verdadero-falso; 1-0; etc.)  Este tipo de recurso es tradicional y se utiliza desde los primeros sistemas de bases de datos de acceso secuencial, donde la longitud del registro se diseñaba bit a bit; y el largo del mismo era crucial para minimizar la capacidad total, cuyo almacenamiento era sumamente costoso. En estos sistemas antiguos tomar la decisión de reservar dos o tres bit por registro para necesidades futuras era un tema para evaluar seriamente. Sin embargo el tiempo ha pasado, los sistemas de almacenamiento como SQL Server 2008 tienen acceso aleatorio apoyado por índices, y los costos de almacenamiento se abarataron hasta dejar de ser una preocupación primordial. Bajo este contexto hoy en día debemos evaluar la importancia de usar campos de tipo bit, pero desde otro punto de vista: desde el rendimiento del sistema.