Desarrollos Sitecore® en Latinoamérica

viernes, 19 de septiembre de 2014

Tal como contamos en nuestro sitio, una de las áreas de negocio a la que venimos abocándonos desde algunos años es el desarrollo de aplicaciones sobre la plataforma Sitecore®, lo que nos convirtió en uno de los pocos equipos de desarrollo en Sudamérica en dedicarse a la misma.

Dado que Sitecore® es, en su concepción más básica, una herramienta pensada para la construcción de sitios web corporativos e intranets, nuestro trabajo como desarrolladores consiste en la implementación de la plataforma, configuración de la arquitectura necesaria, integración de la misma con servicios externos y soporte sobre actualizaciones, entre otras tareas, de forma que los equipos del cliente puedan encargarse de la administración de los contenidos y estrategias de marketing.

Qué es Sitecore® 

Si bien Sitecore® nació como un software de gestión de contenidos, al día de hoy su punto más fuerte radica en las ventajas que ofrece al área de marketing, y se ha constituido como una de las más sólidas herramientas empresariales para la construcción de aplicaciones web, intranets y software de Automatización de Marketing. Por lo cual, y según su propia definición, Sitecore® es "una plataforma de gestión de la experiencia de usuarios".

Con más de 10 años de posicionamiento en el mercado (su primera versión apareció por 2001), la empresa multinacional danesa que lo creó cuenta hoy con oficinas en lugares como Australia, Suecia, Canadá, Alemania, , Reino Unido, y Estados Unidos entre otros.

Los usos de Sitecore® son variados pero siempre enfocados a la administración de la experiencia de usuarios y funcionalidades de marketing. Con el paso de los años ha ido unificando la actividad de múltiples canales abarcando desde el armado de campañas, seguimiento de la actividad de los usuarios (con la incorporación de los web performance for marketers, por ejemplo) hasta mediciones de performance.

Novedades de la plataforma

En la reciente presentación de los features de la próxima versión "Sitecore® 8 - #SYMNA" en Las Vegas (Sitecore® Symposium 2014) se destacó que el objetivo principal de los cambios incorporados en la herramienta está puesto en el "customer engagement".

En dicho simposio se mostró a Sitecore® 8 como una plataforma con la capacidad de implementar analíticas como base de una "máquina de marketing" personalizada, integrada con múltiples canales. Se agrega la posibilidad de trabajar con segmentación dinámica de audiencias y con testing automatizado que permite optimizar las estrategias de captación de clientes.

Además de una interfaz de usuario más simplificada, la nueva versión avanza sobre una tecnología de marketing altamente focalizada en el target de los clientes a los que apunte cada compañía que la implemente.

En cuanto a la "parte de atrás" de la herramienta, podemos decir que está desarrollada en .NET y permite integración con una infinidad de servicios y plataformas de diverso tipo.

Dada esta característica, otro de los anuncios importantes es que están trabajando en forma conjunta con Microsoft® con la finalidad de dotar a la plataforma de algoritmos de "machine learning" que agregan un valor importantísimo a uno de los objetivos de la herramienta que es el de lograr "enviar el aviso específico a la persona adecuada en el momento justo", es decir, captar nuevos clientes y lograr retenerlos fieles al producto que cada empresa ofrece.

Artículos de interés:

Sitecore Documentation
Sitecore, gestor de contenidos
Technical Debt
Sitecore simplifies marketing with newest upgrade, Sitecore 8
Sitecore simplifica el marketing con su última versión, Sitecore 8
Sitecore Experience Platform


Leer más...

Trabajo en equipos distribuidos

miércoles, 23 de julio de 2014

Nuestra experiencia en trabajar en equipos distribuidos en distintos lugares físicos fue dándose gradualmente:

  1. pasamos de trabajar en dos oficinas separadas - por una cuestión de calidad de vida de algunas de las personas que tenían mucho tiempo de viaje -,
  2. a trabajar para clientes en el exterior - lo que implicó cambiar nuevamente algunos hábitos laborales -,
  3. hasta ser parte de un grupo de equipos de desarrollo ubicados en puntos distantes del planeta.

