17.7. Conclusiones de la experiencia BI utilizando Open Source. Evaluación final de Pentaho BI CE.

Durante los dos ultimos meses he estado peleandome con Pentaho y su plataforma BI, y no puedo negarlo, mis sensaciones con la plataforma no han sido buenas. Entiendo que estamos hablando de un producto OpenSource, gratuito, elaborado con la colaboración desinteresada de mucha gente. Pero el hecho de tener que estar continuamente tocando ficheros, tener  que repetir las mismas acciones con cada herramienta que utilizamos, tener que tener conocimientos sobre aspectos que quedan fuera de lo que es el Business Intelligence en sí y que se parecen mas a una artesanía tecnológica no me han terminado de convencer. Además, la documentación sobre muchos aspecto es muy floja y no queda más remedio que la prueba/error y la experimentación para conseguir que muchas cosas funcionen. Cuando se producen errores, también es complicado hacer una depuración y llegar al quit de la cuestión sin dificultad. También se nota en demasia que estamos hablando de diferentes herramientas que ha sido integradas en una plataforma y no forman una verdadera suite todavía, a las que aun les queda mucha evolución por delante.

Entiendo que esas tareas pueden ser una parte importante de un proyecto, pero me han hecho desviar demasiado la atención de lo que pienso que es realmente importante cuando estamos hablando de un sistema de este tipo. Yo no intento aprender Java, o sobre Apache o Ajax, quiero montar una plataforma en la que quiero dedicarme a lo importante de un proyecto BI, y no tener que perder tanto tiempo en aspectos tecnológicos que pueden ser interesantes pero que no me aportan nada. Y si lo comparo con la experiencia y el feeling obtenido, por ejemplo, al utilizar la Microstrategy Reporting Suite (gratuita también, por cierto), la cosa para mi no tiene demasiado color.  Todo esto, unido al siguiente parrafo que me encontre en la guia de usuario de la community edition:

Pentaho no longer suggests using Community Edition  for enterprise  evaluations. If you are a business user interested
in  trying out the BI  Suite Enterprise Edition, follow the Enterprise  Edition evaluation  link on the pentaho.com
front page, or contact a  Pentaho sales  representative. The enhancements, service, and support  packaged with  the BI
Suite Enterprise Edition are designed to  accommodate production  environments,  especially where downtime and time
spent figuring out  how to install, configure, and maintain a business  intelligence  solution are prohibitively expensive.
If your business will  save money  or make more money as a result of a successful business  intelligence  implementation,
then Enterprise Edition is the most  appropriate choice.

Este texto termina de confirmar mis dudas sobre el producto. Entiendo que las versiones Enterprise estarán mas elaboradas, además de contar con el soporte técnico que proporciona el fabricante. Pero para eso seguramente, desde mi punto de vista de gestor de un departamento de informática, en el caso de tener que elegir un producto para un proyecto BI, me decantaría por un producto propietario, quizás con un coste superior, pero con un nivel de integración mayor, mejor documentación, mayor estabilidad tecnológica y el soporte de una empresa involucrada en el desarrollo y con una base amplia de clientes de todos los niveles. Puede que este perdiendo posibilidad de integración con otros sistemas y me este casando con un único producto en el que tendré menos posibilidades en algunas cosas, pero seguramente eso no me haga falta en circunstancias normales.

Esto no es un alegato en contra del software Open Source, en el que creo firmemente y del que utilizo muchas herramientas, tanto a nivel personal como dentro de mi organización (Ubuntu, MySQL, Eventum, Untangle, OpenOffice, MailScanner, Talend, Kettle, VisualParadigm, Apache, etc), pero me apunto a los comentarios que hacía Pau de BI Facil en su blog. En el se hacen consideraciones muy interesantes sobre las herramientas Open (y su utilización en proyectos BI) y que os voy a recordar, pues, desde mi punta de vista, ha acertado de pleno con lo que yo pienso sobre el tema:

"Que un programa tenga el código fuente disponible es una buena cosa. Sin  duda. Puestos a escoger, prefiero utilizar software
del que pueda ver  y/o modificar el código. Esto me dará independencia y me dará una cierta  tranquilidad incluso en el caso de
que el fábricante desaparezca. En la  práctica, sin embargo, no creo que deba ser un criterio fundamental  para la elección de
software. Mi empresa (¿y la tuya?) no se dedica a  fabricar software, por lo que no tiene ni los conocimientos, ni el  interés,
ni las ganas de modificar el código fuente de nuestros  aplicativos. Aunque suene impopular: Tengo más asegurada la continuidad
de Microsoft Word (de código privativo), que el de Pentaho (de código  abierto). Por razones evidentes."

Totalmente de acuerdo. No me veo, con los recursos de los que normalmente disponemos en una empresa media, que nos pongamos a modificar el código fuente de un producto de este tipo (con miles de lineas de código) o nos pongamos a buscar un error que se produzca en un momento determinado. Si puede ser que esto nos permita realizar alguna personalización o algún desarrollo puntual para un tema especifico, pero requeriremos un experto en Java o en desarrollo Web para hacerlo con garantías. Todo un reto.

"Que el software sea gratis o de bajo coste es una buena cosa. Sin duda.  Puestos a escoger, prefiero utilizar software que sea gratis.
Sin  embargo, no debemos equivocarnos: los proyectos “open source” tampoco  son gratuitos, ya que su negocio suele estar en la consultaría,
en el  soporte, o en otros servicios asociados. Personalmente, preferiría una  aplicación que fuese tan fácil de utilizar que no requiriese
consultoría  (o que fuese lo menor posible), ya que a la larga los costes de  consultaría y mantenimiento pueden superar con creces los
costes de  hardware y software. Es decir: Tampoco el coste es un criterio  definitivo para la elección de una herramienta. Existen otros
parámetros  más importantes: Funcionalidad, facilidad de uso y administración,  estabilidad, etc."

Aquí Pau vuelve a dar otra vez en el clavo. Seguramente en un proyecto BI cambiando herramientas propietarias por Open Source estamos trasladando los costes de licencias a coste de consultoria, desarrollo y mantenimiento. Y coincido con el en que el tema del coste no ha de ser definitivo, pero si la funcionalidad, facilidad de uso y administración, estabilidad, documentación, soporte, solución de bugs, sin tener que ponernos a bucear en las tripas de un producto que habra sido desarrollado con herramientas en las que no estaremos especializados y en la que nuestra capacidad de actuación no tendra  demasiadas garantias en comparación con la del soporte del fabricante en un producto evolucionado e integrado.

"Finalmente, el concepto de “software colaborativo” es el que me  resulta más extraño. ¿Qué me importa a mi, como comprador de software,
que el software lo haya hecho un equipo de profesionales a sueldo de IBM  o una comunidad de internautas en sus ratos libres? De hecho,
éticamente, me siento más cómodo comprando algo cuyos autores han  resultado debidamente pagados, y que genera empleo, y tal… No sé si me
explico. El próximo comentario tratara sobre este asunto (después de  haber leído ciertas cosas estoy cabreado, y prefiero no escribir en  caliente)…"

"En definitiva, en mi opinión, la única viabilidad que  tienen las empresas Open Source es entrar de lleno en mercado, y jugar  con las
reglas del mercado. Sólo si sus productos son mejores, podrán  ganar terreno al software “privativo” (así denominan al software  comercial habitual)."

Creo que Pau vuelve a bordarlo con este comentario. El Open Source puede ser una opción de entrada, pero solo creo que sus productos triunfaran si entran en las reglas del mercado (como esta haciendo, por ejemplo, Pentaho) y son mejores que sus competidores.

Conclusión final.

Aunque la experiencia Open Source ha sido muy satisfactoria en la parte de herramientas de integración de datos (tanto Pentaho Data Integration como Talend han cubierto de sobra mis requerimientos, ademas de ser herramientas muy evolucionadas, con muchisimas funcionalidades y estables), no puedo decir lo mismo en la parte de la Plataforma BI y las herramientas de análisis, por todo lo que he descrito en los parrafos anteriores. Además, a nivel de funcionalidades, creo que todavia no se puede establecer una comparación de igual a igual entre un producto como Microstrategy (que es el que he utilizado yo en mis análisis) y Pentaho. Y supongo que lo mismo ocurrira si nos vamos a Sap  (BW o Business Objects), Oracle (OBIE) o IBM Cognos. Quizas este comparando cosas que no tienen mucho que ver, pero una vez he conocido las funcionalidades de un producto así, la evaluación de Pentaho ha sido bastante desilusionante para mi.

Entiendo que el producto tiene potencial de futuro y una gran evolución por delante, pero aun le queda muchisimo para llegar al nivel de las grandes. Y si, siendo un producto Open Source da bastantes funcionalidades que quizas puedan ser suficientes para muchas organizaciones, eso no lo discuto. Pero yo veo algunos peros  y dudas que no me terminan de convencer, aunque ha habido productos que me han gustado bastante, como Kettle, PRD, y otros no tanto como Mondrian o CDF (donde tenemos que ser programadores para hacer nuestros tableros y cuadros de mando). Para mi es fundamental que la herramienta sea fácil de usar, para que, incluso usuarios no técnicos puedan sacar todo el partido de ella, sin necesidad de tener la dependencia del departamento de informática de toda la vida. Seguramente prefiera estar pagando licencias y actualizaciones anuales (para las nuevas funcionalidades), que estar pagando programadores y consultores, y estar sacando todo el partido de la herramienta sin necesidad de perfiles tan técnicos, centrandome en lo importante de la Inteligencia de Negocio, que es el análisis y la extracción de conocimiento de los datos.

NOTA

Gracias a Pau, de BI Facil, hemos conocido el blog La Pastilla Roja. Hay un interesante entrada sobre los criterios y cosas a tener en cuenta a la hora de «hacer el cambio» al Open Source. Creo que se mencionan cosas muy interesantes que pueden ser válidas en nuestra proceso de decisión de «pasarnos» al otro lado.

17.6. Cuadros de Mando en Pentaho con Community Dashboard Framework (CDF).

CDF (Community Dashboard Framework) es un conjunto de tecnologías Open Source que permite a los desarrolladores BI construir cuadros de mando dinámicos y tableros (Dashboards) para la plataforma BI de Pentaho. Los dashboards CDF son paginas web que utilizan la tecnología Ajax para combinar informes, graficos, tablas Olap y mapas.

Pentaho no esta directamente involucrado en el desarrollo de este proyecto, pero incluye el plugin correspondiente tanto en la versión Community como en la Enterprise. Igualmente, desarrolladores de Pentaho son contribuyentes activos al proyecto.

El proyecto fue iniciado por Ingo Klose en 2007 y posteriormente potenciado por el trabajo de Pedro Alves, que además colabora en otros proyectos dentro del ambito de Pentaho, como CDA (Community Data Access), CBF (Community Build Framework) o CDE (Community Dashboard Editor).

Ejemplo CDF

Podeís acceder a la documentación existente sobre CDF en el portal de Pentaho.

Arquitectura de CDF.

Los dashboards CDF son paginas web que contienen areas llamadas componentes, donde se visualiza contenido BI (informes, gráficos, tablas Olap,etc). Cuando ejecutamos un dashboard en la plataforma BI, se produce la siguiente secuencias de acciones para ejecutarlo en el servidor:

1. El usuario utiliza el navegador en la plataforma BI para abrir un tablero. Esto genera una request HTTP que es enviada al servidor BI de Pentaho.
2. El servidor reconoce una petición de Dashboard e intenta localizar el fichero .xcdf asociado.
3. El fichero .xcdf determina el template o plantilla del dashboard. Es un fichero HTML parcial que contiene los huecos para los componentes y las instrucciones Javascript para llenar estos componentes. El dashboard template se combina con la plantilla del documento (outer template) para generar una página web (documento HTML). Este segundo template se especifica igualmente en el fichero .xcdf.

Arquitectura CDF

4. La página es recibida por el navegador para ser visualizada al usuario.  Como parte de este proceso, se inicializa el Dashboard y se ejecutan las instrucciones Javascript del documento, generandose el contenido de los componentes.
5. Despues de la inicialización, se lanza la actualización de los componentes para realizar su llenado. Esto se realiza a través de las correspondientes requests contra el servidor.
6. El servidor Pentaho recibe las solicitudes recibidas por los componentes, que normalmente corresponden a la ejecución de secuencias de acciones (action sequence).
7. El servidor ejecuta la secuencia de acciones.
8. El contenido generado por la secuencia de acciones es enviado como resultado, y es procesado para ser incluido en la pagina web. El resultado llena el correspondiente componente, lo que permite que el resultado sea visible en la página.

Además, en la configuración del plugin se determinan unos templates generales que determinan el marco en el que se visualizan los dashboards y que son totalmente personalizables.

Ejemplo práctico de CDF.

Para entender mejor los diferentes elementos que intervienen en la construcción de un dashboard CDF, vamos a ver un ejemplo práctico sencillo detallando todos los componentes que forman el tablero. Partiendo de uno de los ejemplos que se proporcionan en el portal de Pentaho, que tiene el siguiente aspecto:

CDF - Ejemplo gráfico interactivo

Es un tablero interactivo, de forma que podemos pulsar en cada una de las áreas del gráfico de la izquierda. Al pulsar cada sección, se actualiza de forma automática el gráfico de barras de la derecha, con los resultados de la región seleccionada. Para construir un tablero como el del ejemplo, en primer lugar construiremos el fichero .xcdf, donde estableceremos las propiedades generales, así como el nombre del fichero que contiene el outer template. Este será el fichero pentaho_sample.xcdf del tablero de la imagen:

<?xml version="1.0" encoding="UTF-8"?>
<cdf>
 <title>Pentaho Sample</title>
 <author>Webdetails</author>
 <description>Pentaho Sample</description>
 <icon></icon>
 <template>template.html</template>
</cdf>

