SAP reduce las herramientas cliente de SAP BusinessObjects BI Suite

El amplio abanico de herramientas que ofrece la plataforma de Business Intelligence de SAP, ha significado un generador de dudas para los usuarios finales, más de una decena de componentes posibles y más de una alternativa en las distintas capacidades BI, ha dado lugar a que el usuario cuestione si estaba haciendo la elección correcta.


El amplio abanico de herramientas que ofrece la plataforma de Business Intelligence de SAP, ha significado un generador de dudas para los usuarios finales, más de una decena de componentes posibles y más de una alternativa en las distintas capacidades BI, ha dado lugar a que el usuario cuestione si estaba haciendo la elección correcta.

Simplificación del portfolio Business Intelligence de SAP, ahora denominado SAP BusinessObjects BI Suite

Bajo la máxima “Run Simple”, SAP, en los últimos meses, ha ido aclarando el mensaje en cuanto a su propuesta de BI, a la que denomina por ahora, SAP BusinessObjects BI Suite. SAP señala que desea “ofrecer un menor número de herramientas de BI” y “simplificar la cartera de herramientas de BI, respetando las inversiones que hubieran realizado los clientes”.

SAP Design Studio la herramienta de Dashboarding, en camino de cubrir las funcionalidades de Xcelsius

De este modo, las capacidades BI de SAP quedarían representadas por las siguientes herramientas cliente:

  • Reporting Analítico. Esta capacidad de BI queda representada por el indiscutible e imprescindible Web Intelligence (WebI). En cuanto al veterano Desktop Intelligence se seguirá brindando compatibilidad, pero para cualquier nuevo proyecto la alternativa debería ser WebI.
  • Reporting Operativo y para Impresión. La recomendación es SAP Crytsla Reports for Enterprise (CRE o también referida como la versión Java), al margen queda la clásica versión denominada Crystal Reports 2013 o Crystal Reports 2011, seguirán siendo soportadas, pero la recomendación de SAP es que para nuevos proyectos se utilice CRE, e inclusive, se debería valorar proyectos de migración.
  • Cuadros de mando. El mensaje fue transmitido hace algún tiempo, y no ha variado, la herramienta para nuevos proyectos de cuadros de mando o tableros debería ser Design Studio, en detrimento de Xcelsius (ahora denominado Dashboards), a pesar, como señala SAP, que Design Studio cubre el 70% de la funcionalidades de Xcelsius. A futuro, como en todos los casos, SAP ofrece compatibilidad para los trabajos actuales con los componentes que ha decidido interrumpir su evolución.
  • Descubrimiento y Análisis. Lumira (antes Visual Intelligence) surgió como una herramienta de visualización pero al final ha provocado la extinción del pesado mastodonte que significaba BusinessObjects Explorer, hecho muchas veces negado por SAP. Lumira ha evolucionado en muchos aspectos, además de su mayor integración con otros componentes de BI, ofrecerá capacidades predictivas.
  • Integración con MS Office. La integración con los productos MS Office, en especial con MS Excel, es responsabilidad de Analysis for MS Office, a estas alturas no debería quedar duda que BEx Analyzer es mantenido por compatibilidad y ya no tendría mayor evolución.

SAP Crystal Reports Enterprise como herramienta de reporting operativo e impresión, en lugar de la versión clásica 2013 o 2011

Referencia: SAP.com

El parámetro CLEAN_UNIVERSE, otro “gran desconocido” en BI4


Parametros por defecto de un Business Layer en IDT 4.1Por actividades propias de la edición de universos de SAP BusinessObjects BI, agregando o eliminando los distintos elementos que lo conforman, estas capas semánticas pueden alcanzar un gran tamaño en el transcurso del tiempo. Si se elimina definiciones de objetos en un universo, podremos observar que apenas cambia de tamaño, porque al parecer los objetos eliminados no se retiran físicamente, sólo se “ocultan”.

Para solucionar el problema de tener universos “pesados”, se introdujo en la versión XI 3.1 actualización Fix Pack 5.1, el parámetro CLEAN_UNIVERSE para que “comprimiese” los universos (ver nota 1726463). Al parecer, este parámetro sólo estaba pensado para el antiguo diseñador de Universos UNV, Universe Designer (o simplemente Designer).

Para Information Design Tool, el diseñador de universos UNX de la 4.0/4.1 la información sobre este parámetro es casi inexistente y la poca que hay es contradictoria. Por un lado se señala que no es necesario utilizar este parámetro porque los universos (Business Layer) son guardados de la manera más óptima y por otro lado, hay testimonios de usuarios que señalan haberlo utilizado, luego de los cual sus universos se habrían dañado (ver foro sobre el tema). Hasta no contar con documentación oficial, no recomendamos su uso.

Tamaño ideal de un Universo de SAP BusinessObjects BI

Por “fastuoso” que pueda resultar el nombre de la capa semántica de SAP BusinessObjects BI, un “universo” no necesariamente debe pretender cubrir todas las necesidades de análisis de información que tuviese una organización.


Por “fastuoso” que pueda resultar el nombre de la capa semántica de SAP BusinessObjects BI, un “universo” no necesariamente debe pretender cubrir todas las necesidades de análisis de información que tuviese una organización.

