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:
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.
Informática y Sistemas (β) 