En segundo lugar, construiremos el fichero template. html, que incluye la parte html y la parte Javascript que va a determinar como se llenan los diferentes componentes del tablero y como es el comportamiento dinámico de este al pulsar sobre las secciones del gráfico de tarta para ver el desglose de cada una de las zonas.

<SCRIPT LANGUAGE="JavaScript">

// This is a custom function that is fired when a user selects a productLine and then want to select a territory

// Its purpose is to reset the productLine variable back to null and pass the territory that has been selected

// The function is executed from the url-template tag in the territorySales.xaction

function clickOnRegion(value) {

 department = "null";

 Dashboards.fireChange('region',value);

}

</SCRIPT>

## PARTE HTML DONDE DEFINIMOS LAS SECCIONES Y LAS ETIQUETAS HTML QUE LUEGO SERAN SUSTITUIDAS POR LOS COMPONENTES CDF  ##

<!-- The page_title_object -->

<h1><span id=page_title_object></span></h1>

<!-- The dashboard layout table -->

<table align="center" cellpadding="3">

 <tr>

 <td align="center"><div id="RegionsPieChartObject"></div></td>

 <td align="center"><div id="RegionVarianceBarChartObject"></div></td>

 </tr>

 <tr>

 <td align="center"><div id="DepartmentDialChartObject"></div></td>

 <td align="center"><div id="EmbeddedReportObject"></div></td>

 </tr>

</table>

<script language="javascript" type="text/javascript">

// Define script variables before script execution

var region = "null";

var department = "null";

## DEFINICION DE LOS DIFERENTES COMPONENTES, CON SUS PROPIEDADES y FUNCIONES A EJECUTAR ANTES Y DESPUES DE LA EJECUCION DE CADA UNO

// pageTitleString component generates the page title with any other parameters is may need to construct the string

pageTitleString =

{

 name: "pageTitleString",

 type: "text",

 listeners:["region", "department"],

 htmlObject: "page_title_object",

 executeAtStart: true,

 expression: function(){return "title"},

 preExecution:function(){

 if(region == "null" && department == "null") {

 title="Select a region";

 }

 else if (region != "null" && department == "null") {

 title="This is headcount spending for " + region;

 }

 else if (region != "null" && department != "null") {

 title = "This is headcount spending for " + region + ", " + department;

 }

 },

 postExecution:function(){}

}

// RegionsPieChart component generates the

RegionsPieChart =

{

 name: "RegionsPieChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "RegionsPieChart.xaction",

 listeners:[],

 parameters: [],

 htmlObject: "RegionsPieChartObject",

 executeAtStart: true

}

// RegionVarianceBarChart component generates the

RegionVarianceBarChart =

{

 name: "RegionVarianceBarChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "RegionVarianceBarChart.xaction",

 listeners:["region"],

 parameters: [["REGION","region"]],

 htmlObject: "RegionVarianceBarChartObject",

 executeAtStart: false,

 preExecution:function(){document.getElementById('DepartmentDialChartObject').innerHTML="";document.getElementById('EmbeddedReportObject').innerHTML="";}

}

// DepartmentDialChart component generates the

DepartmentDialChart =

{

 name: "DepartmentDialChart",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "DepartmentDialChart.xaction",

 listeners:["department"],

 parameters: [["DEPARTMENT","department"],["REGION","region"]],

 htmlObject: "DepartmentDialChartObject",

 executeAtStart: false

}

// EmbeddedReport component generates the

EmbeddedReport =

{

 name: "EmbeddedReport",

 type: "xaction",

 solution: "bi-developers",

 path: "cdf-samples/20-samples/pentaho_sample",

 action: "embedded_report.xaction",

 listeners:["department"],

 parameters: [["DEPARTMENT","department"],["REGION","region"]],

 htmlObject: "EmbeddedReportObject",

 executeAtStart: false

}

## DEFINICION DE LOS COMPONENTES A SER CARGADOS EN EL DASHBOARD Y LA FUNCION PRINCIPAL DE CARGA DEL TABLERO

// These are the components to be loaded into the dashboard withing the [] seperated by ,

var components = [pageTitleString, RegionsPieChart, RegionVarianceBarChart, DepartmentDialChart, EmbeddedReport];

</script>

<script language="javascript" type="text/javascript">

// The intial dashboard load function definition

function load(){

 Dashboards.init(components);

}

// The intial dashboard load function execution

load();

</script>

Como vemos, todo es programación y somos nosotros los que hemos de indicar el comportamiento de los diferentes elementos, compaginandolos con elementos de diseño HTML. En la documentación de CDF se enumeran las propiedades que se pueden definir y los componentes que podemos utilizar dentro de los tableros. Por ejemplo, podremos configurar los siguientes tipos de componentes:

check: crea una lista de casillas de seleccion etiquetadas con los resultados de una determinada secuencia de acciones (leyendo, por ejemplo, de la base de datos).

dateInput: crear un control de calendario para introducción de fechas.

radio: crea una lista de radiobuttons etiquetados con los resultados de una determinada secuencia de acciones.

select: crear una lista de selección simple, que esta llena con los valores recuperados por una determinada secuencia de acciones.

selectMulti: igual que el anterior, pero la lista permite selección multiple.

text: permite actualizar el texto de una cadena HTML.

textInput: crea un campo de entrada de texto.

xaction: ejecuta una secuencia de acciones y visualiza los resultados en una determinada etiqueta HTML.

jpivot: ejecuta una secuencia de acciones jpivot y visualiza los resultados en un frame donde la tabla jpivot es embebida.

map: componente para integrar mapas.

mapBubble: componente para integrar gráficos.

Con el componente jpivot podremos embeber una tabla de análisis dentro del tablero. Con xaction podremos definir una secuencia de acciones (como ejecutar un informe, por ejemplo). Aunque no la hemos analizado, Pentaho proporciona la herramienta llamada Design Studio (PDS), basada en el entorno Eclipse, que nos permite crear secuencias de acciones para integrar en el servidor BI. Por ejemplo, podremos crear secuencias de acciones para ejecutar informes o sentencias SQL, para enviar correos electrónicos, obtener datos desde Kettle, realizar acciones sobre el scheduler de la plataforma BI, etc. Podeís ver un resumen de las acciones mas usuales en este link. Los ficheros de secuencia de acciones tiene la extensión .xaction. Un ejemplo de fichero de este tipo para ejecutar un report de PRD es el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<action-sequence>
 <title>JFreeReport HTML Example</title>
 <version>1</version>
 <logging-level>debug</logging-level>
 <documentation>
 <author>James Dixon</author>  
 <description><![CDATA[
 This is an example of an HTML report produced by JFreeReport.
 <p/>It shows the actual headcount cost, budgeted headcount
 cost, and variance for every position in the specified
 department and region
 ]]></description>  
 <icon>/style/icons/jfree1.png</icon>  
 <help/>
 <result-type>none</result-type>
 </documentation>

 <inputs>
 <REGION type="string">
 <sources>
 <request>REGION</request>
 </sources>  
 <default-value><![CDATA[Southern]]></default-value>
 </REGION>  
 <DEPARTMENT type="string">
 <sources>
 <request>DEPARTMENT</request>
 </sources>  
 <default-value><![CDATA[Sales]]></default-value>
 </DEPARTMENT>
 </inputs>

 <outputs>
 <report type="content">
 <destinations>
 <response>content</response>
 </destinations>
 </report>
 </outputs>

 <resources>
 <report-definition>
 <solution-file>
 <location>embedded_report.xml</location>  
 <mime-type>text/xml</mime-type>
 </solution-file>
 </report-definition>
 </resources>

 <actions>
 <action-definition>
 <component-name>SQLLookupRule</component-name>
 <action-type>Query For Report Data</action-type>
 <action-inputs>
 <REGION type="string"/>  
 <DEPARTMENT type="string"/>
 </action-inputs>
 <action-outputs>
 <query-result type="result-set" mapping="reportData"/>
 </action-outputs>
 <component-definition>
 <jndi>SampleData</jndi>  
 <query><![CDATA[select     QUADRANT_ACTUALS.REGION,
 QUADRANT_ACTUALS.DEPARTMENT,   
 QUADRANT_ACTUALS.POSITIONTITLE,   
 QUADRANT_ACTUALS.ACTUAL,   
 QUADRANT_ACTUALS.BUDGET,   
 QUADRANT_ACTUALS.VARIANCE  
 from QUADRANT_ACTUALS
 where QUADRANT_ACTUALS.REGION in ( {PREPARE:REGION} )
 and QUADRANT_ACTUALS.DEPARTMENT in ( {PREPARE:DEPARTMENT} )    
 order by QUADRANT_ACTUALS.REGION, QUADRANT_ACTUALS.DEPARTMENT]]></query>
 </component-definition>
 </action-definition>

 <action-definition>
 <component-name>JFreeReportComponent</component-name>
 <action-type>Pentaho Report</action-type>
 <action-inputs>
 <data type="result-set" mapping="reportData"/>
 </action-inputs>
 <action-resources>
 <report-definition type="resource"/>
 </action-resources>
 <action-outputs>
 <report-output type="content" mapping="report"/>
 </action-outputs>
 <component-definition>
 <output-type>html</output-type>
 </component-definition>
 </action-definition>

 </actions>
</action-sequence>

En la imagen podeis ver la interfaz de PDS, y un ejemplo de una secuencia de acciones, que se compone básicamente de inputs, acciones (como las que enumeramos anteriormente) y outputs. Los ficheros xaction son publicados en el portal para integrar las acciones descritas en él. Nos puede ser muy útil para automatizar procesos o para distribuir resultados de la ejecución de informes y graficos.

Pentaho Design Studio

Como os podeís imaginar, el diseño de los tableros con CDF es todo un reto donde hemos de tener conocimientos profundos en diseño Web, Javascript y además conocer de forma completa el funcionamiento del portal BI y la forma de diseñar secuencias de acciones con Pentaho Design Studio. Podremos construir casi todo lo que queramos, pero con un elevado componente de programación que exige un skill técnico muy elevado, en el que seguramente será necesaria la intervención de varias personas, además del conocimiento del negocio propio de un sistema BI.

17.5. Cubos Olap y navegación dimensional con Mondrian y Jpivot.

Pentaho Analysis Services es la parte de la plataforma BI de Pentaho que nos proporciona las funcionalidades Olap para el análisis de la información. Nos permite, de una forma interactiva, analizar los datos del Data Warehouse a traves de una interfaz de tabla cruzada donde podemos navegar por las diferentes dimensiones definidas en el modelo dimensional.

En una entrada anterior del blog, vimos la forma de definir nuestro modelo dimensional utilizando Pentaho Schema Workbench, aunque disponemos de otra herramienta adicional para la construcción de tablas agregadas, llamada Pentaho Agregation Designer (que permite mejorar la velocidad de ejecución de los análisis).

Una vez definidos los módelos dimensionales, podemos ejecutar nuestros análisis utilizando Jpivot a nivel de interfaz de usuario y Mondrian a nivel del servidor (es la parte que recibe las solicitudes de información de Jpivot, realiza las consultas contra la base de datos y devuelve la información en formato multidimensional).

Vamos a ver un poco como funciona la plataforma utilizando estos componentes y a continuación detallaremos las características mas importantes de Jpivot.

Arquitectura de PAS.

Cuando un usuario realiza un análisis a través de Pentaho Analysis Services, se realiza la siguiente secuencia de acciones entre los diferentes componentes que forman la plataforma:

1. Cuando estamos conectados a la plataforma BI y lanzamos la ejecución de un nuevo análisis, o interactuamos en un análisis ya visualizado (haciendo un drilldown por los datos, por ejemplo,  o modificando la vista de los datos o los filtros), se produce una request HTTP, que provoca una secuencia de acciones sobre Jpivot.
2. El servlet Jpivot recibe la solicitud y la traduce/transforma a una query en lenguaje multidimensional MDX, que es enviada a Mondrian (nuestro servidor ROLAP).
3. Mondrian interpreta la query MDX y la traduce en una o mas sentencias SQL, que son enviadas a la base de datos relacional.
4. La base de datos relacional ejecuta las sentencias SQL enviadas por Mondrian y le devuelve los resultados en forma de tabla (la forma tipica de visualizar resultados en cualquier motor de base de datos relacional utilizando el lenguaje de interrogación SQL).
5. Mondrian procesa los resultados y los traduce a un set de resultados multidimensional. Este set de datos sería la respuesta a la query MDX del punto 2.
6. Jpivot utiliza los resultados multidimensionales para construir una página HTML para visualizar la información, con la interfaz propia que veremos a continuación.

Arquitectura de Pentaho Analysis Services

La base para el correcto funcionamiento del sistema y de los diferentes componentes que lo forman, es la definición de los esquemas dimensionales y sus cubos, que habremos realizado previamente utilizando PWD. Mondrian viene instalado en la plataforma BI de Pentaho como un componente integrado. Si quereis profundizar en aspectos concretos de su funcionamiento y configuración, os recomiendo la lectura de la documentación que Pentaho proporciona en su portal.

Jpivot.

Jpivot es el cliente que vamos a utilizar para visualizar los resultados de los análisis. Para ejecutar un análisis, podemos utilizar uno ya existente que habremos guardado en la correspondiente carpeta de la plataforma, o bien crear uno nuevo desde la opción Nueva vista de análisis, momento en el que se nos pedirá el esquema y el cubo sobre el que queremos construirlo.

Seleccion esquema y cubo

A continuación, nos aparecerá una tabla de Jpivot por defecto, donde aparecerán todas las dimensiones de análisis definidas en el cubo y los indicadores por defecto, con una única linea de resultados totales. Este será el punto de partida sobre el que iremos puliendo nuestro análisis hasta dejarlo de la forma que cumpla nuestros requerimientos de información.

Esta tarea de modificación de los análisis no será siempre necesaria, pues una vez los tengamos preparados, los podremos guardar y reejecutar, manteniendo la configuración de dimensiones, jerarquías, filtros e indicadores de análisis que tuviera la tabla en el momento de ser guardada. Vamos a ver las diferentes opciones de la interfaz de usuario de Jpivot.

