SQL Server 2016: Roadmap de SQL Server Reporting Services…espectacular!!

Aunque ya lo he comentado en varios posts recientes en mi blog, cada vez que veo un nuevo artículo en el que se hace referencia a todo lo que viene en la nueva versión de Reporting Services (SSRS) en SQL Server 2016, más convencido y encantado estoy con la dirección y estrategia en Business Intelligence que Microsoft está tomando y que le va a llevar a marcar la pauta no solo en BI para la nube a través de Power BI, sino también para escenarios híbridos y para escenarios puramente OnPremises. Las últimas novedades anunciadas sobre SSRS 2016 y sobre todo el roadmap lo podéis ver en el siguiente post del equipo de SSRS:

http://blogs.technet.com/b/dataplatforminsider/archive/2015/10/29/microsoft-business-intelligence-our-reporting-roadmap.aspx

Entre los novedades del roadmap encontraremos:

• La esperada harmonización en la visualización de datos, de forma que la experiencia de usuario sea similar independientemente de si estamos en un escenario 100 % Cloud, Híbrido o 100 % OnPremises:

• SSRS es la solución para OnPremises, pero con un cambio radial y evolución con respecto a las versiones previas:

• Publicación de Informes de Power BI en SSRS.
• Experiencia móvil unificada para los tres escenarios comentados.

• Marcar el camino a la convergencia / simetría entre Cloud y OnPremises:

SQL Server 2016: Novedades en Reporting Services en la CTP 2.4!

Como comentaba en este post, y a pesar de que parecía que Power BI iba a ser el “killer” de SQL Server Reporting Services (SSRS), me he encontrado con la sorpresa de que en SQL Server 2016 tendremos importantes mejoras en SSRS que se traducirán en una modernización de esta plataforma a través de novedades que iremos viendo en sucesivas CTPs. En la CTP 2.4 nos encontraremos novedades como:

• Poder ubicar los parámetros del informe de la forma en que se requiera y no siempre en la misma línea o posición:

• El aspecto de los parámetros del informe en tiempo de ejecución (en el nuevo Report Builder por cierto) es el siguiente:

• Exportación a PowerPoint, simplemente necesario hoy en día:

• Impresión de informes en navegadores modernos eliminando la dependencia con controles Active X. Por ejemplo, la experiencia de impresión en Google Chrome es como sigue:

• El renderizador en HTML que ya incorporaba la CTP 2.3 se continua mejorando en la CTP 2.4

Referencias:

• http://blogs.technet.com/b/dataplatforminsider/archive/2015/09/30/sql-server-2016-community-technology-preview-2-4-is-available.aspx
• http://blogs.technet.com/b/dataplatforminsider/archive/2015/09/30/introducing-sql-server-2016-community-technology-preview-2-4.aspx
• http://blogs.msdn.com/b/sqlrsteamblog/archive/2015/09/30/more-reporting-services-enhancements-in-sql-server-2016-ctp-2-4.aspx
• https://msdn.microsoft.com/en-us/library/ms170438.aspx

SharePoint 2013: Integración con SSRS 2012 (I)!

Aunque, y es una opinión en base a mi experiencia, creo que la integración entre SRSS 2012 y SharePoint 2013 Public Preview no está 100 % fina (lo que me sorprende teniendo en cuenta lo bien que se integran SharePoint 210 y SSRS 2012), en este primer post vamos a ver como se realizaría dicha integración:

• Lo primero a tener en cuenta es que necesitas descargarte la CTP 3 del SP1 de SQL Server 2012…con lo que me imagino que al “juntarlo” con una versión beta de SharePoint 2013, tampoco nos permita exigir mucho en lo que a la integración “fina” que comentaba.
• A partir de aquí, y si partimos de una instalación de SharePoint 2013 Public Preview ya hecha como es mi caso, lo que haremos es agregar características de SQL Server 2012 a una instancia existente o bien a una nueva que nos creemos. Lo más importante aquí es elegir entre las mismas Reporting Services – SharePoint y Reporting Services Add-In for SharePoint Products.
• A partir de aquí, seguimos el proceso habitual de instalación que concluye con todos los “indicadores” en verde para los nuevos elementos agregados a SQL Server 2012.
• Si todo ha ido bien, en la gestión de Aplicaciones de Servicio en la Administración Central de SharePoint podremos crear una Aplicación de Servicio de SQL Server Reporting Services.

