Jordi Rambla Blog

Como ya es sabido, las últimas versiones de Crystal Reports han simplificado el clásico problema de la instalación de CR junto con nuestra aplicación por la vía de centralizar todo en los merge modules. Esta estrategia ha funcionado correctamente hasta al momento, sin embargo, con la absorción de la web de Business Objects en la web de SAP, la cosa se ha complicado de nuevo. Casi todas las URL que apuntaban a alguna parte de la web de BO, se redirigen, automáticamente, a una página centralizada en la que advierte del cambio de web y de la política actual de soporte de SAP para los clientes de BO.

Esa página no aporta suficiente información para que los desarrolladores que buscan la nueva versión de los merge modules los localicen, de manera que parece que la confusión se está apoderando de la comunidad.

Ahora los merge modules se han de localizar en la zona de descargas para BO de SAP que (¿aún?) no está redirigida. http://resources.businessobjects.com/support/additional_downloads/runtime.asp o bien en el área de descarga, cuya RL es http://service.sap.com/sap/bc/bsp/spn/bobj_download/main.htm y que solicitará un certificado, paso que puede obviar haciendo clic en "Cancelar". Una vez en la pantalla de búsqueda, aplique un filtro por producto "Crystal Reports", versión "2008", tipo de software "Utility".

PPS-Monitoring es un producto poco ortodoxo en lo que a configuración se refiere. Parece que se ha concebido con la idea de fire-and-forget, es decir, instalarlo y yo no tocar su configuración nunca más. De manera que si te enfrentas con una instalación en la que hay varias "instancias" del producto y no dispones de una documentación de instalación, no tienes ninguna utilidad de configuración a la que acceder para averiguar donde (en qué servidores) residen los distintos componentes del producto o a dónde van a parar los elementos que se envían al servidor de PPS Monitoring.

Recientemente me encontré en una situación similar en un cliente y pude descubrir que la configuración del repositorio SQL Server al que se remiten los elementos que diseñamos en un espacio de trabajo de Dashboard Builder se detalla en el archivo C:\Archivos de programa\Microsoft Office PerformancePoint Server\3.0\Tools\MonitoringConfiguration\MonitoringConfig.xml.

Dentro de este archivo, al final, hallaremos la entrada:

<ConfigUnit ID="WebParts" InstanceID="PPSMonitoring_1" ConfigState="Installed" SHAREPOINT_SITE="http://XXXXXXX:16706/" SQL_DATABASE_SERVER="XXXXXXX" MONITORING_DATABASE="PPSMonitoring" />

No es un problema angustioso, pero cuando quieres comprobar que los duendes no están jugando contigo, reconforta poder comprobar que los elementos se envían a donde uno creía.

Penton Media acaba de hacer público un white paper que escribí para ellos hace unos meses. Tiene un total de 13 páginas y está escrito en inglés y trata de explicar la utilidad técnica y/o empresarial de las distintas funcionalidades de Reporting Services 2005.. El documento puede encontrarse aquí (requiere registro).

Por mi mala cabeza, no añadí una entrada al blog anticipando mi participación en el Summit 2008 de Solid Quality. En este evento, celebrado estos días en Madrid, he impartido y/o participado en las sesiones relativas a:

• Reporting Services 2005 y MDX (con Salvador Ramos)
• Introducción a PerformancePoint Server Monitoring (con Pablo Ahumada)
• Dashboards avanzados con PerformancePoint Server Monitoring
• Novedades de Reporting Services 2008 (diseño) (con Javier Torrenteras)
• Novedades de Reporting Services 2008 (arquitectura)

Quizá la próxima vez mi cabeza esté más predispuesta...

He aprovechado la funcionalidad de Connect de Microsoft (http://connect.microsoft.com) para añadir algunas sugerencias para Reporting Services 2008. He comprobado que ninguna de ellas está incorporada en la CTP 6 (Febrero). Tengo algunas más que iré publicando en el blog para no aburrir.

He sugerido tres cosas, sin ningún orden de importancia:

1. Disponer de plantillas de report autoactualizables: En SSRS es posible crear plantilas de informe, pero estas son de "usar y olvidar". Si hemos creado una plantilla y a partir de esta hemos creado un informe, modificar la plantilla posteriormente no modifica el informe. Es comprensible que ningún fabricante se moje a mantener una funcionalidad tal; sin embargo, lo que en Crystal Reports se resuelve usando subreports en la cabecera y/o pie del informe, no se puede hacer en SSRS por la imposibilidad de poner subreports en esas secciones.
2. Cambiar el botón por defecto en la página Crear Carpeta: Cuando creamos una carpeta, el botón predeterminado es "Cancel", de manera que si tras teclear un nombre, y quizá una descripción, se te ocurre pulsar Intro, se pierde lo que has tecleado. Si, por contra, el botón en OK, no pasa nada grave si creas una carpeta sin querer, la borras y santas pascuas.
3. Disponer de la lista de informes vinculados que dependen de un informe en particular: Los informes vinculados son una gran funcionalidad, sin embargo, hoy por hoy no hay una forma fácil de saber que reports están vinculados con un report "maestro". De manera similar, sí que podemos saber que reports dependen de un data source o de una programación compartida.