La interfaz de usuario de JPivot es muy sencilla. Básicamente, disponemos  de una barra de herramientas con botones donde podemos configurar las propiedades que va a tener la tabla donde visualizamos los resultados de los análisis. Veamos uno por uno cada botón (de izquierda a derecha) de la interfaz de usuario.

Jpivot - Barra Herramientas

Navegador Olap

El primer botón de la barra de herramientas es el navegador Olap que nos permite configurar como Jpivot muestra la información de los cubos en la tabla pivot. Con la herramienta podemos definir que dimension y jerarquia aparece en cada uno de los ejes (filas/columnas), los indicadores que visualizamos en el análisis, filtros, etc. Podemos ir moviendo los diferentes elementos de una sección a otra pulsando los correspondientes iconos a la izquierda de cada elemento hasta dejar el análisis personalizado a nuestra necesidades.

Jpivot - Navegador Olap

De esta forma, vamos configurando como será la visualización en la tabla. Ademas, podremos modificar la jerarquía visible en cada dimensión (en principio se verá la jerarquía por defecto, para el caso de tener varias jerarquías en la misma dimensión). También podemos seleccionar el nivel dentro de la jerarquía o los elementos a visualizar de todos los disponibles.

Jpivot - Selección miembros

Una vez realizadas las consiguientes modificaciones en el layout, pulsaremos el botón Aplicar y los cambios serán visibles en la tabla pivot.

Jpivot - Informe Modificado

Editor MDX.

Como hemos indicado antes, conforme vamos seleccionado las dimensiones e indicadores en el navegador olap, al actualizar la consulta, internamente se traduce a lenguaje MDX que es el que utiliza Mondrian para luego construir las sentencias SQL que se ejecutaran contra la base de datos relacional. Con este control, podemos visualizar la sentencia MDX que se ha construido de forma automática, e incluso, si dominamos este lenguaje, escribir directamente las consultas que darán como resultado la tabla pivot correspondiente.

Jpivot - Editor MDX

Habrá que tener en cuenta en la sintaxis de las sentencias MDX como hayamos llamado a las dimensiones, jerarquías e indicadores. Podeis consultar sobre la sintaxis del lenguaje MDX en la correspondiente página de Pentaho.

Propiedades de visualización.

El siguiente grupo de iconos nos permite establecer propiedades de visualización de la tabla de pivoteo sobre los datos.

• Mostrar padres: podemos forzar la visualización de los elementos padre conforme vayamos profundizando en los datos.

Jpivot - Mostrar Padres

• Ocultar repeticiones: con esta opción podemos ocultar repeticiones de los valores de los miembros de una jerarquía y asi hacer mas comprensible el análisis de los resultados.

Jpivot - Ocultar repeticiones

• Suprimir filas/columnas vacias: oculta las filas o columnas que no tuviesen valores.
• Intercambiar ejes: nos permite de una forma rápida pasar las filas a columnas y viceversa, y así cambiar la forma de ver la información.

Opciones de navegación.

Una opción muy interesante es determinar la forma en que se realiza la navegación por la tabla. Para ello, tenemos 3 posibles opciones.

• Detallar miembro: cuando navegamos por un miembro de una dimensión (por ejemplo, el mercado EMEA en la imagen anterior), independientemente de que estemos en un año u otro, se abre el desglose del miembro en todas las ocurrencias que tuviera en la tabla (en los diferentes años en el caso de nuestro ejemplo).
• Abrir detalle: en contraposición a Detallar miembro, con la opción Abrir detalle sobre se abre el nivel del miembro que hayamos seleccionado, no todas las ocurrencias.
• Entrar en detalle: cambiamos la forma de navegación, sustituyendo el icono + por una flecha, que nos permite ir bajando y subiendo por la información sin que se vaya realizando un desglose. Es una forma de navegación mucho más util para ir analizando aspectos concretos.

Las tres opciones de navegación descritas son excluyentes entre si (solo podremos tener seleccionada una de ellas a la vez).

Jpivot - Entrar en detalle

• Mostrar datos Origen: con esta opción mostramos en la parte inferior de la tabla pivote una tabla adicional donde se muestran los datos originales que dan lugar a los resultados mostrados en la tabla principal. Puede ser útil para buscar determinados valores en registros individuales de datos cuando se produzca una alarma visualizando los resultados de la tabla principal.

Modo gráfico y exportación PDF/Excel.

Finalmente, el ultimo set de botones de la barra de herramientas nos permiten configurar el gráfico que se muestra como complemento de la tabla pivot o realizar la exportación de los resultados en formato PDF o Excel.

• Mostrar gráficos: al seleccionar la opción, se visualiza adicionalmente un gráfico con los resultados de la tabla. Los tipos de gráfico que se pueden utilizar son de barras, de linea, de area o de tarta.

Jpivot - Tabla y grafico

• Configurar gráficos: en esta opción configuramos las propiedades del gráfico (tipo de gráfico, fuentes, titulos, color de fondo, etc).
• Configurar impresion: configuramos alguna de las propiedades que tendrá el PDF que se genere en la opción Exportar a PDF (titulo, tamaño de tabla, orientación del papel, etc).
• Exportar a PDF: genera un documento PDF con los resultados de la tabla pivot según la configuración indicada.
• Exportar a Excel: nos permite exportar la tabla de resultados visibles a un fichero con formato excel.

Otras alternativas. StPivot, Pat y Jrubic/La Azada.

Jpivot tiene una interfaz algo anticuada y no demasiado vistosa. Por este motivo, han surgido algunas alternativas que tratan de mejorar la experiencia de usuario al trabajar con Mondrian. Podemos destacar:

• Stpivot: como lo llaman en Stratebi, es Jpivot con esteroides. Es una mejora de la interfaz de usuario y algunas funcionalidades realizadas por ellos. Os dejo el link al blog de todobi.com donde podeis ampliar información y ver videos de como instalarlo y utilizarlo.
• Jrubik/ La Azada: una opción alternativa a la utilización de PAS es utilizar un cliente Olap que ejecutaremos en nuestro PC como un programa más de escritorio. Un ejemplo de este tipo de aplicación es Jrubik, proyecto desarrollado en su día por gente de la Agencia Tributaria en España o el más actual La Azada, del que podeis leer mas en este documento publicado por todobi.com. Estan totalmente integrados con Mondrian, y aunque tienen algunas limitaciones y bugs, pueden ser una opción interesante.

Interfaz gráfico de La Azada

• Pat (Pentaho Analysis Tool): es el nuevo proyecto que pretende crear la interfaz del futuro que sustituya a Jpivot. Esta todavía en una fase muy inicial y aun le queda un largo recorrido antes de ser una opción a considerar. Podeis ampliar información sobre el proyecto aquí.

Interfaz de usuario de PAT

En la próxima entrada del blog concluiremos el análisis de las herramientas de Pentaho en la parte referente a Cuadros de Mando y Dashboard a través del proyecto Community Dashboard Framework for the Pentaho BI Platform.

17.4. Reporting en Pentaho con Pentaho Report Designer. Otras posibilidades de reporting (Birt y JasperReports).

La plataforma Pentaho nos proporciona dos formas integradas de realizar reporting, ademas de permitir la utilización e integración de otras herramientas (como JasperReports o Birt). Las herramientas propias de Pentaho, como ya vimos, son las siguientes:

• Web Ad Hoc Query and Reporting Client (WAQR): herramienta integrada en el portal que nos permite realizar querys y reporting adhoc de una forma intuitiva y sencilla, aunque con limitaciones.
• Pentaho Report Designer (PRD): a través de una herramienta de diseño desktop, que nos permite definir y construir nuestros informes, y luego publicarlos en el portal de BI para que puedan ser ejecutados por los usuarios.

Vamos a ver un poco mas en profundidad en que consisten estas herramientas.

Web Ad Hoc Query and Reporting Client (WAQR).

EL WAQR es la herramienta de reporting ad-hoc integrada en el portal BI de Pentaho. Accedemos a la herramienta desde la opción de menú Archivo –> Nuevo –> Nuevo report o pulsando el correspondiente Icono en la barra de la aplicación. En ese momento nos aparece un asistente que nos permitirá la construcción de los informes a partir de la información del metadata definida en el sistema (que habremos preparado previamente utilizando Pentaho Metadata Editor, como vimos en la correspondiente entrada del blog).

El asistente dispone de 4 etapas, en las que realizaremos las siguientes acciones:

1) Select Data Source: realizaremos la selección del origen de datos que queremos utilizar. Dispondremos de tantos origenes de datos como Business Model o Modelos de negocio hayamos generado en la definición del Metadata. Seleccionaremos uno de los modelos y tendremos disponibles para los siguientes pasos todas las vistas de negocio y sus correspondientes campos incluidas dentro del modelo de negocio seleccionado. Además, podremos indicar un template o plantilla que nos determinará el formato que va a tener nuestro informe.

Asistente de la creacion de un informe de WAQR

2) Make Selections: a continuación, de todas las vistas de negocio incluidas en el modelo de negocio seleccionado, configuraremos la disposición de los resultados del informe, seleccionamos los campos oportunos de cada una de las vistas de negocio disponibles. Seleccionaremos uno a uno los campos y lo llevaremos a las secciones del informe que se encuentran en la parte derecha de este. Tenemos 3 posibles secciones: Groups (campos con los que realizaremos grupos de valores, pudiendo configurar hasta 5 niveles de agrupación), Details (campos que formaran el cuerpo del informe o detalle) y Filters (campos que se utilizaran para restringir los valores devueltos en la ejecución).

Selección de campos y configuración de secciones

3) Customize Selections: en esta tercera pestaña configuraremos aspectos del formato de cada una de las secciones del informe. Por ejemplo, en lo referente a las agrupaciones (Groups), podremos indicar aspectos generales de como se realiza el agrupado (nombre de nivel, repetición de cabecera de grupo, mostrar sumario de grupo, etiqueta para el total por grupo, ruptura de pagina o no en el grupo, ruptura de pagina antes o despues del grupo, alineación, etc), tal y como podeís ver en la imagen siguiente.

Propiedades de campos y secciones

Ademas, podemos indicar aspectos de formateo, como mascaras de edición, alineación, forma de ordenación del grupo, condiciones del grupo, etc, tal y como veis en la imagen. Basicamente, tenemos los mismos componentes de formato si estuvieramos modificando los campos seleccionados en la sección Details (detalles).

Propiedades de campos y secciones

Para los campos insertados en la sección Filters, podremos indicar constraints que serán condiciones que limitaran los resultados devueltos por el informe.

4) Report Settings: este será el último paso en la preparación del reporte adhoc. En este paso final indicaremos la orientanción del informe, el tamaño de papel y la configuración de la cabecera y pie de pagina del informe. En este momento, el informe ya esta listo para su ejecución o para ser guardado y reutilizado posteriormente por los usuarios.

Configuracion del informe y de cabecera y pie de página

Hemos visto que es una herramienta muy fácil y sencilla de utilizar, y su potencia radica en que hayamos definido correctamente en el metadata los campos a utilizar con las relaciones definidas correctamente entre las tablas que son su origen. Aunque tiene muchas limitaciones, nos puede sacar de un apuro y puede ser sin duda facilmente utilizada por los usuarios finales. Ademas, los resultados del informe los pondremos tener en HTML, PDF, Excel o CSV.

Pentaho Report Designer (PRD).

Pentaho Report Designer es una herramienta de reporting que nos permite crear nuestros propios informes, bien para ejecutarlos directamente o para publicarlos en la plantaforma BI y que desde allí puedan ser utilizados por los usuarios. La herramienta es independiente de la plataforma y forma parte del conjunto de herramientas de la suite de Pentaho.

Antes de continuar, os hago una recopilación de la documentación que proporciona Pentaho en su portal Wiki con respecto al reporting.

User Guides

• Formula Syntax

Blogs, Articles, How-Tos

• Diethard Steiner: Using Parameters in queries and datasources in Pentaho Reporting 3.5
• Diethard Steiner: Setting up an «All» Parameter
• Bart Maertens: Crosstabs in PRD-3.5
• Michael Tarallo: Guided Ad-Hoc with PRD-3.5
• MDX PARAMETER function

Books

• Pentaho Reporting 3.5 for Java Developers
• Roland Bouman, Jos van Dongen: Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL

Developer Guides

A pentaho-reporting-sdk aimed at Java-Developers with simple demos, a detailed step-by-step guide and all the sources for all the libraries used in the demos is available from sourceforge.

• How to configure Logging in Pentaho Reporting
• Dependency documentation
• Pentaho Reporting’s Modular Design
• Using the DocumentBundle Reader and Writer
• Parameter Definitions
• Report Processing State Diagramm
• Code-style Definitions
• Functions And Expressions
• DataSource MetaData, User-friendly column names and formatting information
• Aggregate Fields
• Drill-Linking

Installation Guides

• Report configurations and the boot process
• Use of TrueType Fonts
• Define Selectable Report Encoding

User Guides

• URL Parameters for the Report Viewer Plugin
• Reserved Parameter Names
• Classic Engine Algorithm
• Layout Restrictions for Table-based and Plain-Text output
• Style-Keys Reference
• Subreport Guide
• Introduction to Report Pre-Processors
• Fonts: Export to PDF and missing Unicode characters
• Timeseries-Charting in Report-Designer
• Links and Drill-Down
• Using Self-Signed Certificates with SSL (HTTPS) Connections