• Tendremos que especificar parámetros como el nombre de la Aplicación de Servicio, si usar un pool de aplicaciones existente o crear uno nuevo, …
• … el prefijo para el nombre de las BDs de la Aplicación de Servicio (se crean 3), las Aplicaciones Web a las que se va vincular la Aplicación.
• Una vez concluye el proceso de creación, comprobamos que la nueva Aplicación aparece en el listado. Por supuesto, todo este trabajo lo podemos hacer con los correspondientes comandos PowerShell.

• Toca comprobar que todo ha ido bien. A nivel de BD, tendremos 3 BDs asociadas a la Aplicación de Servicio de SQL Server Reporting Services:
  • La propia de la aplicación que contendrá los informes publicados.
  • La temporal para cuestiones de procesamiento.
  • La de alertas para guardar información relativas a alertas de datos definidas en informes.
• A nivel de administración de la Aplicación de Servicio, tendremos disponible la correspondiente página que da acceso a las distintas opciones de configuración.
• Por ejemplo, desde la página “Configuración del sistema” podremos especificar parámetros relativos a timeouts en la ejecución de informes, sesiones de usuario, etc.

• La página “Configuración de correo electrónico” nos permite indicar los parámetros a utilizar por la funcionalidad de alertas de SSRS.
• La página “Aprovisionar suscripciones y alertas”, nos permite configurar como usar el Agente de SQL Server para suscripciones y alertas.
• A nivel de Colección de Sitios veremos que tenemos una serie de opciones de configuración de la integración con SSRS.

• Finalmente, a nivel de Colección de Sitios simplemente comprobamos que está activa la característica de integración.

Referencias:

• http://blog.cloudshare.com/2012/09/05/how-to-install-sharepoint-server-2013-preview-with-sql-server-2012-sp1-ctp3-ssrs-ssas-and-powerpivot-and-powerview/
• http://www.jamesserra.com/archive/2012/08/sql-server-2012-and-sharepoint-2013-installing-on-a-virtual-machine/

SharePoint 2010 y SSRS 2012: Trabajo con suscripciones y alertas (III)!

Siguiendo con la serie de posts sobre trabajo con suscripciones y alertas cuando tenemos una integración entre SharePoint 2010 y SSRS 2012, en esta ocasión vamos a ver como configurar alertas personalizadas para un informe de manera que cuando haya un cambio en los datos del mismo nos llegue el correspondiente aviso. Pero antes, os recuerdo los artículos previos de la serie:

• SharePoint 2010 y SSRS 2012: Trabajo con suscripciones y alertas (I)!
• SharePoint 2010 y SSRS 2012: Trabajo con suscripciones y alertas (II)!

Para carear una alerta que se dispare ante cambio de datos de un cierto informe:

• En el visor de informe, pulsamos sobre Actions –> New Data Alert.
• De esta forma, se muestra una ventana que es una aplicación Silverlight que nos permite configurar las alertas.
• Para configurar una alerta, tenemos que seleccionar una región de datos válida del informe y a continuación definir la condición de generación de la misma. Por ejemplo, que la información de una cierta caja de texto tenga un valor superior a un cierto valor fijo. A continuación configuramos la frecuencia de envio de la alerta, la dirección de envío de la alerta, el asunto y una descripción para la alerta.

• Para visualizar las alertas de un cierto informe, nos vamos a la biblioteca dónde está almacenado y a través del menú contextual pulsamos sobre la opción de administración de alertas del informe.
• A continuación se mostrarán el listado de alertas disponibles para dicho informe.

SharePoint 2010 y SSRS 2012: Trabajo con suscripciones y alertas (II)

Siguiendo con la serie de posts sobre como trabajar con alertas y suscripciones cuando tenemos una integración de SharePoint 2010 y SSRS 2012, en esta ocasión vamos a crear de forma efectiva una suscripción:

• Lo primero que tenemos que hacer es configurar el informe para el que queremos crear una suscripción para que utilice una cuenta de ejecución almacenada en BD. Accedemos a la lista de informes y editamos el informe en cuestión con Report Builder 3.0.
• Dentro de Report Builder 3.0, editamos la fuente de datos utilizada y la configuramos para que use un login de SQL Server en lugar de autenticación Windows. Guardamos los cambios en el informe.
• De vuelta al informe ejecutándose en un sitio de SharePoint, para crear una suscripción o una alerta no tenemos más que pulsar Actions –> Subscribe