En este camino que llevamos recorrido hemos tenido que aprender a adaptarnos y compartir experiencias para poder llevar adelante los proyectos manteniendo el uso de metodologías ágiles.

Siguiendo consejos de quienes ya habían pasado por estos menesteres y aportando nuestro propio conocimiento y sentido común, resumimos en este artículo algunos de los puntos que nos parecen más importantes para considerar en estos casos.

Algunos puntos relevantes

Si bien en las metodologías ágiles la comunicación tiene un rol fundamental, encontramos por allí quienes aconsejan también darle tanta o más importancia a la estructuración del proyecto y la gente que va a formar parte de los distintos equipos. Ese trabajo previo debe llevar a que cada miembro tenga claro el contexto, los objetivos y los roles. En nuestra experiencia esto resultó fundamental.

Considerar algunas características culturales y tratar de unificar criterios de colaboración no sólo entre equipos sino también dentro de cada uno de ellos. Algunos de esos criterios son:
  • Definir metas estándar de distinto tipo (por ejemplo, respecto de la calidad del software, armado de prototipos, criterios de aceptación o del significado de "done", etc.)
  • Definir la frecuencia de control para cada meta, para evitar desvíos o minimizarlos
  • Definir cuándo y cómo se van a realizar las Stand up meetings, quiénes van a estar presentes y cómo se van a cargar las horas insumidas por cada equipo 
  • Definir qué herramientas se van a usar, cómo y en qué casos. Es importante entender que no existe una única herramienta que sirva para todos los fines. Si bien es necesario tratar de minimizar la cantidad de éstas para evitar duplicación de trabajo, tampoco tenemos que forzar que una sola h pueda cubrir todas las necesidades. En este punto puede servir detenerse a pensar:
    • qué necesitamos
    • qué herramientas ya tenemos (o usan los distintos equipos para cubrir esas necesidades)
    • qué herramientas nuevas necesitamos incorporar, qué uso se le va a dar y verificar que no entre en conflicto con alguna de las pre-existentes
  • Invertir en el entrenamiento de todos los equipos para el uso de herramientas, estándares en la codificación, metodologías, etc. permitirá ahorrar tiempo y errores a lo largo del proceso. Y puede ser un buen terreno de intercambio de conocimientos entre los equipos

Otros aspectos a tener en cuenta

Para lograr los objetivos cuando los equipos se encuentran físicamente distribuidos y deben ensamblarse es necesario contar con un rol de alguien que sirva como guía, gerente, scrum master, coordinador o la etiqueta que quiera ponérsele para que se encargue de aunar los criterios de trabajo, la relación con el cliente y la comunicación entre teams. Y por sobre todas las cosas debe asegurarse que los equipos puedan reaccionar rápidamente a los cambios que se presenten.

En otro aspecto, en metodologías ágiles son bienvenidas las habilidades diversas dentro del equipo. Al trabajar con equipos de diferentes culturas y niveles de conocimiento hay que ser muy cuidadosos y optimizar el uso de las distintas capacidades dentro de cada uno de  los equipos y entre los equipos dado que muchas veces pueden darse colisiones. El rol del "administrador" en estos casos es fundamental.


Por supuesto, uno de los aspectos importantes en esta forma de trabajo está referido a la creación y mantenimiento de canales de comunicación que permitan suplantar de la mejor manera los beneficios de la comunicación "presencial" o cara a cara. Pero además es necesario equilibrar la comunicación escrita con la oral para evitar el uso exagerado de una sola de las dos.

En el mismo sentido anterior, el uso de las Historias de Usuario puede tener un apartado especial. Cuando los equipos son tan diversos es posible que la adminstración de las historias requiera un detalle más exhaustivo de lo que un equipo independiente está acostumbrado a usar.
En nuestra experiencia hemos necesitado que las historias o estén complementadas con otra forma de documentación o que sea necesario el uso de una herramienta un poco diferente a la tradicional pizarra para poder llevarlas adelante. Sobre todo, porque hay que tener en cuenta que dados los distintos husos horarios y la integración con tareas hechas por otros equipos, las historias deben considerarse como lugar de conversación y de tracking de necesidades o consultas con otros miembros.
En este sentido una herramienta que nos ha sido muy útil es Assembla.