Pentaho Report Designer nos permite trabajar con multiples origenes de datos (JDBC, Olap4J, Pentaho Analysis, Pentaho Data Integration, XML) incluido el metadata que tengamos definido en nuestro sistema. También nos permite modificar los informes ad-hoc que hayamos creado utilizando WAQR (de hecho es la única forma de modificarlos). El motor de reporting de Pentaho esta basado en JFreeReports y ha sido totalmente rediseñado en lo que llaman PRD (Pentaho Report Designer). PRD es un generador de informes del tipo Banded (en contraposición de los generadores orientados a flujo),  en los que un informe se divide en secciones o grupos de datos en los que los elementos del informe pueden ser posicionados. Esta forma de trabajar tiene algunas limitaciones, que se pueden superar con el uso de subinformes. El resultado de los informes que vamos diseñado se puede ver con las opciones de previsualización, y nos permite la salida de resultados en diferentes formatos como PDF, HTML, XLS, RTF y CSV.

Interfaz de usuario de PRD

A continuación vamos a realizar un ejemplo de utilización conectandonos a una base de datos Oracle para obtener diferentes informes de ventas, que nos permitira ver las funcionalidades básicas de PRD, así como todos los elementos que forman su interfaz de usuario.

Estructura de los informes.

Tal y como vemos en la imagen anterior, cuando creamos un informe partimos de una estructura estandar que incluye una serie de secciones que podremos utilizar o no. Las secciones mas habituales son las siguientes:

• Page Header/Page Footer: el contenido indicado en estas secciones sera visible en cada una de las páginas del informe, en cabecera o pie de página según la sección seleccionada.
• Report Header/ Report Footer: el contenido indicado será visible solo una vez, al principio del informe o al final de este. Puede ser utilizado para indicar un titulo o un resumen del informe (en la primera página) o para presentar totales o conclusiones en la última página.
• Group Header/ Group Footer: cuando estamos trabajando con grupos de información, disponemos de estas dos secciones para abrir o cerrar cada grupo de información (sacar titulo al inicio o al final, subtotales, etc).
• Details Body: es la seccion que contiene la información detallada (fila por fila) recuperada de la base de datos. Tambien incluye las secciones Details Header y Footer para incluir cabeceras o titulos y pies.
• No Data: es una sección especial que se visualizara en el informe en el caso de que el set de resultados del informe este vacio.
• Watermark: es una sección especial que nos permite definir una marca de agua (o fondo) que se imprimira como base del informe en cada página de este.

Ejemplo de informe donde podemos ver las secciones que lo forman

En la imagen podeis ver un ejemplo de informe donde se utilizan algunas de las secciones descritas anteriormente (Cabecera de página para incluir el log de una empresa, Report Footer para incluir un gráfico resumen de los datos, cabecera y pie de grupo, detalle, etc). Podeis igualmente ver en la parte derecha del informe la sección Data que veremos mas adelante para definir los origenes de datos, la query que utilizaremos para recuperar datos, así como las funciones y fórmulas para hacer cálculos.

Componentes.

En la parte izquierda de la pantalla, disponemos de una barra de herramienta en las que tenemos los diferentes componentes que podemos utilizar al definir un informe (tal y como vemos en la imagen siguiente). Vamos a ver en detalle cada uno de ellos (de derecha a izquierda según aparecen en la imagen):

Componentes de la barra de herramientas

• Etiqueta (label): elemento básico para añadir texto estático o etiquetas de columna en un informe.
• Campo Texto (text-field): para visualizar el contenido de campos de texto recuperados del dataset del informe.
• Campo Numérico ( number-field): para visualizar el contenido de campos numéricos recuperados del dataset del informe.
• Campo Fecha (date-field): para visualizar el contenido de campos de fecha recuperados del dataset del informe.
• Campo Mensaje (message-field): campo avanzado que nos permite combinar texto, referencias a campos y funciones en una única celda de datos. Por ejemplo, podremos definir un campo de este tipo con el contenido: «Cliente: $codigo_cliente domiciliado en: $poblacion». Los campos precedidos por $ se refieren a campos del dataset.
• Etiqueta de recurso (resource-label): basandonos en un fichero de recursos, PRD puede traducir etiquetas de textos a otros idiomas.
• Campo de recurso (resource-field): idem que el anterior, pero para campos.
• Mensaje de recurso (resource-message): idem que el anterior, pero para mensajes.
• Campo Imagen (content-field): para visualizar campos del dataset que sean imagenes (recuperados, por ejemplo, de la base de datos).
• Imagen (image): visualiza una imagen proveniente de un archivo o de una URL.
• Elipse (ellipse): dibuja una elipse en el informe.
• Rectangulo (rectangle): dibuja un rectangulo en el informe.
• Linea horizontal (horizontal-line): dibuja una linea horizontal en el informe.
• Linea vertical (vertical-line): dibuja una linea vertical en el informe.
• Gráfico de escala (survey-scale): para dibujar un mini-grafico para representar una escala de 1 a 5.
• Grafico (char): inserta un gráfico de análisis, que se podrá editar mediante el correspondiente editor. Nos permite crear gráficos de barras, de área, de tarta, de lineas, de burbujas, de anillo, radar, etc.

Editor de gráficos

• Código de barras (simple-barcodes): traduce el contenido de un campo a un código de barras que podrá ser leido por un lector apropiado.
• Bar-sparkline,Line-sparkline, Pie-sparkline: para crear mini gráficos de barras, lineas o tarta.
• Banda (band): elemento para agrupar varios elementos y facilitar su formato de forma conjunta.
• external-element-field: válido para cargar subreports externos, desde una URL o desde una ubicación de archivos.
• SubInforme (subreport): nos permite incluir un subinforme dentro de la ejecución de un informe (y al que podremos pasar también parámetros del propio informe padre).

Definición de datasets.

La parte más importante cuando estemos creando un informe es la definición del dataset, pues va a determinar los datos que vamos a poder utilizar dentro de nuestro informe. PRD nos deja trabajar con varios tipos de origenes de datos, como son JDBC, el Metadata de la plataforma BI,  Pentaho Data Integration, origen de datos OLAP, fichero XML, etc. Vamos a ver un ejemplo sencillo utilizando JDBC como origen de datos.

En primer lugar, configuraremos el origen de datos al que nos vamos a conectar utilizando JDBC. A continuación, definiremos las querys que van a determinar los datos devueltos desde el origen de datos, tal y como vemos en la imagen.

Configuración de Dataset - Origen JDBC

Para la construcción de las querys, tenemos un asistente que nos permite ver las tablas disponibles e ir construyendo las diferentes secciones de la sentencia SQL (Select, From, Where, Group By, Having, Order by). Disponemos la opción Preview para ir visualizando los resultados que devolvería la ejecución de la query.

Editor de querys

Una vez concluida la definición de la query, nos aparece en la parte derecha de la aplicación, en la sección Data (tal y como vemos en la imagen siguiente). Tendremos todas las querys que hayamos definido y la lista de campos que devuelve la query, para poder ser utilizados en las diferentes secciones y controles del informe.

Sección Data en PRD

Uso de parámetros y funciones.

Para poder definir restricciones a los datos que devuelvan los informes, PRD nos permite trabajar con parametros, que se nos pediran en el momento de ejecución del informe y que se podrán incluir en las condiciones de las querys definidas. Podremos definir diferentes tipos de parametros, desde lista simple, lista multiple, casilla de selección, radio button, etc. Los valores a mostrar en los filtros también se pueden hacer que sean determinados por el resultado de ejecución de una query contra base de datos (por ejemplo, una lista de provincias para determinar los resultados que queremos mostrar).

Editor de Parametros

Para incluir los parametros en la ejecución de las querys, utilizaremos la notación ${nombre_parametro} en el lugar apropiado. Por ejemplo:

SELECT DISTINCT
‘dim_date_en_us’.’year4′,
‘dim_date_en_us’.’quarter_name’,
‘dim_date_en_us’.’month_number’,
‘dim_date_en_us’.’month_name’
FROM
‘dim_date_en_us’
WHERE
‘dim_date_en_us’.’year4′ = ${param_year}
AND ‘dim_date_en_us’.’quarter_name’ IN (${param_quarter})

Observar el uso de un parametro que es una lista de valores en la ultima linea de la sentencia SQL, utilizando el operador IN para que un campo de una tabla se compare contra una lista de valores.

PRD también nos permite la utilización de funciones para realizar calculos y operaciones complejas (incluyendo la utilización de formulas al igual que vimos con PDI).

Editor de fórmulas

Uso de subinformes.

Otra característica interesante de PRD es la posiblidad de utilizar un informe dentro de otro informe (lo que llaman subinformes). Esto nos puede permitir superar las limitaciones que tiene un generador de informes del tipo Banded. Por ejemplo, lo podremos utilizar para mostrar diferentes vistas del mismo conjunto de datos. Cuando incluimos un subinforme dentro de otro, al hacer doble click accedemos al informe hijo para realizar su modificación y diseño.

Todos los elementos vistos hasta ahora tienen sus correspondientes tablas de propiedades donde podemos configurar su compartamiento, propiedades de formato y visualización, calculos, etc. Disponemos igualmente de una opción de previsualización para ver como quedaría el resultado del informe tras la fase de diseño.

Publicación y ejecución de informes.

Los informes que hayamos creado se pueden ejecutar directamente desde PRD o bien publicarlos en la plataforma BI, momento en el que ya estarán disponibles para ser usados por los usuarios (habrá que acordarse previamente de refrescar la cache del  metadata en la plataforma para que tenga en cuenta y sea accsesible el nuevo informe).

Otras alternativas. Birt y JasperReports.

Ademas de las herramientas propias de Pentaho, la plataforma nos permite integrar con otras de las herramientas de reporting Open Source mas conocidas, como son Birt y JasperReports. Os dejo algunos links donde se explica la forma de configurar y ejecutar informes de Birt y Jasper en la plataforma BI de Pentaho.

• Ejecución de informes BIRT en la plataforma de Pentaho: link.
• Ejecución de informes JASPER en la plataforma de Pentaho: link.

Igualmente, os dejo otros links interesantes donde hablan de la integración de Pentaho con estas herramientas y algunos posibles problemas o cosas a tener en cuenta:

• Todobi.com: Integrando BIRT con Pentaho.
• Eclipse BIRT 2.5 and Pentaho 3.5 Integration and Configuration: link.

Con el uso de PRD y estas dos herramientas alternativas de reporting quedan mas que cubiertas las necesidades de reporting en la plataforma.

17.3. Preparando el analisis dimensional. Definición de cubos utilizando Schema Workbench.

En lo referente al análisis dimensional, Pentaho nos proporciona en su plataforma BI una solucion ROLAP a través de lo que llaman Pentaho Analysis Services. PAS esta basado en Mondrian, que es el corazon de este, y en Jpivot, que es la herramienta de análisis de usuario, con el que realizamos la navegación dimensional sobre los cubos desde la plataforma BI y visualizamos los resultados de las consultas. Estas son ejecutadas por Mondrian, que traduce los resultados relacionales a resultados dimensionales, que a su vez son mostrados al usuario en formato Html por Jpivot.

Arquitectura Pentaho Analysis Services

Tal y como vemos en la imagen, donde se representa la arquitectura de Pentaho Analysis Services, el elemento principal del sistema son los ficheros xml donde se representan los esquemas dimensionales. Para construir estos ficheros xml, podriamos utilizar cualquier editor de texto o xml, o bien la herramienta que nos ofrece Pentaho, que se llama Schema Workbench. Pentaho Schema Workbench es la herramienta gráfica que permite la construcción de los esquemas de Mondrian, y además permite publicarlos al servidor BI para que puedan ser utilizados en los analisis por los usuarios de la plataforma.

En los ficheros de esquema XML, se describen la relaciones entre las dimensiones y medidas del cubo (modelo multidimensional)  con las tablas y campos de la base de datos, a nivel relacional.Este mapeo se utiliza para ayudar la traducción de las querys MDX (que es el lenguaje con el que trabaja Mondrian), y para transformar los resultados recibidos de las consultas SQL a un formato dimensional. Vamos a ver a continuación como utilizar PSW para definir los esquemas de nuestro proyecto y publicar los resultados en el servidor BI. Más adelante veremos como funciona jpivot a nivel de frontend, para sacarle todo el partido a los análisis.

Pentaho Schema Workbench.

Como en todas las herramientas de Pentaho, en primer lugar hemos de definir las conexiones a base de datos como paso previo a la configuración de los esquemas. Además, hemos de colocar el driver jdbc en el directorio drivers que cuelga de la instalación de PSW. En nuestro caso, hemos configurado la conexión con Oracle de la siguiente manera:

Definición de la conexion a BD en PSW

Vamos a ver a continuación las tareas básicas para definir un esquema utilizando PSW. Os recomiendo la lectura de la documentación Online de Pentaho referente a este tema antes de continuar, pues en ella se explican los conceptos básicos que tendremos que conocer para realizar el diseño de forma correcta.

En primer lugar, procederemos a crear el Esquema. Un esquema es un contenedor de cubos (tendra un único fichero xml), donde podremos crear tantos cubos como deseemos. La propiedades que se pueden indicar al crear un esquema son un nombre, la descripción, un nombre para la dimensión que agrupara a las medidas y un rol por defecto para utilizar en las conexiones de base de datos. Como ayuda en este momento y en la creación del resto de elementos, podemos poner el ratón en el nombre del atributo a definir, y nos aparecera un texto explicativo de este (tal y como veis en la imagen siguiente).

Creacion esquema

Una vez creado el esquema, procederemos a la creación de los Cubos, aunque previamente hemos de hacer una consideración.  En cada cubo, podemos definir la estructura de tabla de hechos, medidas, miembros calculados y dimensiones. La dimensiones y sus jerarquias podemos definirlas dentro de cada cubo, o crearlas de una forma general dentro del esquema, y luego utilizarlas en los cubos que nos interesen. Esto nos evita tener que definir varias veces lo mismo para cada uno de los cubos, así como reutilizar elementos ya definidos que se tratan en varios cubos. Esta será mi elección de diseño. Por tanto, antes de crear los cubos vamos a crear las dimensiones compartidas con sus correspondientes jerarquías.

Creación de dimensiones compartidas.

Para añadir las dimensiones, seleccionaremos el esquema y pulsaremos la opción Add Dimension. Le daremos un nombre significativo a la dimensión, y seleccionaremos su tipo (TimeDimension en este caso) y una descripción.