Recuento de objetos de un universo UNX en IDT a través del Business Layer (BI4)Un “universo”, el cual cumple el esencial papel de “interprete” o “puente” entre las estructuras técnicas de los datos y los usuarios de negocio, debería reflejar los elementos de análisis de un proceso de negocio o procesos complementarios, que no necesariamente son de “propiedad” de una determinada área o principal interés para todos los usuarios de una organización.

Las posibilidades que brindan herramientas como Web Intelligence (WebI) de diseñar documentos en base a más de una consulta, dónde cada consulta puede utilizar un proveedor de datos distinto (los cuales podrían ser diferentes universos), no justifica el diseño de universos mastodónticos.

¿Cuál es el tamaño ideal de un Universo?

Las buenas prácticas de SAP señalan que un universo no debería superar los 200 objetos. Si estamos utilizando “Information Design Tool” (IDT), en la capa del “Business Layer” podríamos obtener el recuento de objetos. Un universo demasiado grande podría ocasionar los siguientes contratiempos:

  • Problemas de rendimiento y memoria
  • Dificultad de navegación y uso
  • Complejidad en el diseño de la seguridad, más aún si se desea realizar a nivel de objeto.

Utilizando IDT de BI4, salvado por un backup

Al estar usando intensivamente Information Design Tool (IDT) de SAP BusinessObjects BI 4.1 SP02 patch 01 (la penúltima actualización disponible) vemos con satisfacción varios pequeños detalles que se han ido incluyendo poco a poco en cada una de sus actualizaciones, detalles que en su conjunto facilitan el trabajo con esta herramienta para diseñar los denominados Universos, la capa semántica de BI4, fundamental para un BI Self Service.


Al estar usando intensivamente Information Design Tool (IDT) de SAP BusinessObjects BI 4.1 SP02 patch 01 (la penúltima actualización disponible) vemos con satisfacción varios pequeños detalles que se han ido incluyendo poco a poco en cada una de sus actualizaciones, detalles que en su conjunto facilitan el trabajo con esta herramienta para diseñar los denominados Universos, la capa semántica de BI4, fundamental para un BI Self Service.

Así como vemos muchas mejoras, nuestro “éxtasis” por esta plataforma de BI no nos ciega para identificar cosas que esperábamos superadas, más aún cuando encontramos notas que así lo señalan. Debemos reconocer que sentimos algunos minutos de “pánico” cuando al validar la integridad de nuestro diseño de Universo observamos varios errores con un texto similar al siguiente: “The calculated column referenced in the table contains ivalid sql” y al tratar de editar la gran cantidad de columnas calculadas que habíamos definido recibíamos como respuesta “Failed to edit calculated column”.

No tenemos certeza absoluta del origen del problema, pero este se produce en la denominada Data Foundation dónde observaremos que varias tablas del esquema no figuran como seleccionadas en la lista de tablas de la conexión, por lo que todos los alias y columnas calculadas generan errores al validar el “business layer” o la “data foundation”.

Después de probar varias opciones nos resignamos a recurrir a una copia seguridad, pero sólo restituimos, en otro proyecto, el fichero .dtx del «data foundation», conservando el fichero .blx del “business layer” y el acceso directo de la conexión. Otra opción hubiera sido recuperar la versión publicada en el repositorio de la plataforma, para luego realizar los cambios que estuviesen faltando.

A pesar del tiempo transcurrido SAP BusinessObjects BI nos puede seguir dando algunas sorpresas no muy gratas, por lo que en la fase de desarrollo o diseño de un proyecto de BI resulta muy aconsejable las copias de seguridad diarias.

Cómo fluyen los datos en QlikView

Tenemos muy clara nuestra elección de plataforma de Business Intelligence, pero vemos necesario conocer las principales características de funcionamiento de otras alternativas, como puede ser QlikView, del cual no dudamos sus bondades, tales como la tecnología asociativa (rutas de análisis de los datos que requiera el usuario) y el procesamiento de datos en memoria.


Tenemos muy clara nuestra elección de plataforma de Business Intelligence, pero vemos necesario conocer las principales características de funcionamiento de otras alternativas, como puede ser QlikView, del cual no dudamos sus bondades, tales como la tecnología asociativa (rutas de análisis de los datos que requiera el usuario) y el procesamiento de datos en memoria.

En el documento de referencia encontramos una breve explicación del modo en que fluyen los datos a través de QlikView, que nos permitimos compartir:

  1. Se comienza con los datos fuente. QlikView puede extraer datos de una gran variedad de fuentes, incluyendo ODBC, OLE DB, XML y archivos planos (Excel, CSV, etc). También existen conectores para grandes aplicaciones empresariales como SAP, hasta redes sociales como Twitter.
  2. Los datos se envían a QlikView usando un script de carga. Este script se puede usar para extraer, transformar, y cargar datos al modelo de datos en memoria o para guardarlos a archivos físicos intermedios en disco, en formato QVD.
  3. Los datos de la base de datos en memoria se guardan en formato desagregado, lo que significa que todas las agregaciones y cálculos se hacen al momento que lo solicita el usuario. Esto simplifica el modelado de datos en QlikView, ya que no hay necesidad de crear tablas resumidas por separado.
  4. Las selecciones que hace el usuario se propagan automáticamente a todo el modelo de datos y estos cambios son reflejados por el motor de presentación de QlikView.
  5. Las aplicaciones QlikView se pueden presentar en diferentes clientes.

Referencia: ISBN 978-1-78217-423-3