Después de algún tiempo sin pasar por el blog por motivos varios –largo número de eventos, carnavales, nevada y consecuente gripazo- estoy de vuelta con las pilas recargadas para acercaros las novedades que he podido saborear en la plataforma Azure.
El fin de semana pasado me llegó por fin la invitación para acceder a la CTP de SQL Azure Reporting (Customer Technology Preview, todavía ni es Beta), fase en la que se ofrece acceso limitado a la plataforma como primera toma de contacto a fin de obtener feedback sobre el producto antes de lanzarlo al mercado.
¿Qué es SQL Azure Reporting?
Es la tecnología capaz de generar informes ricos sin tener que mantener una infraestructura, permitiendo usar las mismas herramientas de desarrollo que estás acostumbrado a usar para subir informes a la nube.
No hay necesidad de administrar o mantener una infraestructura separada para la generación de informes, lo que conduce a costes más bajos y menos complejidad. Los clientes podrán acceder a los informes desde el portal de SQL Azure, a través del navegador o desde nuestras propias aplicaciones.
¿Para qué se usa SQL Azure Reporting?
Hay diversos escenarios, entre los que cabe destacar:
- Generar informes de un datawarehouse sin necesidad de construir y gestionar una plataforma de presentación propia
- Crear informes robustos y fáciles de leer y ponerlos disponibles directamente en tus aplicaciones o vía navegador
- ¡Aprovecha la potencia de la nube! Mantén tus datos seguros mientras ofreces acceso a incluso más usuarios
¿Cuáles son las características principales?
- Desarrollo de informes a través de Business Intelligence Design Studio (BIDS) o Report Builder, permitiendo realizar informes con características avanzadas: mapas, gráficos, indicadores, etc.
- Permite exportación a varios formatos, como Excel, Word, HTML, PDF, XML, CSV y feeds ATOM
- Escalabilidad y flexibilidad para demanda elástica, permitiendo aumentar o disminuir la capacidad de la plataforma según los requerimientos con alta disponibilidad y tolerancia a fallos de serie
¿Hay diferencias con SQL Server Reporting Services?
Sí, como también las hay entre SQL Server y SQL Azure. En este enlace hay una tabla rápida de comparación entre ambas plataformas: Comparación entre SQL Azure Reporting y SQL Server Reporting Services.
Comenzando a trastear con la CTP…
No sé si lo he pillado en un momento algo más avanzado que en su inicio, pero a mi parecer está bastante a la altura para ir hablando de Beta –recuerdo que con la CTPs de Windows Azure la herramienta más utilizada era el Notepad.
Una vez que recibes el ID de invitación, se asocia a una suscripción –para solicitar acceso a la CTP basta seguir las instrucciones dentro del portal de Windows Azure y esperar a que te toque la lotería. En esta fase CTP es muy importante ubicarlo en una suscripción donde nuestro servidor SQL Azure esté en South Central US si no queremos llevarnos una sorpresa en la factura durante las pruebas:
IMPORTANT DATA TRAFFIC NOTICE
Please note that the SQL Azure Reporting CTP is currently only hosted in our South Central US datacenter – we strongly recommend that you host any servers and databases you might use for your reporting testing needs at this datacenter. You will be charged for bandwidth usage for data transfers to/from the South Central US datacenter should you host your data that you report against outside of this datacenter. Also, co-locating with the service will provide optimal performance.
De este modo, hay que dirigirse al portal de Windows Azure, y en la sección “Reporting” pulsar sobre el botón de despliegue del servicio y seleccionar con cuidado la suscripción a la que queremos ligar la CTP. Cuando el proceso termina, tenemos ya nuestro servidor de informes listo para ser usado.
¿Y ahora? ¿Cómo comenzamos a trastear si sólo veo una opción que pone “Reset Password”? Paciencia, pulsemos el enlace “Getting Started with Azure Reporting”
Una vez que le hemos echado una lectura rápida al contenido (por ahora sólo hay 6 páginas de documentación, y donde se puede ver más actividad es en los foros), el siguiente paso para realizar una prueba de concepto es descargar los ejemplos desde Code Gallery en MSDN:
Instalar el data warehouse de AdventureWorks en Windows Azure
Una vez descargada la herramienta de instalación del Dataware AdventureWorks LT para Windows Azure, realizamos los pasos siguientes:
- Eliminar cualquier base de datos de ejemplo de data warehouse de Adventureworks Light (LT) previa
- Iniciar una línea de comandos con privilegios de administrador
- Ubicarse en la carpeta donde se han descomprimidos los archivos de instalación
- Entrar en la subcarpeta AdventureWorks2008R2AZLT
- Ejecutar el comando siguiente:
buildawltaz.cmd tcp:nombreservidor usuario contraseña
Con esta acción iniciamos el script de inicialización del esquema de la base de datos y la carga de los datos de prueba. Como en cualquier upload, aquí ayuda mucho el que lo puedas realizar desde una línea con buen caudal de subida, por ejemplo en una máquina de desarrollo alquilada en un proveedor de IaaS 
Aquí tenéis un vídeo de cómo realizar esta tarea paso a paso:
Desplegar informes de ejemplo en SQL Azure Reporting
Una vez que hemos descargado los informes de ejemplo, el siguiente paso es subirlos para ponerlos disponibles en la plataforma de Azure. Para ello realizamos los pasos siguientes:
- Abrir el proyecto con Visual Studio 2008 (según la documentación VS2010 aún no está soportado aunque en la captura de pantalla que se ve en este enlace parece lo contrario, cosas de CTPs y documentación en construcción)
- Para realizar una vista preliminar de los informes antes de desplegarlos en Azure, editamos la cadena de conexión para apuntarlos a nuestra base de datos en SQL Azure, haciendo doble click sobre los dos “Shared Data Sources” (fijaos que el tipo de conexión es Microsoft SQL Azure) y actualizamos los credenciales (no pongais en el nombre de usuario el “@nombreservidor” porque os dará un problema de conexión en producción, poned sólo el nombre de usuario)
Para desplegar los informes, en las propiedades del proyecto, establecemos el valor de la propiedad TargetServerURL a la URL de nuestro servidor de informes de SQL Azure. Los datos de la URL está en la sección de Reporting del portal de Windows Azure (poniéndole por delante https:// y la coletilla “/reportserver”)
Finalmente, desplegar el proyecto a través del menú “Build>Deploy”, donde finalmente nos solicita los credenciales para acceder al servidor de informes (¡de ahí la opción de “Reset Password”!)
Ver los informes desplegados en el servidor de informes de Azure
Una de las formas más rápidas de examinar los informes es a través del mismo servidor de informes. Para ello, nos dirigimos a la misma URL que introdujimos en la fase de despliegue e introducimos los credenciales en una pantalla super-molona-requeteguay-delamuerte:
Navegando por los informes, podemos comprobar su correcto funcionamiento:
¿Qué más puedo hacer?
La lista de cosas que se pueden hacer a partir de aquí son innumerables, gracias a que se pueden incrustar informes dentro de nuestras propias aplicaciones web o interactuar con el servicio SOAP disponible.
En este enlace tenéis más información de cómo hacer los primeros pinitos programáticamente con el Report Server en la nube.
A mí ya se me está ocurriendo el desarrollo de un módulo para DotNetNuke para visualizar los informes dentro del mismo portal.
¿Y a tí? ¡1,2,3…responda otra vez!
Hoy toca una de cal con Entity Framework 4. Y es que trabajar con un entorno de desarrollo distinto del que luego te puedes encontrar en producción tiene su riesgo (que levante la mano cuántos tienen instalado Visual Studio sobre Windows Server). Una solución es trabajar con máquinas virtuales que simulen al máximo el entorno que te vas a encontrar en producción, pero muchas veces es inviable por los recursos y el tiempo necesario para gestionar todas las combinaciones que tenemos en nuestros clientes.
).
El lunes pasado 