• En la página que se muestra a continuación podremos crear la suscripción. Lo primero que tenemos que elegir es el tipo de entrega del informe que se genere en la suscripción. Como vemos, tenemos cuatro tipos de entrega: Windows File Share, E-Mail, SharePoint Document Library y Null Delivery Provider.
• En este caso, elegimos E-Mail como tipo de entrega y configuramos los parámetros para que el informe que se genere en un cierto formato sea entregado en un buzón de correo. Cómo veis, tenemos bastantes parámetros con los que jugar: dirección a la que enviar el informe generado, el asunto, el formato de entrega, etc.
• Lo siguiente que tenemos que hacer es configurar cuando entregar el informe generado de acuerdo a una cierta programación.

• Si todo se ha configurado de forma correcta, veremos la nueva suscripción añadida en el listado de suscripciones.
• Y comprobaremos que el informe se recibe de forma correcta en el buzón de correo electrónico especificado.

SSRS 2008 R2: Como crear parámetros con comportamiento en cascada a un informe!

Una cuestión clásica cuando se crean informes de SQL Server Reporting Services (SSRS) es la relativa a como añadir parámetros en cascada, es decir, qué la información de filtrado de un cierto parámetro dependa del valor seleccionado o indicado en otro parámetro. Para SSRS 2008 R2, este artículo de MSDN explica como realizar dicha configuración. Como veis, la idea pasa por usar query parameters y meter en la consulta del parámetro la dependencia con el parámetro de inicio que fuerza el comportamiento en cascada.

   1: SELECT DISTINCT Subcategory FROM <table> 

   2: WHERE (Category = @Category)

SharePoint 2010: Migración de Reporting Services nativo a modo integrado con SharePoint!

Como sabéis, cuando trabajamos con SQL Server Reporting Serives (SSRS) tenemos dos modos:

• El modo nativo, en el que todo informe que creemos y publiquemos en el servidor de SSRS será administrado, gestionado y visualizado desde el portal Report Manager.
• El modo integrado con SharePoint, en el que la administración, gestión y visualización de informes se realiza desde los sitios de SharePoint en los que vayamos publicando los informes.

Pasar de un modo a otro es sencillo a través de la herramienta de configuración de SSRS, pero ¿Qué pasa cuando queremos migrar artefactos de SSRS publicados en modo nativo a modo integrado? La respuesta la tenemos en este estupendo artículo  en el que se introduce la Reporting Services Migration Tool para facilitar dichas migraciones.

SharePoint 2010: Integración con SSRS 2008 y SSRS 2008 R2 (VIII)!

Siguiendo con la serie de artículos en torno a la integración entre SharePoint 2010 y SQL Server Reporting Services (SSRS) en esta ocasión quería tratar un tema que necesitaremos por ejemplo para poder crear suscripciones: crear una cuenta de ejecución de informes que resida en SQL Server. Antes de empezar, os remito al último post de la serie que a su vez tiene un enlace a todos los artículos relativos a esta integración que se han publicado hasta ahora: SharePoint 2010: Integración con SSRS 2008 y SSRS 2008 R2 (VII)!

Para crear una cuenta de ejecución de informes a nivel de BD:

• En primer lugar, es necesario crear a nivel de BD un login con los privilegios mínimos que nos permita definir orígenes de datos de SQL Server usando dicho login. Para añadir el login, tenemos dos posibilidades:
  • A través del SQL Server Management Studio.
  • Creando dicho login a través de T-SQL de acuerdo al siguiente script:

   1: --Añadimos el usuario en la master

   2: use master

   3: exec sp_droplogin @loginame='ReportExecution'

   4: exec sp_addlogin @loginame='ReportExecution', @passwd='pass@word1'

   5:  

   6: --En AdventureWorksDW

   7: use AdventureWorks2008

   8: if exists(select * from sysusers where name='ReportExecution')

   9:     exec sp_dropuser @name_in_db='ReportExecution'

  10: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'

  11:  

  12: --En msdb

  13: use msdb

  14: if exists(select * from sysusers where name='ReportExecution')

  15:     exec sp_dropuser @name_in_db='ReportExecution'

  16: --add the users to the databases and give them permissions

  17: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader' 

  18:  

  19: --En ReportServer

  20: use ReportServer

  21: if exists(select * from sysusers where name='ReportExecution')

  22:     exec sp_dropuser @name_in_db='ReportExecution'

  23: --add the users to the databases and give them permissions

  24: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'