Respecto de la integración de código, Github es altamente recomendable (How Github works)
Y por supuesto Skype, GoogleDocs y Join.me son también de gran ayuda.

Más artículos de interés:

Distributed Agile: 8 ways to get more from your distributed teams
3 Surprising Reasons Distributed Teams Work Better
Fully Distributed Teams: are they viable?
The Secret Ingredients of a Successful Distributed Team

De nuestro blog:

Trabajo distribuido
Herramientas para trabajo distribuido
Reuniones diarias


(Fuentes de las imágenes:
http://2.bp.blogspot.com/-jUVasDg67s8/Ui6s1sF-MeI/AAAAAAAABho/S7Kv8NZ_yuY/s200/distributed-teams.jpg
http://qablog.practitest.com/wp-content/uploads/2012/07/ID-10064353.jpg) 


        







Leer más...

Documentación ágil

miércoles, 7 de mayo de 2014

En cuántos proyectos nos ha pasado que no encontramos la forma ideal de crear y mantener una documentación que resulte realmente útil?

Cuántas veces tuvimos que recurrir a una documentación para ver "cómo se había definido algo" o "cómo se había resuelto" y no lo encontramos o lo encontramos desactualizado?

(fuente www.freevector.com)
Particularmente me siento muy frustrada cuando pasan estas cosas porque me doy cuenta de lo difícil que nos resulta determinar en qué medida documentar y cómo sostener esto en el tiempo.

En este artículo de Jens Schauber encontré algunos comentarios y tips que me parecen muy útiles para ordenar la idea de la práctica de la documentación durante los proyectos.

Comparto un resumen de lo que dice el autor:

El concepto que me pareció más interesante es la visión que nos da sobre la documentación y que expresa al final de su artículo:
La documentación no debe ser un objetivo por sí misma. Es una herramienta para el entendimiento común y sólo debería ser creada cuando realmente aporta valor a nuestro trabajo. No debemos confundir la herramienta con el propósito que debe tener.
  • Cuando creamos documentación es necesario clarificar el propósito, debemos preguntarnos qué problema esperamos resolver con eso, qué problema trata de resolver esa documentación y resolver ese problema en la misma documentación.
  • Y no sólo eso, cuando se crea una documentación hay que pensar y tener claro desde el principio cómo hacer para mantenerla actualizada. Algo que sugiere Schauber es incluir esa tarea como parte de la definición de "Done! o agendar tiempo a intervalos regulares para dedicar a la misma. 
  • Debemos elegir formas de documentar que sean fáciles de matener: una wiki puede ser una buena idea, documentar en el código puede ser aún mejor.
  • Y algo para tener en claro según el autor: 
"lo que decididamente no sirve es tener largos procesos de aprobación de la documentación, que hará que nadie quiera actualizarlos a menos que sea obligado a hacerlo ...."

Territorios y mapas

Creo que a partir de lo anterior podemos entender mejor algunos de los tips que nos da, haciendo una analogía entre la documentación y los mapas.

Según el autor, una de las utilidades de la documentación es la de servir como guía a los nuevos. Para quienes llevan tiempo trabajando en un proyecto es fácil identificar cuáles son los puntos más importantes, riesgosos o complejos. Alguien nuevo seguramente se encuentre perdido en un territorio desconocido. Tener un "mapa" de ese terreno ayudará a que el nuevo integrante pueda ubicarse y detectar sin mucho esfuerzo los puntos estratégicos, aún cuando ese mapa no esté del todo actualizado.

Por otro lado, aún cuando se conozca bien el territorio, no siempre es fácil determinar la mejor forma de moverse entre dos puntos. Un mapa puede ayudar a darnos una visión más clara y rápida de ese problema.

A veces podemos encontrar en ese territorio "features" que no se sabe muy bien para qué estan.  Poner anotaciones en el mapa ayuda a detectar fácilmente si esos features deben quedar (y por qué) o simplemente son basura que espera ser removida.

Por último, Schauber nos dice que la documentación debe ser usada,
la documentación que no se usa es inútil

Usar la documentación sirve para notar los problemas y, a partir de eso, abordarlos.

Además, la documentación debe ser fácilmente accesible y comunicada al resto: desde imprimir y pegar en las paredes de la oficina las actualizaciones o definiciones más importantes, hasta poner un link en algún lugar al que los involucrados tengan acceso (servers, intranets, etc.)  o enviar mail, usar RSS feeds, etc., debemos buscar la forma de hacer llegar a todos las notificaciones de cambio si queremos que realmente tenga sentido el tiempo que utilizamos en mantener una documentación medianamente actualizada.


Artículo de Jens Schauber (en inglés): The purpose of documentation



        










Leer más...

Cuando la solución es el problema (cómo prevenir la sobre-ingeniería)

lunes, 5 de mayo de 2014

Hace pocos días leí un artículo que me pareció muy útil y cierto sobre algo que podemos reconocer fácilmente como "pecado cometido" en nuestros propios proyectos: lo difícil que resulta determinar cuándo llegamos a un punto en que estamos haciendo sobre-ingeniería o agregando features que no siempre son imprescindibles.

La visión que tiene el autor - Aneesh Karven - y los consejos que da para reconocer y afrontar este problema son muy directos y pueden ser de gran ayuda para empezar a observarnos internamente.
Les comparto aquí un resumen en español del artículo (original en inglés):

Un primer punto a destacar de la nota es que el autor entiende que el problema de muchos profesionales del software es que tienen un "exceso de confianza en la herramienta que usan y les es familiar" (por eso lo relaciona con la Ley del Martillo) lo que hace que piensen que aquello que puede ser la "solución al problema" en realidad resulta ser una exacerbación del problema. Esto hace que se generen features y fixes que dañan más que lo tienen que curar debido a las consecuencias inesperedas que suelen provocarse.

Otra de las cosas que me pareció interesante es lo que Karven sugiere como solución a estos casos de sobre-ingeniería en los que se suele caer. Como punto de partida nos dice que es fundamental un cambio de mentalidad.


Y a partir de este cambio sugiere implementar estos 2 consejos prácticos:

Preguntarse 3 cosas

Cuestionarse varias cosas antes de escribir una sola línea de código. El autor recomienda tener en cuenta estas 3 preguntas de Baumer and Silverman (en su libro When the implication is not to Design)

  1. Podría la tecnología ser reemplazada por un enfoque igualmente viable pero no tecnológico?
  2. Una intervención tecnológica puede resultar en más problemas o daños que los que podría provocar la situación actual ?
  3. Es la tecnología (en este caso) un sustituto "menor" de la solución real a aplicar?

Cambiar la cultura de la compañía 

Según Karven los siguientes valores culturales pueden ser útiles para prevenir la expansión descontrolada de features:

  • Valorar el "no hacer algunas cosas" (o "no hacer cosas"):  aquí sugiere instalar conversaciones dentro de la compañía sobre "MENOS ES MÁS". Considerar qué features se pueden eliminar para mejorar el producto Esta frase que Karven cita en su artículo me pareció muy apropiada: "La perfección es finalmente alcanzada no cuando ya no hay más para agregar sino cuando ya no hay más para sacar." (Antoine de Saint Exupéry)
  • Documentar los caminos NO explorados: para superar la mencionada Ley del Martillo nos sugiere documentar lo que NO SE ESTÁ HACIENDO y por qué no lo hacemos, o sea, tener bien visibles las soluciones NO TOMADAS.


Continuar creciendo

A lo que se refiere en este caso es a lograr un cambio de perspectiva. Practicar esto es "practicar la humildad y precisión". El software, la gente que lo usa y las situaciones que crea pueden ser más complejas de lo que podemos imaginar. Debemos esperar sorpresas y resultados no lineales de cada intervención."
Esta otra frase dentro del artículo expresa muy bien lo que nos quiere decir "mirar en todos los rincones antes de empezar a intervenir.".

Personalmente encontré en este artículo muchos puntos clave con los que podemos identificarnos quienes trabajamos en este ámbito desde hace tiempo y creo que la mayor dificultad está en poder entender claramente que un cambio de rumbo en estas prácticas (a veces no vistas como un problema) pueden mejorar muchísimo el resultado de nuestro trabajo. Es muy común pensar que cuanto más agreguemos y tengamos contemplado dentro de nuestro código, mejor va a ser para el cliente. Pero me pareció muy clara la visión totalmente opuesta que Karven expone sobre esta creencia.

Como dice mi maestro de pintura: "una obra no se termina, simplemente se abandona", lo difícil es tener claro cuál el punto justo para hacerlo.


Este es el artículo original en inglés When the solution is the problem - How to prevent over-engineering & useless features

En el mismo sentido de este artículo, este otro artículo del autor puede ser de utiilidad How to cut features and enjoy it


        


Leer más...

Responsive y Adaptive Design

jueves, 27 de febrero de 2014

Cuando se habla de Responsive y Adaptive web design suelen tomarse como lo mismo.

Pero buceando en la web podemos encontrar 3 visiones diferentes sobre estos términos: los que piensan que son dos cosas muy distintas que no tienen puntos en común ("tengo que elegir entre uno u otro"), los que sostienen que el Responsive Web Design (RWD) es un subconjunto del Adaptive Web Design (AWD) y otros (tal vez los menos?) que consideran que en realidad son dos conceptos que se complementan.

En una definición general podemos encontrar que se habla de Responsive Design cuando se piensa un sitio donde el contenido pueda ser reacomodado según el dispositivo donde se visualiza (desktop, tablet, celular, etc.) enviando siempre la misma información.

Muy genéricamente también encontramos que el diseño Adaptive se define como el diseño pensado en base a los dispositivos donde se visualizará una aplicación, diseñando una versión para cada uno de ellos, haciendo que sea el servidor el que detecte qué dispositivo lo está invocando y enviando el diseño adecuado para el mismo.

Tal como mencionamos, algunas visiones consideran al RWD como parte del AWD, como un subconjunto del mismo. Muchas puntualizan que el Resposive design tiene como objetivo el layout únicamente.

Si bien los dos conceptos tienen en común que se focalizan en permitir que los sitios puedan ser vistos en dispositivos de distintos tamaños o resoluciones buscando dar una mejor experiencia a los usuarios, Adaptive design es algo más amplio e íntimamente relacionado con la mejora progresiva, cosa de la que el RWD tampoco está ajeno. Es por ello que hay quienes consideran que ambos conceptos se complementan. Personalmente me inclino más por esta visión.

El AWD es un concepto más abarcativo y, según la definición de su creador Aaron Gustafson, utiliza mucho de los componentes de la mejora progresiva (PE - Progressive Enhancement) que se focaliza en el uso de los métodos de diseño necesarios que apunten al usuario y no a los browsers, donde el RWD debería ser una parte, pero siempre teniendo en cuenta  que el AWD es un "acercamiento más holístico del diseño web".

Desde el punto de vista de los usuarios de los sitios que desarrollamos, poco sabrán ellos sobre qué métodos fueron usados para crearlos. Sólo buscarán poder navegarlos de la forma más simple, rápida y clara desde cualquier "aparato" que se los permita y si no, simplemente los abandonarán. Es por eso que las herramientas y métodos que usemos en su creación deben llevarnos siempre a satisfacer de la mejor forma posible las necesidades de dichos usuarios.

Tomar lo mejor que cada uno nos brinda para lograr este objetivo puede ser una buena idea ...

    


Leer más...

Uso de texto en lugar de imágenes (icon fonts)

lunes, 24 de febrero de 2014

Desde hace ya un par de años una de las prácticas instaladas en desarrollos web es el uso de fuentes tipográficas en lugar de íconos o pequeñas imágenes o incluso sprites css. O sea, se manejan los íconos como textos lo que permite cambiar sus propiedades usando CSS.




El uso de estos “icon fonts” (icon web fonts) presenta muchas ventajas respecto de otras técnicas de inserción de imágenes dado que disminuyen la carga del servidor y las peticiones HTTP, no son tan complejos de implementar como los sprites, son adaptables a distintos dispositivos (los íconos pueden verse pixelados al cambiar de tamaño), se puede cambiar fácilmente sus propiedades, entre otras.

Varios son los sitios donde podemos encontrar conjuntos de font-icons – gratuitos y pagos - y abarcan una enorme variedad de temas. Algunas de estas colecciones hemos aplicado en nuestro web site.

Recomendamos aquí muy buenos artículos donde pueden leer más detalles sobre su implementación y sitios desde donde descargar colecciones:

CSS Tricks

(imagen: htttp://commons.wikimedia.org/wiki/File:Early_writing_tablet_recording_the_allocation_of_beer.jpg)

    
Leer más...

Probando Pentaho VI: esquema de un cubo con Mondrian

viernes, 14 de febrero de 2014

En un artículo anterior vimos que construir un esquema Mondrian adecuado es la base para cualquier análisis y visualización.
Comparto ahora algunas pruebas realizadas con Mondrian. Utilicé  la documentación provista por Pentaho.

Esquema Mondrian

Un esquema define una base de datos multi dimensional. Contiene un modelo lógico. Este modelo a su vez debe mapear a un modelo físico.
  • El modelo lógico consiste en las estructuras usadas para escribir consultas en lenguaje MDX. Esta formado por cubos, jerarquías, niveles y miembros.
  • El modelo físico  son las tablas de datos presentados previamente en  el modelo lógico. 
Los esquemas Mondrian son archivos de tipo xml. Se pueden editar manualmente, o bien por medio de la herramienta Workbench provista por Pentaho.

Workbench

Mondrian Schema Workbench es una aplicación que permite crear visualmente y testear esquemas Mondrian de cubos OLAP.

Creación del esquema de un cubo usando Workbench

1. Instalar Mondrian, que se puede bajar desde Source Forge
2. Descomprimir en el directorio donde se instalo el server de Pentaho.



3. Incluir el driver JDBC en el directorio 'Drivers': schema-workbench/drivers
4. Con el server de Pentaho activo, iniciar Workbench, (schema-workbench/workbench.bat ) obteniendo una pantalla del tipo



5. Conectarse a la base de datos, desde la opción 'options' del menú principal. Los parámetros para crear la conexión son los mismos que en el caso de la consola de usuario de Pentaho.



6. Este es un ejemplo de esquema de un cubo. Consulta la base en SQL 'AdventureWorksDW'. Tomando como tabla de 'hechos' o fact table FactInternetSales. La medida utilizada es 'SalesAmount'. Las dimensiones, dos básicas, son el tiempo (DimTime) y Región (tabla DimSalesTerritory).
Crear o editar los elementos en el esquema. Workbench valida los cambios contra las tablas del cubo y los nombres de las columnas.

En este caso, construimos la dimensión 'Region' contra la tabla 'DimSalesTerritory'.

 7. Para ver el código XML que subyace detrás del esquema, seleccionar View/XML. Muestra el XML del elemento actual, pero no se puede editar este archivo directamente.

<Dimension type="StandardDimension" visible="true" foreignKey="SalesTerritoryKey" highCardinality="false" name="Region">
    <Hierarchy name="Region" visible="true" hasAll="true" allMemberName="TODOS" primaryKey="SalesTerritoryKey">
        <Table name="DimSalesTerritory" schema="dbo">
        </Table>
        <Level name="Region" visible="true" column="SalesTerritoryRegion" nameColumn="SalesTerritoryRegion" type="String" internalType="String" uniqueMembers="true" levelType="Regular" hideMemberIf="Never" caption="Region" captionColumn="SalesTerritoryRegion">
        </Level>
    </Hierarchy>
</Dimension> 


8. Probar que la  estructura sea correcta, para esto abrir el  editor de MDX y conectarse. Si se hay algún error o campo mal indicado no se conecta y da error.
En ese caso muestra los resultados de la consulta MDX básica.


Resultaron de utilidad los artículos del blog Adventures with Open Source BI

    
Leer más...

Probando Pentaho V: instalando Pentaho 5 - Saiku Analytics

jueves, 16 de enero de 2014

La nueva versión de Pentaho BI-Server 5.0 está disponible.
Hay varias novedades, entre ellas una nueva interfase, mucho más moderna y amigable que la anterior
Por otro lado, la consola de usuario (Pentaho User Console) y la consola de adminstración están integradas, con lo cual no es necesario ahora configurar un server extra.
Se ha mejorado la instalación de plugins por medio de MarketPlace.

Instalamos entonces la nueva versión de Pentaho. El cambio que más nos gustó fue la presentación más moderna y austera, con una paleta de colores muy amigable. También el acceso fácil a todos los elementos.
Este es el detalle de los pasos básicos que seguimos para tener Pentaho 5 andando:
  1. Instalación.
  2. Conexiones a las bases de datos.
  3. Creación de Data Sources y consultas MDX.
  4. Presentaciones y gráficos.

-1-  Instalación

La instalación fue simple, bajamos los archivos desde Pentaho Community  (biserver-ce-5.0.1-stable)

-2- Conexiones

Las conexiones: basta instalar el driver adecuado en los directorios y crear la conexión en sí
    • Drivers: driver para acceso a SQL. jtds-1.3.0.jar en los directorios:
 bi-server/data/lib
 bi-server/tomcat/lib
    • Creación de una conexión. Desde la pantalla de Pentaho:
File /New/DataSource
SQL query, pantalla de selección de conexiones, agregar una nueva:














-3- Data Sources y consultas MDX.

Una diferencia importante en esta nueva versión de Pentaho es la posibilidad de configurar data sources. Se puede crear un data source a partir del esquema de un cubo creado con Mondrian. Basta tener el xml asociado al cubo. No es necesario publicarlo como en versiones anteriores de Pentaho.

Manage DataSources/ DataSource/ New Analysis

Seleccionar el archivo .xml correspondiente al esquema Mondrian generado por Workbench, y seleccionar el data source correcto.

El data source importado, cuya base es un cubo, se puede ver por medio de Jpivot y Saiku analytics. La creación de las consultas y gráficos es bastante intuitiva. 
JPivot:  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.
Create New/ JPivot View permite seleccionar entre los cubos creados. En este caso, seleccionamos un cubo construido a partir de ventas de internet. Con solo dos dimensiones, región y tiempo. La consulta MDX relacionada es

select NON EMPTY [Region].[Region].Members ON COLUMNS,
  NON EMPTY {Hierarchize({[Time].[Years].Members})} ON ROWS
from [InternetSalesRegionTime]
(de la base AdventureWorksDW)



-4- Visualizaciones

Para probar Saiku Analytics, fue necesario descargar el plug-in por medio de la opción 'MarketPlace' desde la consola de usuario de Pentaho.

Create New/ New Saiku Analytics permite armar consultas  y generar gráficos. 
Estas son las consultas al mismo cubo que abrí con JPivot y gráficos generados. Tomé para el ejemplo un caso sencillo, pero muy ilustrativo.

Consulta Ventas por Región y Tiempo


Consulta Ventas por Región y Tiempo
Ventas por región por año

Gráfico líneas ventas por región


Región en las columnas y años para las filas


Mismo gráfico detalle por mes.


A mi entender es clave partir de un esquema Mondrian adecuado. En un próximo artículo compartiré un par de consejos para crearlos.


    
Leer más...