SSRS

SSRS dice adiós: PBIRS toma el relevo en SQL Server 2025

SSRS dice adiós: PBIRS toma el relevo en SQL Server 2025

La semana pasada, en el SQL Bits, Bob Ward nos daba la noticia con la sonrisa de quien cree que ha tenido una gran idea y espera que todos aplaudamos: a partir de SQL Server 2025, SSRS se queda sin futuro. No habrá nuevas versiones, ni promesas de mejoras, ni siquiera ese Service Pack que llegaba tarde y mal. En su lugar, Microsoft ha decidido que todo lo relacionado con reporting on-premises se haga con Power BI Report Server. PBIRS entra en todas las ediciones de pago de SQL Server y SSRS, después de dos décadas de leales servicios, se queda en mantenimiento hasta 2033. Merece la pena parar un momento, repasar esta historia y ver por qué este cambio tiene sentido, aunque duela.

El ascenso y estancamiento de SSRS

SSRS lleva en nuestras vidas desde antes que alguno de vosotros. Concretamente desde 2004, cuando se presentó como una extensión gratuita para SQL Server 2000. Su propuesta era clara: permitir la creación de informes paginados usando RDL (Report Definition Language), con control pixel-perfect y exportaciones a Excel que acababan en los escritorios de medio planeta. Fue una revolución en su momento, sustituyendo soluciones propietarias más caras y difíciles de mantener (Crystal Reports, te estamos mirando a ti). A partir de SQL Server 2005, SSRS ya venía integrado, y poco a poco se convirtió en la herramienta por defecto para reporting operativo en entornos on-prem. Muchos aún lo siguen usando a diario: por robusto, por fiable y porque funciona.

Pero también es cierto que lleva años estancado. Las mejoras en las últimas versiones han sido mínimas, casi anecdóticas. La interfaz de desarrollo, ya sea en Visual Studio o en Report Builder, parece sacada de una cápsula del tiempo. Y mientras tanto, Power BI ha crecido, se ha convertido en la niña mimada del equipo de producto y ha absorbido toda la inversión. No había que ser visionario para intuir que a SSRS le quedaban pocos cartuchos.

PBIRS entra en escena con todo el respaldo

PBIRS, por su parte, se presentó como una solución híbrida. Construido sobre la base de SSRS permite ejecutar tanto informes paginados como informes interactivos en formato PBIX, lo cual lo convierte en un candidato ideal para ser ese puente entre lo tradicional y lo moderno. Además, añade características importantes como el soporte de seguridad a nivel de fila, visuales personalizados y actualizaciones con una frecuencia más propia de los productos cloud que del viejo stack on-prem. 

Hasta ahora, PBIRS era un extra al que solo podían acceder los clientes de SQL con licencia Enterprise y Software Assurance o clientes de Fabric con licencias F64 o superior, lo que limitaba mucho su adopción. Por suerte, esos tiempos oscuros se van a acabar: a partir de SQL Server 2025, cualquier edición de pago de SQL incluye derecho a instalar PBIRS, usando la misma clave del servidor. Más fácil, más directo, más lógico, como era con SSRS.

La lógica detrás del cambio de SSRS a PBIRS

La justificación oficial es que SSRS no es más que un subconjunto de lo que ofrece PBIRS. Y es cierto: todo lo que hacía SSRS, lo hace PBIRS. Pero también hace más cosas. Si estás en un entorno donde ya conviven informes RDL con Power BI, la unificación es natural. Si vienes solo de SSRS, puede que el salto te parezca innecesario, pero la dirección está clara. Microsoft quiere que el reporting on-prem hable el lenguaje de Power BI, aunque aún no estemos listos para irnos a la nube.

Lo que ganamos con PBIRS (y lo que perdemos)

Ahora bien, no todo es ganancia. En la transición se pierden cosas. Algunas funcionalidades específicas, como los informes vinculados, no tienen una traducción directa en PBIRS. Las integraciones con sistemas antiguos o personalizados, especialmente aquellas que dependían de extensiones específicas o APIs internas de SSRS, pueden requerir adaptación. Y aunque la migración de RDLs está soportada y bien documentada, eso no significa que sea trivial. Hay que revisar fuentes de datos, suscripciones, permisos, configuraciones de caché y otras complicaciones que todos sabemos que pueden existir en informes que tienen más de 20 años y duermen tranquilas hasta que una migración las despierta.