Nota: Si la ejecución del T-SQL da algún tipo de error, se recomienda ejecutar los bloques relativos a cada BD en la que se está añadiendo el login de forma independiente.

• Una vez que hemos creado el origen de datos, nos aseguramos que nuestro servidor de SQL Server permite autenticación Windows y SQL Server ya que por defecto puede ser que esté configurado para utilizar únicamente autenticación Windows.
• Para realizar esta configuración nos conectamos al servidor de BD dónde está configurado SSRS (y también dónde estén las BDs fuente de los informes) con SQL Server Management Studio, hacemos clic con el botón derecho del ratón sobre el nombre del servidor y pulsamos la opción Propiedades o Properties.
• En la ventana que se abre, nos vamos a la sección “Seguridad” o “Security” y marcamos la opción relativa al uso de autenticación Windows y SQL.
• Pulsamos OK, de manera que se mostrará un mensaje informativo indicando que para que los cambios tenga lugar será necesario reiniciar el servicio de SQL Server.
• Para reiniciar el servicio de SQL Server, nos vamos a la herramienta de configuración de SQL Server y simplemente re-iniciamos el servicio correspondiente.

• Comprobamos a través de SQL Server Management Studio que accedemos a BD mediante autenticación SQL y especificando las credenciales del login de BD creado.
• Creamos un origen de datos usando el login de BD creado. Por ejemplo, en Report Builder 3.0.
• Comprobamos que la conectividad a la BD es correcta y generamos un primer informe de ejemplo.

• Por ejemplo, un informe creado con esta forma de autenticación y plenamente operativo es el siguiente.
• El mismo informe vemos que se visualiza en un sitio de SharePoint de forma correcta.sdf

Y hasta aquí llega este nuevo artículo en torno a la integración de SSRS y SharePoint 2010.

SharePoint 2010: Integración con SSRS Denali (I)!

Como sabéis, desde hace unos días tenemos disponible la CTP3 de SQL Server Denali una de cuyas novedades más importantes es las novedades que trae en lo que a integración de Reporting Services con SharePoint se refiere. Si queréis ver estas novedades, es necesario que sigáis una serie de pasos relativos a como configurar esta integración. Por suerte, ya tenemos varios recursos relativos a como configurar la integración de Reporting Services de SQL Server Denali con SharePoint 2010:

• Post de Alan Koo en el que paso a paso nos detalla la integración: Instalación de SQL Server “Denali” CTP3 en un solo servidor
• Checklist en MSDN respecto a los pasos y requisitos para la integración: http://msdn.microsoft.com/en-us/library/hh231687%28v=sql.110%29.aspx
• Documentación en Microsoft TechNet sobre la integración: http://technet.microsoft.com/en-us/library/gg492276%28SQL.110%29.aspx
• Algunos tricks necesarios por si tenéis problemas a la hora de configurar la aplicación de servicio de Reporting Services en SharePoint 2010: http://blogs.msdn.com/b/prash/archive/2011/07/01/do-not-see-the-ssrs-shared-service-in-ca-after-installing-ssrs-quot-denali-quot-sharepoint-mode.aspx

SSRS: PivotViewer Extension for Microsoft SQL Server Reporting Services!

Como sabéis, la plataforma estándar de Microsoft para facilitar la creación, despliegue y visualización de informes es SQL Server Reporting Services (SSRS) que además se integra a la perfección con SharePoint 2010 y que por cada nueva versión añade nuevas capacidades. En este sentido, en los próximos meses verá la luz el PivotViewer Extension for Microsoft SQL Server Reporting Services. Se trata de una extensión del control Silverlight PivotViewer que dota al usuario de una nueva experiencia interactiva a  la hora de visualizar informes, realizar análisis comparativos, ver tendencias, etc.

Podéis descargaros la CTP2 del  PivotViewer Extension for Microsoft SQL Server Reporting Services desde este enlace. Tened en cuenta también que es necesario disponer de SharePoint Server 2010 instalado así como de SQL Server PowerPivot.