Creacion dimension compartida

A continuación, iremos creando las diferentes jerarquias que tenga la dimensión. Por ejemplo, en nuestra dimensión tiempo tenemos la jerarquías: Año – Mes – Dia, Semana – Dia, Año – Trimestre – Mes – Dia, etc. Como veis, podemos tener tantas jerarquías como deseemos. Las jerarquías son los niveles de análisis y detalle de la información de nuestro modelo dimensional, que luego nos permitiran realizar el análisis y la navegación por los datos utilizando Mondrian. En cada jerarquía, indicaremos una serie de parámetros (importantes el hasAll, si queremos que haya un agrupador de todos los valores de la jerarquía, y su descripcion en el caso de que este marcado (allMemberName)). Igualmente importante la clave de la jerarquía y una descripción que luego nos aparecerá al configurar la ejecución del cubo.

Propiedades de la jerarquía de una dimension

Para cada jerarquía, indicaremos una tabla de la dimensión, y a continuación iremos creando los diferentes Niveles (levels) que componen la jerarquía.Para cada nivel, iremos indicando la columna de la base de datos que la describe, el tipo de datos, el tipo de nivel, la columna que contiene la descripción, etc. Esto lo realizaremos para cada uno de los niveles de la jerarquía. El orden con el que vamos creandolos determina la estructura de la jerarquía.

Creación de niveles dentro de la jerarquía

Podemos tener tantas jerarquías como sea necesario dentro de la dimensión. Luego podremos utilizar la que deseemos a la hora de realizar los análisis (la primera será la jerarquía por defecto). Una vez concluido el diseño de todas las dimensiones con sus correspondientes jerarquías, ya podemos proceder a la creación de los cubos.

Creación de Cubos.

Al crear el Cubo, le indicaremos un nombre y una descripción, pudiendo marcar ademas las opciones cache (para que Mondrian trabaje con cache en este cubo) y la opción enabled (para que el cubo sea visible. Sino esta marcada este flag, el cubo no aparecerá).

Creacion del Cubo

A continuación, seleccionaremos la Tabla de Hechos del cubo (a partir de la cual podremos calcular las medidas o indicadores). Antes de proceder a crear las medidas, seleccionaremos las dimensiones que queremos incluir en el cubo, con la opción Add Dimension Usage. Incluiremos todas las dimensiones necesarias(de las compartidas que hemos creado antes). El cubo hereda todas las características que hayamos incluido en la dimensión, incluyendo todas las jerarquías y sus correspondientes atributos.

Como ultimo paso en la creación del cubo, nos tocará definir las Medidas, que van a ser los valores de análisis. Tenemos aquellas que se calculan directamente con campos de la base de datos, y los Miembros Calculados, que son formulas en las que utilizamos otras medidas.  Los atributos que podemos indicar para las Medidas son su nombre, descripción, función de agregación (suma, media, valor máximo, valor mínimo, contador, etc), la columna que genera la medida, si es visible o no (puede interesar que campos intermedios que se utilizan para otras medidas no se vean), tipo de datos, formato y caption (nombre que aparecera cuando lo utilicemos).

Creacion Medida

En lo referente a los Miembros Calculados, los atributos están mas limitados. Podremos indicar su nombre, descripción, caption (nombre que aparecerá en los análisis), si es visible o no, y el atributo mas importante, la formula que genera el valor de la medida calculada. Para indicar los valores de otras medidas, utilizamos la notación [dimension_medidas].[medida]. Por ejemplo, para calcular el importe bruto de ventas, la formula, siguiendo esta notación sera la siguiente: [Measures].[Unidades]*[Measures].[Precio_Bruto]

Publicación del Esquema y utilización desde el portal BI.

Hemos visto los elementos básicos que podemos utilizar en la definición de un esquema de Mondrian y sus cubos. Disponemos de otros elementos, como los NS (Named Set) o los UDF (User Defined Functions), así como los elementos virtuales (Cubos, Dimensiones y Medidas), en los que no vamos a entrar en detalle. Tras construir el esquema, el paso final para poder utilizarlo en los análisis del portal BI de Pentaho es su publicación. Para ello, salvamos el cubo y seleccionamos la opción de menú File –> Publish. Se nos pide la dirección de publicación del servidor, la contraseña de publicación y los datos del usuario. Se realiza la conexión con el servidor y el esquema ya esta disponible para ser utilizado.

Publicacion de un esquema de Mondrian desde PSW

Accedemos al portal para ver si esto es asi. Al crear una nueva vista de análisis, nos aparecen los diferentes esquemas disponibles, y ya aparece el nuestro, ademas de los esquema de demostración que incluye el servidor. Tal y como veis en la imagen, disponemos de nuestro primer análisis. Aparecen todas las dimensiones (aunque solo se visualiza una jerarquía por dimensión) y solo se ve una medida de todas las que hayamos definido.

Aunque veremos más adelante todas las opciones que podremos utilizar con Mondrian y jpivot, rapidamente modificamos el análisis, modificando la configuración de las dimensiones y los indicadores de análisis, y nos queda algo así. Hemos dejado solo la dimensión tiempo, con la jerarquía Año-Mes-Dia partiendo del nivel de mes, y hemos modificado los indicadores (medidas) que se visualizan.

Ejemplo de análisis sencillo

Con la definición del metadatos que vimos en la entrada anterior del blog, y la creación y publicación de los esquema de Mondrian que hemos visto aquí, tenemos el portal de BI listo para profundizar en las herramientas de reporting y para sacar todo el partido de los análisis dimensionales. Estos son los aspectos que vamos a ver en profundidad en las próximas entradas del blog.

17.2. Preparando el reporting. Definición de metadatos con Metadata Editor.

La plataforma Pentaho nos proporciona dos formas integradas de realizar reporting, ademas de permitir la utilización e integración de otras herramientas (como JasperReports o Birt). Las herramientas propias de Pentaho son las siguientes:

• Web Ad Hoc Query and Reporting Client (WAQR): herramienta integrada en el portal que nos permite realizar querys y reporting adhoc de una forma intuitiva y sencilla, aunque con limitaciones.
• Pentaho Report Designer (PRD): a través de una herramienta de diseño desktop, que nos permite definir y construir nuestros informes, y luego publicarlos en el portal de BI para que puedan ser ejecutados por los usuarios.

Para poder trabajar con WAQR, es indispensable tener definido el correspondiente metadatos con PME (Pentaho Metadata Editor), ya que es el único origen de datos permitido en la plataforma para ese componente. En cambio, con PRD podremos utilizar otros muchos origenes de datos, aunque también podremos utilizar el metadata definido con PME como origen de datos (y asi poner una capa lógica encima del modelo físico que va a facilitar con toda probabilidad el diseño de informes).

Veamos antes de entrar en detalle con Pentaho Metadata Editor cual es el planteamiento de Pentaho respecto a los metadatos.

¿Que son los metadatos?

Como hemos visto en varias entradas del blog, los metadatos son información sobre los datos. Se utilizan en las herramientas ETL (como vimos al utilizar Talend), en las herramientas BI (como por ejemplo en Microstrategy) y Pentaho también tiene su propio enfoque.