Migrar a PBIRS: lo bueno, lo malo y lo inevitable

El proceso de migración, en sí mismo, está bastante claro. Microsoft ha publicado guías detalladas y herramientas para mover informes y catálogos desde SSRS a PBIRS. Incluso puedes probar PBIRS en modo Developer o Evaluation antes de tomar decisiones definitivas. Pero, como siempre, todo depende del grado de personalización de tu entorno y de cuánto te hayas alejado del camino en los últimos diez años. Porque sí, todos decimos que usamos SSRS “como viene”, pero luego llegan los informes con código embebido, las fuentes de datos compartidas con autenticación personalizada y ese servidor que nadie quiere tocar porque “funciona y no se ha caído en años”.

Soporte hasta 2033: más calma que consuelo

Lo curioso es que la noticia, pese a ser una especie de epitafio para SSRS, viene acompañada de la típica promesa tranquilizadora: SSRS 2022 seguirá recibiendo actualizaciones de seguridad (en soporte extendido) hasta enero de 2033. Eso quiere decir que puedes seguir usándolo si no quieres o no puedes migrar todavía. Puedes incluso seguir instalando SSRS 2022 con versiones más nuevas del motor de SQL Server, aunque no recibirás nuevas funcionalidades. Básicamente, queda en modo mantenimiento. Como cuando apagas el monitor pero dejas el servidor encendido: sigue ahí, pero ya no espera nada de la vida.

SSRS y PBIRS: Una consolidación inevitable

Hay que reconocer que este cambio tiene sentido. No es una jugada improvisada. Es parte del movimiento más amplio hacia Fabric, hacia unificar las herramientas de BI bajo el paraguas de Power BI, y hacia simplificar el stack on-prem. En lugar de mantener dos productos con solapamientos, Microsoft apuesta por uno solo, más potente, más alineado con su estrategia cloud y más fácil de justificar a nivel de roadmap. Tiembla SSIS.

Aun así, para quienes hemos vivido el mundo SSRS puro y duro, este cambio tiene algo de nostalgia. Nos ha acompañado en muchas guerras, nos ha dado informes que imprimen correctamente en la primera pasada, nos ha dejado programar suscripciones y controlar exportaciones como si estuviésemos montando una fábrica de PDFs. Pero el futuro no es eso. El futuro tiene interactividad, exploración de datos, visuales dinámicos y conectividad con servicios cloud. Y todo eso, por mucho que nos pese, no lo va a ofrecer nunca SSRS.

Conclusión

Así que, no lo veamos como una pérdida. Veámoslo como lo que es: una consolidación que estaba cantada. PBIRS hereda todo lo bueno de SSRS y añade lo que le faltaba. Que el proceso de migración tenga sus complejidades no debería sorprendernos. Es parte del juego (y a los consultores y técnicos nos dará dinerito). Lo importante es que ahora tenemos un camino claro, una herramienta mejor y tiempo suficiente para adaptarnos. Porque sí, SSRS fue grande. Pero PBIRS es el que se queda. Y conviene conocerlo bien, porque es lo que nos espera en los próximos años.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, SQL Server, 0 comentarios

Buenas prácticas en Power BI Report Server (PBIRS)

Continuamos con los artículos sobre Power BI Report Server, ya hemos visto tanto sus características principales como los consejos de implantación y mantenimiento y hoy, y para cerrar esta semana temática, vamos a hablar de buenas prácticas. Lo primero que tenemos que recordar es que Power BI Report Server (PBIRS) está construido sobre la base de SQL Server Reporting Service (SSRS), una herramienta de reporte de BI de Microsoft con más de 15 años en el mercado. Con esto quiero decir que la mayoría de las cosas que vamos a ver ahora os sonarán familiares si ya habéis administrado SSRS pero si no es así no os preocupéis que para eso lo vamos a ver.