El metadata de Pentaho esta basado en el estandar Common Warehouse Metamodel (CWM), que es una especificación creada y mantenida por el Object Management Group (OMG). Intenta ser un estandar abierto y neutral para permitir el intercambio y representación de metadatos en plataformas Business Intelligence (http://www.omg.org/technology/cwm).

Ventajas del nivel de metadatos.

El hecho de poner este nivel de metadatos por encima del nivel físico de las tablas nos proporciona algunas ventajas bastante evidentes a la hora de trabajar con nuestro sistema BI.

• Interfaz de usuario mas amigable: cuando trabajamos con bases de datos relacionales, se hace complejo la interrogación de la base de datos, pues hay que conocer en profundidad el lenguaje SQL (para sacarle todo el partido a las consultas) y también se hace necesario conocer la estructura física de las tablas. Al poner la capa de metadatos  por encima, describimos las tablas, los campos y sus relaciones, y los podemos presentar al usuario de una forma  mas comprensible para que construya sus  propios reports sin necesidad de conocer la «compleja» realidad que puede haber detras.

• Flexibilidad e independencia del esquema físico: si tenemos un gran número de informes definidos en nuestro sistema BI, y es necesario cambiar la estructura física de los datos, esto nos obligara a modificar todo los informes para adaptarlos a esta casuística. Al tener la capa de metadatos por enmedio, en un caso como este, modificaremos su esquema con los cambios realizados sin necesidad de modificar los informes. En estos casos, la capa de metadatos nos va a ayudar a absorver el impacto de los cambios en el esquema físico de la base de datos.

• Definición de privilegios de acceso: normalmente, las bases de datos nos permiten establecer privilegios de acceso sobre los objetos o sobre las operaciones que se realizan sobre ellos. Pero no nos  permiten establecer privilegios de acceso sobre la granuralidad de los datos (por ejemplo, limitaciones de lectura según las zonas geográficas, en un tipo ejemplo de informes para delegados regionales). Es decir, no tenemos un control de acceso a nivel de registro. A través de los metadatos, podemos establecer autorizaciones de este tipo bien a nivel de usuario o de rol (grupo de autorizaciones), para establecer politicas de acceso a los datos con alto nivel de detalle.

• Gestión de la localizacion (internacionalizacion): la definición de metadatos también nos  puede permitir gestionar la internacionalización de un sistema BI, definiendo propiedades como etiquetas o descripciones de las tablas y columnas a nivel de idioma. Cuando se utilizen esos elementos en los informes, aparecerán en el idioma del usuario, recuperando las descripciones (apropiadas a cada lenguaje) del metadatos.

• Homogeneización del formateo de datos: en un sistema de reporting de BI,  por ejemplo, puede ser aconsejable unificar la representación de los datos, especialmente en aquellos tipos de campos que necesita un formateo especial (importe monetarios, por ejemplo), con sus correspondientes indicadores de moneda, simbolo de decimales o de miles. Igual para el caso de links a otros informes o páginas (que se han de representar de una forma especial) o similares. El metadatos también nos puede ayudar en estos casos a definir un formato asociado a los campos, que luego se aplicara cuando sean utilizados en los informes.

Caracteristicas del metadatos de Pentaho.

Antes de ver como definir nuestro metadatos utilizando PME, vamos a ver como Pentaho utiliza esta capa en la práctica. Cuando definimos el metadatos, al terminar el proceso este queda archivado en un fichero .xmi (o a nivel de base datos, en el repositorio), y se exporta al servidor BI. En este momento ya puede ser utilizado por la herramienta de reporting Adhoc, o bien desde Pentaho Reporting Designer, para construir nuestro propios informes, utilizandolo como si fuese un origen de datos mas (como cualquier origen de base de datos relacional, por ejemplo).

La construcción de los informes se realiza sin necesidad de ver el esquema físico de los datos, sino que utilizamos la definición que se haya descrito en el metadatos. Al ejecutar uno de estos informes, la definición de las querys se guardan en un formato llamado Metadata Query Language (MQL), que se resuelve contra el metadatos, y se traduce a nivel SQL  para lanzar la consulta contra la base de datos en el lenguaje que esta entiende. Tenemos por tanto un motor MQL que se encarga de realizar este mapeo entre el esquema Lógico y el esquema Físico (tal y como podeis ver en la imagen anterior).

Podemos hablar de 3 niveles en la definición del metadatos: physical layer, logical layer y delivery layer.

En primer lugar, tenemos el physical layer, que conocen los consultores de BI en profundidad (pues lo han diseñado y construido según los requerimientos). Corresponde a los campos y tablas de la base de datos. Estos objetos son los componentes que nos van a permitir construir el logical layer (pues no tiene sentido que los usuarios finales tengan que conocer como esta creada realmente la base datos).

En el logical layer, las tablas del nivel físico son redefinidas, y enriquecidas con columnas adicionales construidas a partir de las campos de las tablas y operaciones o expresiones sobre ellas. Ademas establecemos relaciones entre las tablas, que serán la forma de extraer información de forma conjunta (joins). Ademas, podemos crear varias tablas lógicas sobre la misma tabla física, para el tratamiento,por ejemplo, de las dimensiones role-playing (la misma tabla de dimensión juega diferentes roles).

Layers en Pentaho Metadata Editor

En el delivery layer se realiza una selección de columnas de la capa lógica y se agrupan en unidades que tengan sentido para el usuario de negocio (Business View). Esta es la única parte del metadatos que es visible para los usuarios finales, y partir de ella se realizará la construcción de los informes.

En todos los niveles, podemos definir diferentes elementos, que son principalmente conceptos y propiedades. Ademas, se puede establecer como los conceptos pueden heredar propiedades de otros. Veamos un poco más en detalle en que consiste esto:

Propiedades

Los objetos en el metadata pueden tener un gran número de propiedades. Las propiedades son items con nombres que se usan para asociar diferentes tipos de información a los objetos. Las propiedades se pueden dividir en categorias:

• Propiedades generales: como el nombre y la descripción.
• Propiedades de visualización: como fuente de letra, color, etc.
• Descriptores de modelo: expresiones, tipo de datos, reglas de agregacion, etc.

Dependiendo del tipo de objeto con el que estemos  trabajando, habra propiedades que seran obligatorias y habrá que definir siempre. Otras estarán o no disponibles según el tipo de objeto.

Conceptos.

Ademas de las propiedades, en el metadata de Pentaho podemos trabajar con una colección de propiedades y agruparlas en lo que llaman Concepto. Un concepto se puede aplicar a un objeto del metadatos, y sus propiedades son heredadas por el objeto. Por ejemplo, para todos los importes monetarios (que vamos a mostrar con un formato determinado de numeros decimales) o tipo de letra, podemos crear un concepto y luego aplicarlo a todas las columnas que queremos que compartan propiedades comunes. De esta forma, en lugar de modificar las características  en los todos los objetos del metadata, lo haremos en los conceptos y asi nos aseguramos su consistencia y mantenerlo de una forma más fácil.

Herencia.

Las propiedades se pueden gestionar utilizando la herencia. La herencia ocurre basando un objeto (el objeto hijo) en otro objeto (el objeto padre). De esta forma, las propiedades del hijo y sus valores se construyen a partir de las del padre. Los cambios en las propiedades se transmiten en forma de cascada en la cadena de herencia.

Las propiedades que hereda un objeto se pueden quedar como las del padre, o bien ser modificadas y configuradas como una instanciacion propia de dichas propiedades. En ese momento se rompe la cadena de herencia de esa propiedad con respecto al padre. Cuando se modifique algo del padre, no se modificara la propiedad en el  hijo. En Pentaho tenemos dos niveles de herencia:

• Herencia de objetos derivados: los objetos del metadata heredan las propiedades de sus objetos padre. Por ejemplo, definimos una tabla en el nivel físico y configuramos sus propiedades. Al utilizarla en el logical layer, todas las propiedades de nombres de tabla, campos, formatos, autorizaciones que hubieramos definido antes se heredan en el nuevo objeto. Si la tabla fisica se utiliza en varios tablas lógicas, todas heredaran las  mismas propiedades. Puede ser util, pues seguramente para unas columnas  determinadas pondremos unas descripciones y un formato que nos interesan que se utilicen en todos los sitios de la misma manera. En ese caso, cualquier cambio en el modelo físico se transmitiran a los objetos «descendientes».
• Herencia de conceptos: como hemos visto los conceptos son una forma de asignar propiedades a los objetos de una forma centralizada. Dentro de los conceptos, podemos establecer tambien jerarquía de propiedades, de forma que podemos tener un concepto general, y luego conceptos descendientes de este con propiedades especificas (que luego podremos también asignar a los objetos del metadatos).

Pentaho Metadata Editor.

Como paso final, vamos a ver como definir el metadatos para nuestro modelo (en una entrada anterior del blog vimo como quedaba la estructura física de nuestra base de datos), teniendo en cuenta todas las características de PME vistas hasta ahora.

Al trabajar con PME, podemos utilizar un repositorio local (a nivel de ficheros) o un repositorio de base de datos. El repositorio de PME es independiente del de la plataforma BI o el de Kettle, no tiene nada que ver. Se trabaja con el concepto de Dominio, que es un contenedor que incluye la definición del metadatos.

Los tres niveles que hemos indicado antes (physical layer, logical layer y delivery layer), se implementan de la siguiente manera.

Physical Layer

Contiene los objetos físicos que existen a nivel de base de datos. Es la parte básica de la definición del metadata. Podemos tener varios origenes de datos (varias conexiones), de las que seleccionaremos las tablas que nos interesen para nuestro modelo, y para cada tabla, los campos que la componen. Podemos seleccionar solo aquellos campos que nos interesen, o bien seleccionarlos y luego ocultarlos cuando pasemos al nivel lógico.

• Conexiones: definimos las conexiones de la forma habitual (es necesario tener el jdbc correspondiente y depositarlo en el directorio \libext\jdbc dentro de la carpeta donde tengamos instalado PMD).
• Tablas: desde la conexión, con el menú contextual podremos importar las tablas que queremos añadir a nuestro modelo (con la opción Import Tables o desde Import from explorer). Una vez las tablas estan importadas, podremos modificar sus propiedades, tales como su nombre (incluyendo la internacionalización), descripcion, tipo de tabla (Dimension, Hechos u Otros)

Database Explorer

• Campos: por defecto, se importan todos los campos de las tablas. Posteriormente podemos eliminar aquellos campos que no nos interese tener en el metadata, o bien incluir nuevos campos, como calculos de los existentes o iguales que los existentes pero cambiando determinadas propiedades (por ejemplo, el formato). Al igual que en las tablas, en los campos tenemos un conjunto de propiedades (Nombre, Descripción, Fuente, Color, Alineación del texto, Tipo de datos, forma de agregación). Si el campo es una formula, podremos indicar la composición de esta y también podremos indicar si el campo queremos que este oculto. Además de estas propiedades por defecto, podemos añadir otras, como temas de seguridad, mascaras de edición, ancho de columna, textos explicativos adicionales, etc.

Propiedades de metadata de los campos en una tabla física

A la hora de la construcción de los campos físicos, podemos definir campos que sean operaciones entre varios campos o formulas. Para ampliar la información sobre esta funcionalidad, podeís ver la documentación Online de Pentaho.

Logical Layer.

Una vez tenemos definidos todos los componentes del nivel físico (que van a ser las piezas básicas de nuestro metadatos), continuaremos con el segundo nivel, el nivel lógico.

• Business Models: es un contenedor que nos permite agrupar los objetos lógicos y sus relaciones, para disminuir de la mejor manera posible el impacto de los cambios a nivel físico. Podemos tener varios modelos de negocio dentro de un dominio de metadatos (aunque solo soporta una conexión a base de datos por cada uno de ellos).
• Business Tables y Columns: cuando creamos una nueva Business Table, nos aparece la lista de tablas físicas disponibles en nuestro dominio y seleccionamos las que nos interesan. En ese momento se crean la BT, como una abstracción de la tabla física. Como podeís ver en la imagen, cada tabla lógica (business table) tiene asociada su correspondiente tabla física, y hereda todas las propiedades que tuviera esta. Podemos dejar los atributos como estan o modificarlos en el caso de que nos interese. La tabla también hereda todos los campos que tuviera definidos la tabla física, aunque se pueden eliminar los que queramos. A la hora de añadir, solo se pueden utilizar los definidos en la tabla física, aunque podremos añadir cuantas veces deseemos campos que ya existen y modificar sus propiedades para crear nuevos campos.

Editor de propiedades de las Business Tables

• Relaciones: puede haber casos en que para hacer la lectura de datos, necesitemos juntar varias tablas. En la parte de relaciones, definimos como se va a realizar el join entre las diferentes tablas de nuestro modelo. En la imagen podeis ver el correspondiente editor donde vamos definiendo, en cada tupla de tablas, como va a ser la relación entre ellas.

Editor de relaciones entre Business Tables

Delivery Layer.

La parte final de la definición del metadata es decidir, de todos los elementos de los que disponemos en el modelo de negocio, cuales van a estar a disposición de los usuarios. Esto lo realizamos a traves de las Business Views y las Business Categories. Veamos en que consiste esto:

• Business Views: las vistas de negocio son los contenedores que visualizaran los usuarios, y que contendrán los elementos que van a poder utilizar en el reporting y análisis ad-hoc. Podremos tener varias vistas de negocio a través de lo que llamamos categorias. Las categorias pueden contener una tabla lógica completa o bien una lista de campos seleccionados de varias tablas lógicas. Las diferentes categorias apareceran luego en el reporting, con todos los elementos que hayamos incluido en su definición. Aquí también podremos incluir seguridad para determinar que usuarios pueden trabajar con ellas. Las propiedades de los elementos, igual que con las tablas de negocio, son heredadas de estas, aunque pueden ser modificadas (sobrescribiendo la herencia por defecto).

Gestión de categorias

Hemos realizado la definición del metadata de nuestro proyecto EnoBI para permitir el reporting sobre el.  Como paso final, nos quedaría publicar el metadatos en el portal de BI para poder utilizarlo en el reporting ad-hoc. Para ello, lo publicaremos en el portal (solo puede haber un fichero por solución). También podriamos haber hecho público el fichero ubicandolo en la correspondiente carpeta del servidor (colgando de pentaho-solutions). Igualmente, podemos exportar el fichero xmi para utilizarlo directamente con Pentaho Reporting Designer, como un origen de datos más a la hora de construir los informes.

Publicacion del metadata en el servidor BI

Para trabajar con PRD no hace falta publicar en el servidor BI, sino que accedemos directamente al fichero xmi como origen de datos. Para verificar que el metadata esta correctamente importado en el portal BI, nos conectamos con nuestro usuario de pruebas y realizamos nuestro primer informe Ad-hoc. Todo se ha configurado correctamente.

Informe Adhoc - Ejemplo sencillo de listado de clientes

Podeis ampliar información sobre todo lo visto en esta entrada del blog en la documentación online de Pentaho. A continuación vamos a ver como podemos definir nuestro esquema dimensional utilizando Pentaho Schema Workbench, lo que nos permitira posteriormente trabajar con los análisis sobre los cubos Olap.

17.1. Instalación y configuración de la plataforma BI de Pentaho.

Con la ultima versión estable de la plataforma BI descargada de la web de Pentaho (la 3.5.2), y siguiendo las instrucciones de Prashant Raju para esta versión en la plataforma Windows utilizando MySql, realizamos la instalación y configuración de nuestro sistema realizando los siguientes pasos:

1) Requisitos previos: maquina virtual Java y la base de datos MySQL (u otra de las soportadas).

Para poder ejecutar la plataforma de BI de Pentaho es necesario disponer de una máquina virtual Java instalada en el equipo donde vamos a trabajar. Pentaho recomienda la versión 1.5 de Sun JRE. Con versiones anteriores no funciona y la 1.6 no esta oficialmente soportada (es la que tengo instalada yo), aunque si funciona.

Para ver la versión instalada, ejecutaremos el comando: java  -version. En el caso de no disponer de la máquina, podemos descargarla en la web de Sun.

A continuación comprobaremos que la variable de entorno JAVA_HOME apunte al directorio donde tenemos instalado Java. Igualmente, la variable PATH también debera apuntar al directorio de ejecutables de la instalación de Java. En mi caso, el valor de las variables será el siguiente:

JAVA_HOME   c:\Program Files\Java\jdk1.6.0_17
PATH        c:\Program Files\Java\jdk1.6.0_17\bin;.....

Para configurar las variables, lo realizaremos desde Propiedades del Sistema, Variables de Entorno.

Con respecto a MySQL, en el caso de que no lo tengamos instalado en nuestra máquina, lo descargaremos de la web y realizaremos la instalación según las instrucciones que nos proporcionan en su portal de documentación.

2) Descomprimir los ficheros de la plataforma.

Seleccionamos una carpeta (por ejemplo c:\pentaho), y en ella vamos a descomprimir el fichero Zip que nos hemos bajado de la web. Tras el proceso, tendremos dos carpetas diferenciadas, llamadas administration-console y biserver-ce. La primera carpeta alberga los ficheros de la plataforma de administración, que utilizamos para configurar y administrar el servidor BI (utiliza Jetty). La segunda, es la plataforma de BI propiamente dicha (la que utilizarán los usuarios), que utiliza tomcat.

En este momento, ya podriamos arrancar la plataforma desde los correspondientes scripts que se encuentran en la carpeta c:\pentaho\biserver-ce (start-pentaho.bat para iniciar el servidor y stop-pentaho.bat para pararlo). Este Script arranca en primer lugar la base de datos HSQLDB de ejemplo (donde residen las datos necesarios para el funcionamiento de la plataforma, junto con datos de pruebas para los ejemplos precargados). A continuación, arranca la plataforma de BI, a través del tomcat. Como no queremos trabajar con esa base de datos, sino con MySQL, vamos a proceder a realizar una serie de ajustes antes de arrancar la plataforma.

3) Creación de catalogos en base de datos necesarios para la plataforma.

La plataforma Pentaho necesita dos bases de datos para su funcionamiento (además de la base de datos de test para poder trabajar con el set de ejemplos). Las bases de datos y su cometido son las siguientes:

• hibernate: esta base de datos almacena la autentificación de usuarios y los datos de autorizaciones, el contenido BI (solution repository) y los origenes de datos disponibles en la plataforma.
• quartz: es el repositorio para el scheduler Quartz, que es uno de los componentes que forma la plataforma, que nos permite la planificación de procesos dentro del servidor BI.
• sampledate: contiene las tablas para ilustrar y hacer posible la ejecución de todos los ejemplos por defecto que proporciona la plataforma, para poder hacernos una idea de sus funcionalidades y sus posibilidades de análisis.

Por defecto, los catálogos de estas bases de datos estarán creados en la base de datos HSQLDB que se puede arrancar en la configuración del servidor por defecto.  Para crearlos en MySQL, como es nuestro caso, ejecutaremos los scripts que se encuentran en la carpeta c:\pentaho\biserver-ce\data o bien descargarlos de la web de Prashant Raju. Decido utilizar estos últimos, pues ademas de crear todos los catalogos de tablas, también incluye la carga de datos de ejemplo (paso 5), que es una opción que no incluye la instalación estandar. El orden de ejecución será el siguiente:

mysql> source 1_create_repository_mysql.sql;
 ...output
 mysql> source 2_create_quartz_mysql.sql;
 ...output
 mysql> source 3_create_sample_datasource_mysql.sql;
 ...output
 mysql> source 4_load_sample_users_mysql.sql;
 ...output
 mysql> source 5_sample_data_mysql.sql;
 ...output

La ejecución de los scripts sql la realizaremos desde MySQL Query Browser (la herramienta gráfica para ejecución de sentencias SQL) o bien desde linea de comandos con la utilidad mysql que llevar incluido el servidor MySQL para ejecutar scripts. Podiamos haber utilizado cualquier otro editor sql, como SQuirreL.

4) Configuracion JDBC, Hibernate and Quartz.

Todas las aplicaciones de Pentaho, incluyendo el Pentaho Server, utilizan la conectividad JDBC (Java Database Connectivity) para la comunicación con las bases de datos. Por tanto, será necesario disponer de los correspondientes conectores según la base de datos que vayamos a utilizar. En nuestro caso, vamos a dejar tanto el conector para MySQL (donde iran las bases de datos de Hibernate y Quartz), como el de Oracle (donde va la base de datos del DW). Las carpetas donde vamos a copiar serán las siguientes:

• C:\Pentaho\biserver-ce\tomcat\common\lib: ubicación de los drivers JDBC para poder utilizar en el servidor Pentaho la base de datos para la que el conector proporciona conectividad.
• C:\Pentaho\administration-console\jdbc: es necesario ponerlos aquí también para poder definir correctamente las conexiones a base de datos en la consola de administración.

A continuación, configuraremos los ficheros de parametrización del sistema para que Hibernate y Quartz lean de los catalogos de base de datos en Mysql que hemos creado en el punto 3, en lugar de la base de datos HSQLDB proporcionada por defecto.

• Configuracion de Hibernate (I): en el fichero applicationContext-spring-security-jdbc.xml (ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system), modificaremos la parte que veis subrayada a continuación, con los valores referidos para utilizar MySQL.

<!--  This is only for Hypersonic. Please  update this section for any other database you are using --> 

<bean id="dataSource"

class="org.springframework.jdbc.datasource.DriverManagerDataSource">

<property name="driverClassName" value="com.mysql.jdbc.Driver" />

<property  name="url"

value="jdbc:mysql://localhost:3306/hibernate"  />

<property  name="username" value="hibuser" />

<property name="password" value="password" />

</bean>

• Configuracion de Hibernate (II): en el fichero applicationContext-spring-security-hibernate.xml (ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system), modificaremos la parte que veis subrayada a continuación, con los valores referidos para utilizar MySQL.

jdbc.driver=com.mysql.jdbc.Driver

jdbc.url=jdbc:mysql://localhost:3306/hibernate

jdbc.username=hibuser

jdbc.password=password

hibernate.dialect=org.hibernate.dialect.MySQLDialect

• Configuración de Hibernate (y III): en el fichero hibernate-settings.xml ( ubicado en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system\hibernate), modificaremos la parte que veis subrayada a continuación.

<config-file>system/hibernate/mysql5.hibernate.cfg.xml</config-file>

Con la configuración anterior, hemos configurado la seguridad JDBC de la plataforma. Ahora nos falta indicar en los contextos del servidor de aplicación, la ubicación de las bases de datos, para decirle al servidor que lea de las bases de datos en Mysql, utilizando los drivers y la configuración de seguridad realizada anteriormente. Para ello, modificamos el fichero contexts.xml (ubicado en C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\META-INF) de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>
 <Context path="/pentaho" docbase="webapps/pentaho/">
 <Resource name="jdbc/Hibernate" auth="Container" type="javax.sql.DataSource"
 factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
 maxWait="10000" username="hibuser" password="password"
 driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/hibernate"
 validationQuery="select 1" />

<Resource name="jdbc/Quartz" auth="Container" type="javax.sql.DataSource"
 factory="org.apache.commons.dbcp.BasicDataSourceFactory" maxActive="20" maxIdle="5"
 maxWait="10000" username="pentaho_user" password="password"
 driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/quartz"
 validationQuery="select 1"/>
 </Context>

Con esta configuración ya tendriamos lista la parte de conectividad con la base de datos. Solo en el caso de que no hubieramos utilizado los scripts de Prashant Raju, tendriamos que realizar un último paso, que sería ejecutar la siguiente sentencia SQL para indicarle al servidor que los datos de ejemplo los hemos cambiado de lugar:

UPDATE hibernate.DATASOURCE
 SET DRIVERCLASS = 'com.mysql.jdbc.Driver’,
 URL = 'jdbc:mysql://localhost:3306/sampledata’,
 QUERY = 'SELECT 1’
 WHERE NAME = 'SampleData’
 ;

5) Configuración Servidor Apache-Tomcat.

La plataforma Pentaho utiliza Apache-Tomcat como servidor de aplicaciones para desplegar los servicios que la componen. El servidor lleva una configuración por defecto que podemos modificar (por ejemplo, para variar el puerto donde nos conectamos, para el caso de que haya conflicto con otras aplicaciones instaladas en el servidor), la ubicación html, el lenguaje, etc. Para ello, modificaremos el fichero web.xml que se encuentra en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\WEB-INF. Veamos alguna de la cosas que podemos cambiar.

solution-path

Con este parámetro, le indicamos a la plataforma BI la ubicación de la carpeta pentaho-solutions. Por defecto, tiene el valor c:\biserver-ce\.

En nuestro caso, vamos a cambiar el valor para que apunte a la carpeta donde hemos instalado:

<context-param><param-name>solution-path</param-name>
 <param-value>C:\Pentaho\biserver-ce\pentaho-solutions</param-value>
 </context-param>

base-url

Al instalar, la ruta URL por defecto para acceder a la plataforma será la siguiente: http://localhost:8080/pentaho

Podemos cambiarla si lo desamos modificando el parmetro base_url dentro del mismo fichero. En nuestro caso, como vamos a cambiar el puerto por defecto, modificamos su valor indicando lo siguiente:

<context-param>
 <param-name>base-url</param-name>
 <param-value>http://localhost:9999/pentaho/</param-value>
 </context-param>

Esto nos obligará a cambiar tambien la configuración del fichero server.xml, que veremos mas adelante.

port

En la ruta C:\Pentaho\biserver-ce\tomcat\conf, tenemos el fichero server.xml, donde podemos modificar el puerto por defecto de nuestro servidor BI (que es el 8080).

<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
 <Connector port="9999" maxHttpHeaderSize="8192"
 maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
 enableLookups="false" redirectPort="8443" acceptCount="100"
 connectionTimeout="20000" disableUploadTimeout="true" />

Ahora pararemos el servidor tomcat y al arrancar la nueva URL de acceso será la siguiente: http://localhost:9999/pentaho

6) Otros elementos. Scripts arranque. Configuración de la publicación de contenidos y del correo SMTP.

Antes de continuar, vamos a ajustar el script de arranque de la plataforma BI, omitiendo la parte de arranque de la base de datos HSQLDB, que por defecto se arranca cuando lanzamos el script start-pentaho.bat (de la carpeta c:\pentaho\biserver-ce). Es tan sencillo como comentar la linea donde se arranca la base de datos. El script quedaría como sigue (la linea subrayada se ha comentado para que no se ejecute):

@echo off
setlocal
cscript promptuser.js //nologo //e:jscript
rem errorlevel 0 means user chose "no"
if %errorlevel%==0 goto quit
echo WScript.Quit(1); > promptuser.js

if exist "%~dp0jre" call "%~dp0set-pentaho-java.bat" "%~dp0jre"
if not exist "%~dp0jre" call "%~dp0set-pentaho-java.bat"

cd data
rem start start_hypersonic.bat
cd ..\tomcat\bin
set CATALINA_HOME=%~dp0tomcat
set CATALINA_OPTS=-Xms256m -Xmx768m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
set JAVA_HOME=%_PENTAHO_JAVA_HOME%
call startup
:quit
endlocal

Ademas de toda la configuración realizada hasta ahora, nos quedan por configurar dos aspectos importantes para el funcionamiento del sistema:

• Publicación de contenido: por defecto, la publicación de contenido en el servidor BI esta desactivada, por lo que para publicar los informes o análisis que vayamos realizando, lo deberiamos de hacer dejando los ficheros en la correspondientes carpetas del servidor. Pero es mas fácil hacerlo mediante lo que se llama publicación (que veremos en detalle mas adelante). Para habilitar la publicación, modificaremos el fichero publisher_config.xml, que se encuentra en la carpeta C:\Pentaho\biserver-ce\pentaho-solutions\system. Ahí indicaremos la contraseña de publicación. Por defecto, no tiene ninguna contraseña, y por tanto, no esta habilitada la publicación.

<publisher-config>
 <publisher-password>passpublic</publisher-password>
</publisher-config>

• Servicio de correo SMTP: como ultimo paso, configuraremos la posibilidad de envio de correo electrónico, a través de un servidor externo (ya que la plataforma no dispone de un servidor de correo electrónico propio). Para ello, configuraremos el fichero email-config.xml en el directorio C:\Pentaho\biserver-ce\pentaho-solutions\system\smtp-email, de la siguiente manera:

<email-smtp>
 <properties>
 <mail.smtp.host>smtp.gmail.com</mail.smtp.host>
 <mail.smtp.port>587</mail.smtp.port>
 <mail.transport.protocol>smtps</mail.transport.protocol>
 <mail.smtp.starttls.enable>true</mail.smtp.starttls.enable>
 <mail.smtp.auth>true</mail.smtp.auth>
 <mail.smtp.ssl>true</mail.smtp.ssl>
 <mail.smtp.quitwait>false</mail.smtp.quitwait>
 </properties>
 <mail.pop3></mail.pop3>
 <mail.from.default>respinosamilla@gmail.com</mail.from.default>
 <mail.userid>respinosamilla@gmail.com</mail.userid>
 <mail.password>password</mail.password>
</email-smtp>

En este caso, estoy utilizando gmail para enviar los correos desde la plataforma. Los valores subrayados son los que yo he indicado. En el caso de estar utilizando otro servidor de correo, tendreís que modificar la configuración de servidor, puertos, tipo de conexión, ect, para que funcione según la configuración de este. Con esta funcionalidad habilitamos la distribución de contenido a través del correo electrónico (por ejemplo, para el envío de la ejecución de informes o análisis).

En este momento, ya podemos arrancar la plataforma. Al iniciarla, y conectarnos en el puerto http://localhost:9999, nos aparece la consola de usuario, con una configuración por defecto. Tendría el siguiente aspecto.

Consola de Usuario por defecto

Ya podemos conectarnos con alguno de los usuarios existentes y trastear con el proyecto de ejemplo Steel Wheels o la colección de muestras y ejemplos que incluye la plataforma. Con ellos nos podemos hacer una idea de las posibilidades de análisis de las que vamos a disponer.

Personalizando la plataforma de usuario.

Como queremos personalizar el portal, vamos a realizar algunos cambios en la consola de usuario (también llamada Mantle). Para ello, vamos a utilizar el blog de Prashant Raju donde nos explica muy bien los pasos a seguir para configurar nuestra plataforma. Esta personalización va a consistir en lo siguiente:

No queremos que aparezcan los usuarios de ejemplo al conectarnos al sistema.

Con la configuración por defecto del sistema, cuando entramos al portal de usuario, nos aparece la siguiente ventana:

Aparecen los usuarios de ejemplo, y al seleccionarlos podemos entrar directamente en la plataforma (sin necesidad de recordad su nombre de usuario o contraseña), ya que el sistema nos lo recuerda. Esto no es operativo para un sistema productivo, y por tanto, vamos a modificarlo. Para ello, modificaremos el fichero loginsettings.properties (ubicando en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantleLogin). La configuración por defecto del fichero es la siguiente:

# this file contains settings to configure the login dialog
# flag to turn on/off show users list (overrides pentaho.xml)
#showUsersList=true
# launch PUC in new window (default setting)
openInNewWindow=false
# sample users (be sure that each group has the same # of items as the rest)
userIds=joe, suzy, pat, tiffany
userDisplayNames=Joe (admin), Suzy, Pat, Tiffany
userPasswords=password, password, password, password

Vamos a modificar los valores de la siguiente manera:

# this file contains settings to configure the login dialog
# flag to  turn on/off show users list (overrides pentaho.xml)
showUsersList=false

Reiniciamos el servidor y al entrar en el portal, el aspecto de login habrá variado, apareciendo la siguiente pantalla:

Este login es mas acorde con un sistema donde hay que mantener la seguridad.

Ventana de conexión personalizada para nuestra empresa.

Para modificar el aspecto de la ventana de login, hemos de modificar el fichero PUC_login.jsp que se encuentra en la carpeta C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\jsp. En este fichero hemos modificado textos, alguna de las imagenes que aparecen, hasta conseguir el siguiente aspecto:

Esto es solo un ejemplo sencillo de como podemos ajustar el diseño de la página a las necesidades corporativas de una empresa (logos, infografia, etc). Os dejo el link al fichero PUC_login.jsp modificado.

Configuración de mensajes de login y de mensajes de error.

Para modificar los mensajes de usuario en el momento del login, habrá que modificar el fichero MantleLoginMessages_es.PROPERTIES (para el caso del idioma castellano, o el fichero MantleLoginMessages_en.PROPERTIES en el caso de estar trabajando con el ingles). El fichero se encuentra en dos ubicaciones distintas y habra que modificarlo en ambos casos para que siempre salgan los mismos mensajes. Las ubicaciones son las siguientes:

• C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantleLogin\messages
• C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantle\messages

Cambiaremos los textos de los mensajes, y al grabar el fichero automaticamente seran utilizados por el servidor con los nuevos valores.

Personalización del panel de control y del area de trabajo.

Se pueden personalizar muchisimos aspectos de la consola de usuario (area de trabajo), tal y como nos cuenta Prashant Raju en su blog, desde los logotipos, barras de menu, barra de herramientas, colores, etc. En nuestro ejemplo, vamos a modificar el fichero launch.jsp (ubicado en C:\Pentaho\biserver-ce\tomcat\webapps\pentaho\mantle\launch). En el ejemplo, he modificado el fichero para que en la parte de la derecha aparezca mi blog a los usuarios de la plataforma, en el momento de conectarse. El resultado es el siguiente:

Workspace personalizado

Este es solo un ejemplo sencillo de lo que se puede personalizar, que puede ser casi todo (hasta el código fuente si fuese necesario).

Con todos los elementos que hemos configurado, la plataforma de BI de Pentaho esta preparada y lista para ser utilizada, y ademas personalizada a nuestro gusto o necesidades. A continuación vamos a ir viendo las diferentes herramientas que nos proporciona Pentaho para construir nuestros análisis y la forma de configurar su ejecución dentro de la plataforma BI de Pentaho. Además realizaremos la configuración del metadata y la definición de los cubos Olap que luego nos permitiran realizar los análisis dimensionales.

17. Implementando nuestro sistema BI con Pentaho.

Durante los próximos días vamos a montar nuestro sistema de Business Intelligence utilizando la Community Editión de Pentaho. Hemos conseguido concluir el diseño de los procesos ETL que van a llenar nuestro Data Warehouse a partir de nuestros sistemas origen y ahora queremos explotar esta información en los diferentes ambitos de la inteligencia de negocio, pero con Pentaho CE. Para ello, configuraremos en primer lugar la plataforma de BI, realizando las siguientes tareas:

• Descarga del software necesario: nos descargamos la ultima versión estable de los diferentes elementos de la plataforma y del proyecto en la web de Pentaho.
• Instalación y configuración de la plataforma BI para utilizar con MySql y Windows 7. En esta base de datos tendremos el catalogo para el BI Server (aunque la base de datos del DW la tendremos en Oracle, como ya vimos).
• Personalización del portal: realizaremos un tuneado del portal para adaptarlo a los requerimientos del proyecto, personalizando logotipos, pantalla de inicio, menús, para ver las posibilidades de configurarlo según las necesidades del cliente. Prepararemos igualmente el metadata y los diferentes cubos de análisis antes de continuar con el resto de herramientas.

A continuación, una vez preparada la plataforma, iremos haciendo un recorrido por las diferentes soluciones de las que dispone Pentaho para abordar el análisis de nuestro datos:

• Reporting: Pentaho Report Designer. Otras posibilidades de reporting (Birt y JasperReports).
• Analisis Olap: Cubos Olap y navegación dimensional con Mondrian, jpivot y stpivot.
• Cuadros de mando y tableros en Pentaho con Community Dashboard Framework (CDF).
• DataMining con Weka.
• Integración de otros componentes: Design Studio.

Los materiales que vamos a utilizar para este cometido serán principalmente los siguientes:

• Libro Pentaho: como guia para el recorrido por todas las soluciones he elegido el libro Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL, escrito por Roland Bouman, Jos van Dongen.
• Documentación Web:  BI Server 2.x-3.x Community Documentation, Mondrian, Pentaho Reporting, Weka, Wiki de la comunidad Pentaho, Community Dashboard Framework, Demos y Videos, Youtube, etc.

• Prashant Raju: en su blog ha incluido una serie de articulos donde explica aspectos tan interantes como la personalización de la consola de Usuario de Pentaho (Mantle), guias de instalación y configuración para trabajar con diferentes bases de datos ( MySql, PostgreSQL y Oracle ), serie de tutoriales para trabar con Pentaho Report Designer, etc.
• Maquina Virtual: en dataprix.com, gracias al magnifico trabajo de Carlos Fernandez y Dario Bernabeu, teneis una máquina virtual de la plataforma Pentaho totalmente operativa, incluyendo ejemplos de todos los componentes listos para funcionar. Puede ser un punto de partida para ver una plataforma totalmente operativa, utilizando VMWare.

La arquitectura de nuestro sistema va a ser la siguiente:

Configuración de nuestro sistema BI

Os adelanto que nos va a tocar modificar bastantes ficheros de configuración para que todo funcione correctamente y para personalizar tanto el portal como el funcionamiento de las herramientas, lo cual resulta un poco farragoso en ocasiones. Por ejemplo, para las conexiones a Base de Datos, hay que configurar lo mismo en un montón de sitios, echandose de menos una especie de repositorio común.  Empezemos…

15. Business Intelligence Open Source. Proyecto EnoBI usando Pentaho.

Tal y como prometimos, vamos a replicar nuestro proyecto EnoBI utilizando herramientas Open Source. En concreto, vamos a utilizar Pentaho y todo el conjunto de aplicaciones del que disponemos en la Community Edition.

Han pasado ya 5 meses desde que empezamos a «estudiar» para adentrarnos y profundizar en el interesante mundo del Business Intelligence. Hemos visto muchas cosas, teoría, práctica, ejemplos, etc, que ademas nos han permitido profundizar en el uso de varias herramientas (Mysql como base de datos, Talend como herramienta ETL y Microstrategy 9 como plataforma integral de Business Intelligence).

Dando una releida a todo lo publicado, en especial lo referente al proyecto EnoBI (que era un modelo de empresa real dedicada a la elaboración de vinos), y repasando conceptos, teoría, opiniones leidas en otros blogs, libros de referencia, etc.,  llega el momento de revisar el modelo definido, ajustarlo, corregirlo (pues seguramente hemos cometido errores de principiante) y ampliarlo teniendo en cuenta cosas que no consideramos en su día (por ejemplo, el tratamiento de las dimensiones lentamente cambiantes (bis), las claves subrogadas, creación de una area de stage, etc). Ademas, vamos a ampliar el modelo de datos para incluir información de presupuestos para poder comparar los datos de ventas reales con los presupuestados.

Arquitectura Plataforma BI Pentaho

Este revisión del diseño de nuestro modelo (modelo conceptual y modelo físico) será el punto de partida de la implementación del sistema BI, pero utilizando, en este caso, las siguientes herramientas:

• Base de datos: Oracle 10g Enterprise.
• Herramienta de Modelado: Oracle SQL Developer (no dejeis de leer el articulo referente a él en dataprix.com)  y Sybase Power Designer.
• Procesos ETL: Pentaho Data Integration (Kettle).
• Sistema BI: Pentaho Community Edition y todas las herramientas del proyecto (Pentaho BI Platform, Mondrian, Pentaho Reporting y Weka).

Antes de continuar, vamos a hacer una recopilación de fuentes que utilizaremos para el desarrollo de la evaluación.

• Libros:el mundo Pentaho pega fuerte con la aparición de varios libros. Los que yo voy a mirar para las pruebas:
  • Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL®. Roland Bouman y Jos van Dongen. ISBN: 978-0-470-48432-6.
  • Pentaho 3.2 Data Integration- Beginner’s Guide. Maria Carina Roldan. ISBN: 978-1-847199-54-6.
• Documentación: en el proyecto Pentaho existe una amplia documentación de todas las herramientas (Pentaho BI Platform, Kettle, Mondrian, Pentaho Reporting y Weka) . La parte de Pentaho Data Integration (Kettle) esta traducida al castellano gracias a la gran aportación Bernabeu Dario (que colabora en muchos sitios, al igual que con su metodologia Hefesto para el diseño de DW).
• Web y blogs: hay una comunidad muy grande de gente trabajando con Pentaho y compartiendo sus conocimientos y experiencias. Aquí os dejo alguno de los links que he encontrado:
  • Red Openbi: en esta red hay varios grupos de trabajo con productos Pentaho. En castellano.
  • Almacen de datos: algunos tutoriales sobre Pentaho.
  • Analyse This: blog de Prashant Raju con ejemplos trabajando con Pentaho.
  • Blogs de la comunidad Pentaho: Matt Caster on Data Integration y alguno de los gurus y promotores de los proyectos de Pentaho.
  • Forums de Pentaho: foros de la comunidad donde consultar nuestras dudas o leer consultas anteriores. También tenemos los forums en castellano.
  • Video Tutoriales de Pentaho en la comunidad redopenbi.com. Otros video tutoriales: Instalación de Pentaho, Videos y recursos de DataMining con Weka.
  • Todobi.com: amplia información sobre todos los productos de Pentaho: Kettle,  Mondrian, Pentaho, Weka, jpivot, etc.
  • Dataprix.com: coleccion de articulos, tutoriales. Interesante una imagen virtual Vmware con una instalación completa de Pentaho 2.0.. Incluye ejemplos practicos de todo (Kettle, Dashboard, Informes, etc).

Empecemos…

Aplicaciones para gestión de Incidencias y Bugs. Productos OpenSource.

En el desarrollo de cualquier proyecto o en la gestión del soporte en cualquier ambito de los sistemas de información (tanto si se trata de soporte interno o a clientes), se requiere el uso de herramientas apropiadas que nos permitan la gestión de dicho soporte, permitiendonos hacer un seguimiento de los procesos, realizar tareas de control o reporting, así como documentar adecuadamente las acciones realizadas.

En el mundo OpenSource, existen multitud de herramientas orientadas a la gestión de incidencias, tickets o bugs. Herramientas que nos pueden servir para la gestión de un Help Desk o como soporte al desarrollo de nuevos proyectos o la gestión de los bugs y problemas detectados en un producto software. Yo particularmente llevo 5 años trabajando con Eventum, la solución desarrollada internamente en  el proyecto de MySql y que posteriormente fue liberada al público para su uso. Es muy sencilla de utilizar y configurar (PHP+MySql) y puede ser valida para la gestión de soporte y documentación de incidencias en un departamento de Informática de una empresa pequeña o mediana.  Podeis validarla en mi portal de pruebas (con el usuario supervisor@ejemplo.com, contraseña supervisor). Hay creados un lote de incidencias para que veais los informes, los estados y prioridades de cada una y las cosas que se pueden incluir en las incidencias (ficheros anexos, notas internas, imputación de tiempos consumidos, correos, etc). Podeis crear vuestras propias incidencias con el usuario indicado.

Interfaz de usuario de Eventum

Ademas, tenemos muchas mas opciones Open para el mismo cometido. Teneis una interesante comparativa de herramientas en la Wikipedia. Igualmente, se ofrece una buena recopilación en Opensourcehelpdesklist.com,  software-pointers.com y webresourcedepot.com. Hay proyectos muy curiosos, como el Bugzilla, desarrollado originariamente a nivel interno en el proyecto Mozilla( y utilizado por ejemplo, en el proyecto Eclipse); el mismo Trac, utilizado en la Nasa para el desarrollo de proyectos y por WordPress;  o Jira, usado por la Apache Software Foundation y muchos otros proyectos de desarrollo Open Source, como Pentaho o JBoss (pues aunque es un producto propietario, se cede su uso para proyectos Open Source o para organizaciones sin animo de lucro). Como producto de pago, es usado en empresas tan importantes como BMW, Adobe, Yahoo o Boeing  (ver lista completa aquí).

Otras iniciativas, como Google Code, proporcionan una serie de recursos para desarrolladores, así como hosting para proyectos Open Source (similar a Sourceforge ). En este hosting se incluyen el uso de herramientas para la gestión de proyectos, como Wiki o gestión de Issues (Bugs). Podeis ver un ejemplo con el proyecto Hypertable (ideado para la gestión de grandes volumenes de datos, tema del que precisamente estan hablando nuestros amigos de Dataprix.com).

Os dejo un pequeño resumen con los links a las páginas de alguno de los proyectos o fabricantes:

Aplicacion	Creador	Licencia	Lenguaje/BD
BugTracker.NET	Corey Trager	GPL	ASP.NET/C# on Windows(SQL Server, SQL Server Express)
Bugzilla	Mozilla Foundation	MPL	Perl(MySQL, Oracle, PostgreSQL)
Debbugs	Debian	GPL	Perl (Flatfile, BDB indexes)
DisTract	Matthew Sackman	New BSD	Haskell, Javascript (Monotone)
Eventum	Mysql	GPL	PHP (MySQL)
Flyspray	flyspray.org	LGPL	PHP (ADOdb)
Fossil	D. Richard Hipp	GPLv2	C (Fossil)
Gemini	Countersoft	Proprietary, Free for non profit / open source	ASP.Net/C# (Microsoft SQL Server)
GNATS	Free Software Foundation	GPL	C (MySQL)
GLPI	INDEPNET	GPL	PHP (MySQL)
Google Code Hosting	Google Code	Proprietary, available for open source projects	Python (BigTable)
JIRA	Atlassian	Proprietary, Free for non-commercial use	Java (MySQL, PostgreSQL, Oracle, SQL Server)
Liberum Help Desk	Doug Luxem	GPL	ASP (SQL Server, Access)
Kayako SupportSuite	Kayako	Proprietary, some parts GPL	PHP (MySQL)
LibreSource	Artenum	GPLv2	HTML/Java on all platforms (PostgreSQL)
MantisBT	Various (Open source contributors)	GPLv2	PHP (ADOdb (MySQL, PostgreSQL, MS SQL, etc))
OTRS	otrs.org	AGPL	Perl (MySQL, PostgreSQL, Oracle, SQL Server)
Redmine	Jean-Philippe Lang	GPL	Ruby on Rails (MySQL, PostgreSQL, SQLite)
Request Tracker	Best Practical Solutions, LLC	GPL	Perl (MySQL, PostgreSQL, Oracle)
Roundup	Ka-Ping Yee, Richard Jones	MIT license (ZPL v 2.0 for the template system)	Python (SQLite, MySQL, PostgreSQL, Berkeley DB)
Simpleticket	Spur	GPL	Ruby on Rails (MySQL, PostgreSQL)
Teamwork	Open Lab	Proprietary, some parts LGPL	Java (all relational (uses Hibernate))
Trac	Edgewall Software	New BSD	Python (SQLite, PostgreSQL, MySQL)
OsTicket	OsTicket	GPL	PHP (MySQL)

Como ejemplo del uso de estas herramientras en el ambito de las administraciones públicas, os dejo la interesante entrada del blog de Victor Fernández, donde nos explica un caso práctico de mejora de procesos Itil usando OpenSource, en concreto, usando OTRS (Open source Ticket Request System). Podeis acceder a una demo online del proyecto en este link.

Igualmente, os dejo el link al portal de pruebas para que jugueis con otra de las herramientas que se incluye en las listas, en concreto MantisBT(con el usuario supervisor, password supervisor) Al igual que Eventum, esta desarrollada en PHP y es muy fácil de configurar. Se puede utilizar con MySql, PostgreSQL o SQL Server, siendo un producto bastante completo, aunque no permite la imputación de tiempos o la integración con clientes como Eventum. Podeis ampliar información sobre el producto aquí. Es el proyecto Sourceforge del mes de abril.

Portal de bugs del proyecto Pentaho utilizando Jira

Para terminar, nada mejor que ver un ejemplo práctico de uso de la herramienta Jira en el portal de tracking del proyecto Pentaho (en la imagen). Podeis acceder al portal en el siguiente link y realizar el seguimiento de los diferentes proyectos que estan realizando en Pentaho y como evolucionan los bugs y el desarrollo de mejoras, modificaciones o futuras versiones, a la vez que comprobais las funcionalidades de Jira.