Configuración avanzada de Report Server

Cuando instalamos PBIRS tendremos a nuestra disposición una herramienta de configuración calcada a la de SSRS donde podremos realizar las configuraciones más básicas de este servicio. Sin embargo, esto no es todo,habrá aspectos que configuraremos en el propio servicio web y otros, los más avanzados, para los que necesitaremos un SSMS. Y, en concreto, son tres de estas configuraciones de las que vamos a hablar en este apartado. Configuraciones que, para la mayoría de las empresas pueden funcionar pero, para otras igual no tanto.

Para acceder a estas configuraciones nos conectaremos a nuestro PBIRS desde nuestro Management Studio (SSMS) usando la opción de conexión a SQL Server Reporting Service (SSRS). Una vez conectados abriremos las propiedades de la instancia y accederemos a las propiedades avanzadas. Aquí, entre otras, podremos encontrar la siguientes configuraciones:

Power BI Report Server Advanced Config

EnableMyReports

La configuración “Enable and disable My Reports» nos permite a los administradores activar o desactivar la funcionalidad de «Mis informes». Esta función, desactivada por defecto, ofrece a los usuarios la posibilidad de crear un espacio personal dentro del servidor donde pueden guardar y gestionar sus propios informes. Esto es similar al concepto Mi espacio de trabajo que tienen los usuarios dentro del servicio Power BI. Habilitar Mis informes es una excelente manera de fomentar la BI de autoservicio y puede ser beneficioso para fomentar la personalización y la autonomía de los usuarios, permitiéndoles trabajar de manera más eficiente sin sobrecargar los espacios compartidos del servidor. No obstante, dejarlo desactivado puede ser preferible en entornos donde la uniformidad y el control sobre los informes es una prioridad.

ExecutionLogDaysKept

ExecutionLogDaysKept es otra configuración importante que define cuántos días se conservan los registros de ejecución de informes en el servidor. Estos logs son fundamentales para el análisis de rendimiento y la solución de problemas, ya que contienen información detallada sobre cada ejecución de informes. Ajustar esta configuración nos permite a los administradores balancear entre la retención de información suficiente para análisis detallados y la gestión eficiente del espacio de almacenamiento. Por defecto esta propiedad está establecida en 60 días, un periodo de retención más largo puede ser útil para auditorías y análisis históricos, sobre todo si tienes informes que se ejecutan sólo una vez al mes o menos. Por otro lado, un periodo más corto puede ayudar a optimizar el rendimiento del servidor. 

EnablePowerBIReportExportUnderlyingData

Por último, la configuración EnablePowerBIReportExportUnderlyingData controla si los usuarios tienen permiso para exportar los datos subyacentes de los informes de Power BI. Esta opción es crucial para mantener la seguridad y privacidad de los datos. Permitir la exportación puede ser necesario para usuarios que requieran analizar la información fuera de la plataforma, pero también puede suponer un riesgo si los datos son sensibles. Por ello, esta configuración debe ser ajustada con cuidado, asegurando que solo los usuarios adecuados tengan acceso a esta funcionalidad y que se cumplan las políticas de seguridad de la organización. 

Si me preguntáis por mi opinión, yo soy totalmente partidario de deshabilitar esta opción. Además, un abuso de la descarga de información en horas de mucha actividad de usuarios puede suponernos un verdadero quebradero de cabeza.

Seguridad a nivel de carpetas en Report Server

Llegamos a una de las principales diferencias entre Power BI Report Server y el servicio en la nube de Power BI. Mientras en el cloud tenemos Workspaces que sirven como entornos aislados colaborativos para que los equipos desarrollen contenido de Power BI al unísono. Después creamos aplicaciones para facilitar la entrega del contenido a los usuarios. Estos conceptos no existen en Power BI Report Server. En PBIRS tendremos que usar carpetas.

Las carpetas dentro de Power BI Report Server (y SSRS) se comportan como carpetas dentro de un sistema de archivos. La seguridad a nivel de carpeta se puede aplicar para restringir el acceso a todo el contenido de la carpeta. Además, al igual que un sistema de archivos, se puede crear una jerarquía de carpetas. Esto es diferente a la naturaleza aplanada de App Workspaces dentro del servicio Power BI. 

Gestión de los permisos

Estemos alojando informes en el servicio o en PBIRS, debemos realizar una planificación cuidadosa desde el principio para proteger adecuadamente su contenido. Normalmente, tiene sentido crear carpetas para diferentes departamentos o equipos de la empresa como, por ejemplo, ventas, contabilidad, marketing, etc…

Aunque en Power BI Report Server (PBIRS), también podemos definir la seguridad en elementos individuales (por ejemplo, un único informe), normalmente no es una práctica. En implementaciones grandes, podemos encontrarnos con decenas o cientos de informes y mantener individualmente los permisos sería una pesadilla. Del mismo modo tenemos que huir de los permisos a usuarios individuales y, siempre que sea posible, utilizar grupos de usuarios. Si llevamos esto a rajatabla, podremos proteger múltiples informes relacionados y habilitar su uso para un subconjunto de usuarios sin complicaciones. 

En la mayoría de los casos, también recomiendo que os ciñais a una estructura de carpetas plana. De este modo, no solo será más fácil proteger las carpetas, también PBIRS coincidirá lógicamente con la estructura plana de Workspaces en el servicio Power BI. Esto nos facilitará la tarea de migración o  transferencia del contenido de Power BI Report Server (PBIRS) al servicio Power BI en la nube si alguna vez queremos hacerlo.

Reutilizar un modelo de datos en Report Server

Una de las limitaciones de Power BI Report Server (PBIRS) frente al servicio de Power BI en la nube es la capacidad de utilizar un mismo modelo de datos para diferentes informes. Así, mientras que en Power BI en la nube todos nuestros informes pueden acceder a un mismo modelo, si tenemos 12 informes que usan el mismo modelo de datos, en Power BI Report Server (PBIRS) tendremos que mantener 12 copias del modelo de datos. Esto, no hace falta que os lo diga, es un problema a la hora de actualizar los modelos y puede generar una discrepancia de datos entre los informes, que, en el mejor de los casos, nos provocará una reprimenda por parte de los usuarios. 

Sin embargo, nosotros que somos DBAs y sabemos de bases de datos y, sobre todo, de servicios de SQL Server, sabemos que podemos aprovecharnos de las capacidades de SQL Server Analysis Services para almacenar nuestras bases de datos dimensionales y, desde los informes de Power BI simplemente acceder a ese único origen de datos compartido para todos los reportes.

Analysis Services es una excelente opción si ya tenemos una inversión en SQL Server y sus componentes de BI, que la tendremos si hemos licenciado PBIRS con la licencia de SQL Server Enterprise. Sin embargo, si estamos implementando Power BI Report Server gracias al licenciamiento de Power BI Premium, también podemos aprovechar los conjuntos de datos que residen en la capacidad Premium como modelos de datos reutilizables.

Podemos establecer una conexión desde nuestros informes de Power BI a un conjunto de datos Premium como si fuera un modelo de Analysis Services. Para ello, debemos asegurarnos de que nuestra capacidad Premium tenga habilitada la lectura en la configuración del extremo XMLA.

Conclusión

En resumen, Power BI Report Server (PBIRS) es una herramienta muy potente, que, si se configura y gestiona adecuadamente, puede convertirse en un pilar fundamental para la inteligencia de negocio en tu organización. Desde la configuración avanzada para habilitar funciones como «Mis informes» o controlar la exportación de datos subyacentes, hasta la gestión cuidadosa de la seguridad a nivel de carpetas y la reutilización de modelos de datos, podemos optimizar cada aspecto de PBIRS para alinearlo con las necesidades y políticas de nuestra empresa. Implementar estas buenas prácticas no solo mejorará el rendimiento y la seguridad de nuestro entorno de reportes, sino que también facilitará futuras migraciones al servicio Power BI en la nube, asegurándonos que nuestra infraestructura de BI está preparada para el crecimiento y el cambio.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Power BI, Rendimiento, 0 comentarios