El Rincon del BI

Descubriendo el Business Intelligence…

Archive for 27 enero 2010

14.4. Gestión de usuarios en Microstrategy 9. Configuración del portal Web.

Posted by Roberto Espinosa en 27 enero 2010


La gestión de usuarios se realiza en Microstrategy a nivel de proyecto, de forma que cada uno de ellos tiene sus propios usuarios y grupos de autorizaciones.

Antes de empezar, os recomiendo visualizar el video realizado por Microstrategy sobre la gestión de usuarios.

La gestión de usuarios se realiza desde la herramienta Desktop, en la sección de Administración. En Microstrategy se trabaja basicamente con tres conceptos: Roles de Seguridad,Usuarios y Grupos.

Gestión de usuarios en Microstrategy 9

Disponemos de un conjunto de privilegios, predefinidos y clasificados por areas temáticas, que son los siguientes:

  • Web Reporter.
  • Web Analyst.
  • Web Professional.
  • Opcion Web MMT.
  • Privilegios comunes.
  • Office.
  • Mobile.
  • Microstrategy Distribution Services.
  • Opción de origen múltiple.
  • Desktop analyst.
  • Desktop designer.
  • Architect.
  • Object Manager.
  • Integrity Manager.
  • Administración.

Cada conjunto de privilegios dispone de una lista de posibles tareas a realizar que podemos habilitar o dejar desmarcadas, de forma que se dispondra de autorizacion para dicha actividad en el caso de que el usuario o grupo tenga marcado el correspondiente flag (o no la tendra en el caso de que no este seleccionado). Con la selección de las diferentes tareas autorizadas en los diferentes grupos de privilegios existentes en Microstrategy definimos el concepto de Rol (grupo de autorizaciones). Microstrategy dispone de un conjunto de roles predefinidos que podemos utilizar en nuestros usuarios o grupos.

Editor de Roles de Seguridad

Una vez tenemos definido un rol, podemos desde el mismo editor indicar los  usuarios o grupos que lo poseen. Todas las autorizaciones indicadas en el rol pasaran automaticamente a formar parte del usuario o grupo. De la misma manera, cuando estamos creando un usuario o un grupo, podemos indicar, de cada privilegio, que tareas se autorizan o no al usuario (tal y como vemos en la imagen inferior). En el mismo editor de usuario o grupo podremos ver la autorizaciones que son heredadas por pertenecer a una entidad superior (el usuario pertenece a un grupo, por ejemplo, que ya tiene definidas sus propias autorizaciones, que el usuario también hereda o el usuario pertenece a un rol y también hereda todas las propiedades de este).

Mantenimiento de usuarios

Ademas de las autorizaciones, en el mantenimiento de usuarios se pueden indicar otros aspectos, como son:

  • Gestión de contraseñas: criterios para vencimiento de contraseña, frecuencia de vencimiento, bloqueo de una cuenta.
  • Filtros de seguridad: es un filtro de seguridad que se aplica a todas las consultas que ejecuta un usuario. Nos puede servir para limitar el acceso a los usuarios a determinados valores de atritubos (por ejemplo, creamos un filtro de seguridad para las diferentes regiones y los asignamos a los delegados de cada zona. De esta forma, solo podrán ver la información de su area, y no podrán ver nada del resto de zonas).
  • Grupos: grupos a los que pertence un usuario. Hereda todas las propiedades del grupo (autorizaciones y filtros de seguridad).
  • Verificación de identidad: si se va a verificar la c uenta cuentra un usuario de windows, de base de datos, servidor LDAP, etc.
  • Microstrategy Distribution Services: datos para la gestión de la distribución de informes (por ejemplo, indicar una cuenta de correo para el usuario, para de esta forma poder enviarle los informes a los que este suscrito).

A nivel de mantenimiento de grupos, disponemos de los mismos elementos, excepto la gestión de contraseñas, verificación de identidad y la configuración de distribución de servicios (no tienen sentido en este ámbito).

Privilegios a nivel de objetos.

Finalmente, Microstrategy nos permite establecer permisos sobre los diferentes objetos (Atributos, indicadores, filtros, etc) a nivel de si este se puede ver, modificar o se tiene control total sobre el. Esto nos puede valer para que determinados objetos no sean modificados por nadie que no sea la persona encargada de su definición o mantenimiento.

Privilegios a nivel de objetos

Con toda la configuración de usuarios, privilegios y permisos, podremos montar (sobre todo pensando en entornos complejos con muchos usuarios), el esquema de autorizaciones apropiado para que cada usuario, según su rol dentro del sistema de BI, solo tenga acceso a las tareas y objetos necesarios para el desarrollo de su trabajo.

Configuración del Portal Web

Antes de continuar, os recomiendo un vistazo al video elaborado por Microstrategy referente a la configuración de Portal Web.

Una vez concluida la instalación del producto, el proceso habrá creado todos los elementos necesarios en el servidor de Internet Information Services (Servidor Web) para poder utilizar el portal Web. Igualmente, en el proceso de configuración visto en anteriores entradas del blog, habremos dejado configurado el Intelligence Server según los parámetros oportunos. El Intelligence server nos llevara a todos los origenes de proyecto (contenedor de proyectos), que tengamos definidos del tipo “3 Niveles” (que se gestionan a través de él). Todos los proyectos definidos en un origen de proyecto de este tipo estarán disponibles en la interfaz Web (en caso contrario, solo estarán disponibles a través de la herramienta Desktop).

Solo nos quedará el paso final de conectar el Intelligence Server con el Web Server, tarea que realizaremos desde las paginas de administración Web:

Conexion del servidor Web con el Intelligent Server

El proceso es tan sencillo como indicar el nombre del servidor donde esta el Intelligence Server, y de esta forma establecemos el vínculo entre los dos elementos.

Configuracion parametros Web Server

Ademas podremos establecer otro tipo de propiedades, como la forma de autenticación de los usuarios, menú inicial, ordenación de los proyecto disponibles, etc. Una vez realizada la configuración, ya tenemos disponible también el entorno Web para trabajar con los diferentes elementos de Microstrategy (con el aspecto que vemos en la imagen siguiente):

Entorno Web de Microstrategy

El entorno Web por defecto es el que aparece en la imagen. Se podrán personalizar muchisimos aspectos de el en las preferencias de usuario, para hacerlo mas ajustado a las necesidades de cada uno.

Conclusiones

Hemos concluido en esta entrada del blog la serie de artículos que hablan de como configurar los elementos base de nuestro sistema BI utilizando Microstrategy. Antes de proceder a entrar en profundidad a preparar el sistema de reporting para los usuarios con la elaboración de los informes mas comunes, en la próxima entrada del blog detallaremos la configuración de todos los elementos de nuestro proyecto. Veremos a fondo las jerarquías de sistema y de usuario creadas, los indicadores de análisis, los filtros, las selecciones dinámicas y las transformaciones.

Posted in Business Intelligence, Microstrategy | 2 Comments »

14.3. Diseño de Indicadores, Filtros y Selecciones Dinámicas en Microstrategy 9.

Posted by Roberto Espinosa en 26 enero 2010


Antes de continuar con el diseño de indicadores, filtros y selecciones dinámicas, y ver la forma de preparar plantillas para nuestros informes, vamos a ver un poco mas en detalle elementos que tienen que ver con los atributos de las dimensiones (que vimos como se configuraban en la entrada anterior del blog), y que nos serán utiles en el desarrollo del proyecto.

Tipos de jerarquias.

Las jerarquias nos permiten organizar y navegar por los atributos. En Microstrategy, disponemos de dos tipos de jerarquías:

System hierarchy: Es la jerarquía del sistema, la que incluye las relaciones definidas entre los atributos del proyecto. Esta jerarquía no es necesario definirla, sino que se genera automaticamente en la herramienta Desktop al crear el proyecto (fue la que construimos utilizando el Architect).

Es la jerarquia por defecto, y contiene todos los atributos del proyecto, formando parte de la definición del esquema. Al terminar la creación del proyecto, es la única jerarquia que existe. La jerarquia de sistema no se edita, pero se actualiza cada vez que añadimos o quitamos atributos hijo o padre utilizando el editor de atributos o el architect, o añadimos nuevos atributos al proyecto.

Jerarquia del Sistema del proyecto EnoBI

La jerarquia del sistema es util para determinar las relaciones existentes entre todos los objetos del proyecto (podemos navegar por ella viendo los valores de los atributos y como estan relacionados unos con otros). Los atributos definidos en la jerarquia del sistema no necesitan estan definidos en una jerarquia de usuario. Los atributos de la jerarquia de sistema que no utilizemos en las jerarquias de usuario seguiran estando disponibles para ser usados en los informes, filtros o consolidaciones.

User hierarchy: las jerarquias de usuario son grupos de atributos y las relaciones entre ellos, juntados de manera que tenga significado en el contexto de análisis. No necesariamente tendrá que seguir  el modelo de datos lógico. Ademas, a diferencia de la jerarquia de sistema, nos permite definir limitaciones al numero de valores visualizados, establecer filtros sobre los valores a visualizar o definir un punto de entrada, que sera el atributo donde nos posicionaremos al utilizar la jerarquia (por ejemplo, al navegar o al realizar filtrado).

Editor de jerarquias

Por ejemplo, podremos crear una jerarquia que incluya los atributos Año, Trimestre, Mes y Dia. Cuando navegemos por los atributos con el Data Explorer, al hacer doble click en el año nos apareceran los trimestres, a continuación los meses y asi sucesivamente.

En nuestro proyecto vamos a crear todas las jerarquías necesarias para permitir la navegación por los diferentes atributos de las dimensiones.

Las jerarquias de usuario son las que tendremos disponibles cuando navegemos por los datos en los informes y documentos de Microstrategy, y nos permitiran disponer de la funcionalidad Drill Up y Drill Down entre los atributos que definamos dentro de ella. Por tanto, son un elemento indispensable en la configuración del sistema, pues son el punto de partida para sacarle todo el partido a la navegación dimensional. Por ejemplo, si en el ejemplo anterior estamos visualizando el atributo Trimestre, podremos navegar hacia arriba (drill up) por la jerarquia hasta el año, o navegar hacia abajo (drill down) hasta el mes, o cambiarnos a otra jeranquia y cambiar la navegación.

Son el unico tipo de jerarquia que se puede definir por el usuario y se podran crear todas las jerarquias que hagan falta dentro de un proyecto. Habra que pensar todas las jerarquias necesarias para que cubran todas las necesidades dentro del modelo de negocio de la compañia y del esquema del data warehouse.

Transformaciones

Son objetos del esquema que podemos definir utilizando los atributos. Se utilizan para ejecutar análisis de series de tiempo como periodo a fecha, periodo actual contra periodo anterior o análisis de periodos cambiantes. Las transformaciones las definimos sobre los atributos (como por ejemplo, en la imagen, en la que estamos utilizando una fecha, a la que restamos 14 dias). Esto nos configura un valor variable, que dependerá del valor del atributo con el que esta relacionado, y que luego utilizaremos al crear los indicadores.

Editor de transformaciones

Por ejemplo, tendremos un indicador llamado Ingresos Netos (calculado a partir del hecho ingresos netos), que nos mostrara las ventas netas actuales en el periodo que estemos analizando. Si creamos otro indicador llamado Ingresos Netos de hace 14 dias (y le asociamos la transformación definida en la imagen), cuando utilizemos el indicador en un informe nos mostrará los ingresos de 14 dias antes. Las transformaciones son un elemento muy potente y que nos permitira realizar de una forma sencilla el análisis de las series temporales.

Todos los objetos visto hasta ahora, los atributos, los hechos, las jerarquias de usuario y las transformaciones forman parte de los objetos de Esquema, y son el punto de partida para la construcción y el desarrollo de nuestro sistema de Business Intellingence. Veamos que elementos podemos construir con ellos:

Diseño de Indicadores, Filtros y Selecciones.

Antes de continuar, os recomiendo visualizar el video elaborado por Microstrategy donde se habla del diseño de indicadores, filtros y selecciones.

Indicadores

Los indicadores son objetos de MicroStrategy que representan medidas de negocio e indicadores de rendimiento clave. Desde un punto de vista práctico, los indicadores son los cálculos realizados en los datos almacenados en la base de datos y cuyos resultados se muestran en un informe. Son parecidos a las fórmulas de un programa de hoja de cálculo. No sería una exageración afirmar que el centro de prácticamente todos los informes son sus indicadores. La mayoría de las decisiones que se toman acerca del resto objetos que se deben incluir en un informe dependen de los indicadores que se utilicen en el informe.

En particular, los indicadores definen los cálculos analíticos que se realizan con los datos almacenados en el origen de datos. Un indicador se compone de hechos del origen de datos y de operaciones matemáticas que se van a realizar en tales hechos para, de este modo, poder efectuar un análisis de negocio con sentido en los resultados.

Editor de Indicadores

En los indicadores se pueden definir varias cosas, aunque el elemento fundamental es la formula que determina su valor.Una fórmula de indicador puede estar formada por hechos del origen de datos (como en el ejemplo anterior), atributos empresariales del origen de datos u otros indicadores que ya se hayan creado. Los siguientes ejemplos de indicadores muestran estas opciones distintas de fórmulas:

  • Indicador formado por hechos: (Sum(Ingresos) -Sum(Coste)). La fórmula de este indicador suma todos los beneficios registrados en el origen de datos, suma todos los costes registrados en el origen de datos y, a continuación, resta el total de costes del total de beneficios.
  • Indicador formado por atributos: Count(Clientes). La fórmula hace un recuento de los clientes de la empresa registrados en el origen de datos.
  • Indicador formado por otros indicadores: [Beneficios de este mes] – [Beneficios del mes pasado] / [Beneficios del mes pasado]. La formula de este indicador resta los beneficios del mes pasado (un indicador) de los beneficios de este mes (otro indicador) y divide el resultado entre el resultado del mes pasado para determinar la diferencia porcentual en beneficios desde el mes pasado.

Las formulas pueden contener funciones matematicas y Microstrategy posee un amplia abanico de ellas para permitir realizar multiples tipos de cálculos:

Funciones matematicas para utilizar en las fórmulas

Ademas de la fórmula, podemos indicar lo siguiente en las propiedades del indicador:

  1. Nivel de cálculo del indicador: indicamos el nivel en la jerarquia de atributos en el que se realiza el cálculo del indicador. Por defecto, un indicador se calcula en el nivel de informe, es decir, en el nivel del atributo del informe en el que se encuentra el indicador. Pero puede haber ocasiones en las que el cálculo solo tenga sentido en un determinado nivel (no en todos los posibles según la estructura jerarquica de atributos de las dimensiones). Con este atributo condicionamos ese aspecto.
  2. Condición:Es una condición que se incluye en los datos desde el origen de datos y aplica sólo a los datos relacionados con ese indicador en particular. El filtro entra a formar parte de la definición del indicador. La aplicación de la condicionalidad en un indicador hace que el cálculo de un indicador esté calificado por el filtro del indicador, independientemente de lo que se haya especificado en el filtro del informe, si lo hubiera. Nos permite definir indicadores con sus propias condiciones independientemente de las condiciones fijadas a nivel de informe.
  3. Transformación: Las transformaciones se agregan normalmente a los indicadores diseñados para realizar análisis de series temporales, por ejemplo, para comparar los  valores de momentos distintos, como este año frente al anterior o los del mes hasta la fecha. Las transformaciones son útiles para descubrir y analizar tendencias basadas en el tiempo en los datos.Las transformaciones se crean como objetos independientes (como hemos visto anteriormente) y se agregan a un indicador.

En el proyecto Tutorial que nos ofrece Microstrategy podemos ver ejemplos de como definir indicadores de todos los tipos posibles, desde funciones para manipular fechas, cadenas o numeros, funciones estadisticas, financieras, Olap o funciones para extraccion de datos para DataMining.

Filtros

Los filtros nos permiten establecer restricciones de valores a los diferentes elementos de nuestro sistema. Por ejemplo, podremos establecer un filtro sobre el atributo año y seleccionar un valor en concreto (por ejemplo 2009),y al ejecutar un informe con ese filtro, solo se recuperan los valores de ese año. Podriamos igualmente haber definido ese filtro de forma dinámica, de forma que al ejecutar el informe, nos aparecezca una lista de años y seleccionemos el que vamos a analizar (será un filtro de selección dinámica).

Editor de filtros

También se pueden definir los filtros sobre los indicadores, por ejemplo, para limitar que no nos aparezcan valores que sean inferiores a un valor u operaciones similares.

Selecciones dinámicas (Prompts)

Una selección dinámica es una pregunta que se hace al usuario que ejecuta un informe. Cualquier informe puede contener selecciones dinámicas. Este elemento nos permite dar un dinamismo a los informes y poder ejecutar el mismo report con diferentes criterios de ejecución. Las selecciones dinámicas pueden ser obligatorios (es imprescindible indicar un valor) u opcionales.

Las selecciones dinámicas se usan para seleccionar las condiciones de filtrado en el momento de ejecución del informe. Se puede condicionar de forma dinámica un atributo, una selección de elementos de atributo, métricas y otros objetos que se puedan incluir en un informe. Las selecciones dinámicas pueden utilizarse junto con otras selecciones estáticas, filtros, y se pueden añadir a un informe tantas como sean necesarias.

Creación de selecciones dinámicas

Tenemos los siguientes tipos de selecciones dinámicas:

  • Selección dinámica de una definición de filtro: permiten a los usuarios establecer criterios de filtrado en la ejecución de informes, que se van a aplicar sobre los valores devueltos en la ejecucion de estos. Podremos establecer filtros sobre los siguientes objetos:
    • Jerarquías: Es posible elegir dinámicamente la calificación de una jerarquía o entre cualquier atributo de cualquier jerarquía. Nos permite elegir entre todos los atributos que forman una jerarquía y seleccionar los valores de filtrado entre los valores mostrados para cada atributo.
    • Atributos: Al igual que con las Jerarquías, es posible elegir dinámicamente un atributo concreto. Similar al caso anterior, pero solo se califica sobre un atributo en concreto (por ejemplo, el año).
    • Lista de elementos de un Atributo. Esta opción permite elegir de una lista preestablecida de elementos de atributo, o bien se pueden mostrar todos los elementos. Podemos preseleccionar una lista de valores de los posibles de un atributo, y de esa lista previa, seleccionar los valores deseados.
    • Calificar sobre un indicador. La calificación de una indicador se puede hacer también de forma dinámica cuando se ejecuta un informe. Nos permite establecer restricciones conforme a los valores del indicador.
  • Selección dinámica de un objeto: permite al usuario seleccionar que objetos (tales como atributos, metricas, grupos personalizados, etc) incluir en el informe.  Por ejemplo, podemos tener una lista con varios indicadores, y a la hora de ejecutar el informe, solo seleccionaremos los indicadores que nos interesen.
  • Selección dinámica de un valor: Permite la selección dinámica de una fecha, de un valor numérico o de un texto. El valor devuelto lo podremos utilizar posteriormente en la definición de los filtros sobre una metrica o los valores de un atributo.
  • Selección dinámica de nivel: Esta opción permite al usuario especificar el nivel de calculo de un indicador.

Plantillas de Informes

Las plantillas son objetos que nos sirven de base para construir los informes. Definen el layout que tendra el informe. Las plantillas especifican el conjunto de datos que el informe debe recuperar del origen de datos y también determinan la estructura en que se muestra la información en los resultados del informe.

Cuando se crea una plantilla, se colocan los diferentes objetos de Microstrategy en el, siendo los que podemos utilizar los siguientes: atributos, indicadores, filtros y selecciones dinámicas (ademas de los grupos personalizados y las consolidaciones).

Basicamente, tenemos dos tipos de layout:

  • Tabla cruzada (cross-tab): util para analisis multidimensional.
  • Tabular: util para listados simples de información.

Editor de Plantillas

Las plantillas nos serviran de base para la construcción de informes.

Conclusiones

Hemos pasado por encima de los principales componentes que forman la base del sistema de BI Microstrategy. Son elementos mucho mas complejos de lo que hemos visto, con muchisimas opciones y funcionalidades, que nos van a dar muchisimas posibilidades de cara a cubrir nuestros requerimientos.

Os recomiendo una lectura profunda de la documentación proporcionada por Microstrategy para conocer cada uno de los elementos:

Estructura de Documentación de Microstrategy

De todo lo visto, podemos destacar:

  • Jerarquias de usuario: nos permite personalizar la estructura de los atributos definidos en el modelo. Nos permite darle nuestro enfoque al análisis, pasando por encima del modelo jerarquica general. Ademas, el hecho de poder definir filtros sobre ellas nos podrían permitir crear las jerarquias personalizadas según la persona que va a analizar la información (como por ejemplo, por ambito geográfico).
  • Indicadores: van mucho mas alla de simples calculos utilizando los valores que hemos generado en la tabla de hechos de nuestro modelo. El uso de las funciones de las que dispone microstrategy permite que podamos hacer casi de todo. Muy interesante el hecho de poder disponer de indicadores que calculan temas relacionados con los atributos (como contadores).
  • Filtros y selecciones dinámicas: nos dan dinamismo en los informes a todos los niveles, no solo a la hora de filtrar la información la información a mostrar discriminando por los valores de los atributos o de los indicadores, sino también permitiendonos seleccionar que elementos queremos que aparezcan en los informes de manera dinámica. El hecho de disponer de selecciones por los valores de los atributos de una dimensión, o de poder seleccionar entre los diferentes atributos de una jerarquia y de ahí, los valores, también nos da potencia de cara al filtrado.

Con lo visto, tenemos unas nociones básicas para empezar a trabajar con Microstrategy 9, definir los elementos básicos que luego utilizaremos (como son las jerarquías de usuario, los indicadores, filtros y selecciones dinámicas) y seguir profundizando en el resto de componentes de la herramienta.

Posted in Business Intelligence, Microstrategy | 2 Comments »

14.2. Diseño de hechos, atributos y jerarquia de dimensiones en Microstrategy 9.

Posted by Roberto Espinosa en 24 enero 2010


Una vez configurado el servidor y creado el proyecto (tal y como vimos en la entrada anterior del blog), vamos a proceder a implementar el modelo lógico de nuestro Data Warehouse dentro del esquema de metadatos de Microstrategy.

Esta tarea es fundamental para empezar a trabajar con nuestra herramienta de BI. Es el punto de partida para empezar a preparar los diferentes elementos que formaran nuestro sistema de Business Intelligence (informes, cuadros de mando, análisis, etc).

Del modelo lógico al metadata de Microstrategy

Las tareas que realizaremos en este paso será la definición de los atributos de las dimensiones, la relación entre ellos (organización jerarquica), asi como de los indicadores de negocio relevantes en nuestra organización. Aquí estableceremos la relación entre estos elementos lógicos y sus equivalentes a nivel físico (tablas y campos de la base de datos).

Os recomiendo visualizar el video elaborado por Microstrategy para ver un ejemplo real de la definición de estos elementos.

Haciendo memoria de la teoria del modelo dimensional que vimos anteriormente:

  • Hechos / indicadores: son los valores de negocio por los que querremos analizar nuestra organización (importe ventas, margen, rentabilidad).
  • Dimensiones: las perspectivas o diferentes ambitos por los que querremos analizar estos indicadores de negocio (son las que dan sentido al análisis de los indicadores de negocio, pues sin dimensiones no son mas que un valor mas).  Permite contestar preguntas sobre los hechos y darles un contexto de análisis. En nuestro modelo, las dimensiones seran el tiempo (siempre suele haber una dimensión temporal), cliente, producto, promoción y logística.

Asistente creación de proyectos

Para configurar esto dentro de Microstrategy, realizaremos tres tareas principales:

1) Selección de tablas del catalogo del Warehouse: de todas las tablas que tendremos en la base de datos del Data Warehouse, seleccionaremos con cuales de ellas vamos a trabajar. Las tablas seleccionadas y sus campos determinaran los elementos disponibles para el resto de pasos.

2) Creación de hechos: de las tablas seleccionadas en el paso anterior, indicaremos que campos son los que corresponden a los hechos. Estos campos nos serviran de base para la creación de las metricas, que seran las que utilizaremos en los informes, documentos y análisis. Estas métricas, partiendo de las base de los hechos, podran incluir operaciones, calculos de uno o mas campos, así como el uso de funciones complejas (Microstrategy incluye un gran número de funciones para realizar calculos complejos sobre los datos, incluyendo funciones estadísticas). Esto nos permitira disponer de valores que se calculan y que realmente no estan guardados en la base de datos.

3) Creación de atributos: en este paso, de la misma manera, seleccionaremos los campos que corresponden a los atributos y realizaremos la configuración básica de ellos, como descripciones, ordenación, asignación de descripciones a códigos (lookups), asi como la configuración de la estructura jerarquica de los diferentes componentes que forman una dimensión (a través de las relaciones padres e hijos).

Para realizar estas tareas, utilizaremos el Asistente para la creación de proyectos, que nos guiara de una forma ordenada, en todos los pasos a realizar para completar estas tareas. El asistente solo se utiliza cuando se crea el proyecto y los procesos de mantenimiento posteriores de las tablas, atributos y hechos los realizaremos desde la herramienta de desarrollo Microstrategy Architect o bien desde el Desktop.

Veamos un poco mas en profundidad cada uno de estos pasos:

Selección de tablas del catalogo del Warehouse

En este paso indicaremos la base de datos que corresponde al Data Warehouse, y del catalogo que indiquemos, nos apareceran todas las tablas definidas en el a nivel físico. De dichas tablas, seleccionaremos aquellas que sean relevantes para nuestro módelo (tal y como vemos en la imagen).

Selección de Tablas de DW

Microstrategy nos permite trabajar con la misma tabla varias veces a traves de los “alias” de tabla. Puede ser util cuando la misma dimensión fisica se utiliza de forma lógica en varios lugares(y no es necesario tener que tener una tabla física para cada una de las dimensiones). Igualmente, también nos permite trabajar con vistas.

Creación de Hechos

De los campos de las tablas indicadas en el punto anterior, en este paso seleccionaremos cuales de ellos son las que consideraremos Hechos. En principio, aunque se puede configurar, solo se toman para este cometido los campos que estan definidos como numéricos.

Selección de columnas de Hechos

Creación de Atributos

La creación de atributos es un poco mas compleja y lleva asociados varios pasos. En primer lugar, de todos los campos de las tablas, seleccionaremos cuales son los que corresponden a nuestros atributos. En el caso de que un atributo lleve asociado un campo identificador y un campo descripción, solo seleccionaremos el campo identificador (pues después se establecera la relación entre campos de código y campos de descripción o de lookup).

Creación de atributos

A continuación, para cada uno de los atributos, indicaremos su campo de lookup. Cuando un campo no dispone de este (como el campo Código Postal, que en si mismo se describe), indicaremos “Utilizar ID como descripción”.

Como ultimo paso en la creación de los atributos, para cada uno de ellos indicaremos que atributos son hijos de el (estan despues en la jerarquia de la dimension) o cuales son padre (estan arriba en el arbol). Este paso lo omiteremos, pues lo realizaremos a continuación con la herramienta gráfica Architect, que es mucho más agil para realizar esta definición.

Mantenimiento del módelo usando Microstrategy Architect

El Architect es, junto con el Desktop, la herramienta principal de desarrollo dentro de Microstrategy. Utilizando esta ultima herramienta podriamos igualmente haber realizado la definición de los hechos y atributos (el paso de selección de tablas habría que haberlo realizado igualmente como un paso previo).

El architect es una herramienta gráfica y con ella se realizan las tareas de mantenimiento dentro de MS. En nuestro caso, dejamos sin definir las jerarquías de atributos y las hemos completado utilizando esta herramienta. Esto es tan sencillo como seleccionar el atributo padre y arrastrar hacia el atributo hijo para que se cree la relación. Posteriormente, seleccionamos en el conector para modificar el tipo de relación entre los componentes ( 1 a n, 1 a 1, etc).

Definicion de jerarquias de atributos con Architect

En la imagen, podeis ver como hemos definido la estructura jerárquica dentro de la dimensión Cliente. Ademas, desde aquí podemos crear nuevos atributos, nuevos hechos o modificar las propiedades de estos (en la parte de la derecha tenemos la tabla de propiedades). Seleccionando el elemento, en esa sección nos aparece toda la información de como esta configurado.

Microstrategy Tutorial

Ademas del proyecto que hemos creado nosotros, al utilizar la herramienta Desktop observamos que hay creado un proyecto de ejemplo, llamado MicroStrategy Tutorial. Este proyecto trabaja con bases de datos de prueba en Access y contiene ejemplos de todos los elementos que podemos definir y utilizar en Microstrategy. Puede ser un punto de partida para aprender a trabajar con los diferentes componentes.

Igualmente, al realizar la instalación, se nos ha creado una carpeta de Documentación, donde disponemos de un lote de archivos en formato PDF con manuales completos de todas las herramientas de Microstrategy, como por ejemplo:

  • Microstrategy Evaluation Guide
  • Installation and Configuration Guide.
  • System Administration Guide.
  • Project Design Guide.
  • Basic Reporting Guide.
  • Advanced Reporting Guide.
  • Report Service Document Creation Guide.

Conclusiones

Despues de realizar estas tareas, el módelo lógico de nuestro proyecto esta implementado y configurado dentro de Microstrategy 9, y podemos comenzar a utilizar la herramienta.

Uno de los puntos fuertes que hemos observado en la herramienta es que todo esta centralizado en las mismas aplicaciones, y desde ellas realizaremos todas las tareas de desarrollo, desde la configuración del sistema, creación del modelo, asi como la creación de los componentes que utilizaran los usuarios. El producto parece ser compacto y consistente, esta es la primera impresión que transmite.

Igualmente, Microstrategy proporciona gran cantidad de documentación, ejemplos, video tutoriales, etc, para que sea más fácil empezar a trabajar con la herramienta y buscar información sobre los diferentes elementos que la conforman. Hasta se incluye en la instalación un curso Web de la herramienta con examenes de evaluación.

Posted in Business Intelligence, Microstrategy | Leave a Comment »

14.1. Instalación y configuración del servidor Microstrategy 9.

Posted by Roberto Espinosa en 23 enero 2010


Despues de descargarnos la versión de evaluación gratuita de Microstrategy 9 de su Web, procederemos al registro del producto. Para esto, utilizaremos el código de promocion que nos proporcionan y a la vuelta,  nos enviarán el código de activación que sera el que nos permita utilizar la funcionalidad completa de la herramienta durante 30 dias (sino lo activamos solo se puede utilizar durante 7 dias).

Antes de instalar, vamos a tener en cuenta que requisitos de aplicaciones tiene la suite:

  1. Sistema Operativo: Windows 2003 SP2, Windows 2003 R2 SP2, Windows XP Professional Edition SP3 (on x86) or SP2 (on x64), Windows Vista Business Edition SP1, or Windows Vista Enterprise Edition SP1 (all Windows operating systems on x86 or x64). También se puede instalar la suite en Windows XP o Vista, pero solo para propositos de evaluación (como es nuestro caso).
  2. Servicios de Internet: Microsoft Internet Information Services (IIS) version 5.1, 6.0, or 7.0
  3. Explorador Web: Microsoft Internet Explorer version 6.0.2 or 7.0
  4. Lector Pdf: Adobe Reader version 7.0, 8.0, 8.1, or 9.0
  5. Adobe Flash Player version 9.0
  6. Para evaluar el MicroStrategy Office, cualquier de las versiones siguientes de Office:Microsoft Office 2002 (XP) SP3, Microsoft Office 2003 SP3 y Microsoft Office 2007 SP1.

A continuación lanzaremos el proceso de instalación, en el que se nos pedirá la ubicación de los ficheros y los elementos a instalar. Si alguna de las dependencias para instalar la suite no se cumple, se nos avisará de ello. Una vez concluido el proceso de instalación, continuaremos con la configuración. Como ayuda, os recomiendo el video Set Up and Configure the Server: Instalación y configuración del servidor. Una vez concluido el proceso, el sistema se reiniciara. Sería conveniente en este momento realizar el registro de las licencias utilizando el License Manager.

Bases de datos necesarias para utilizar Microstrategy 9

Para trabajar con Microstrategy, tendremos que tener disponibles varios esquemas de base de datos, cada uno con un cometido diferente:

  • Datawarehouse: una o varias bases de datos de donde la herramienta leera la información (según el módelo que construyamos), para elaborar los informes, consultas, cuadros de mando, cubos, etc. Es la base de datos que hemos modelado y construido en la fase de analísis de nuestro proyecto y llenado con los procesos ETL utilizando Talend.
  • Metadata: son las tablas internas de Microstrategy donde se guarda toda la información del modelo de datos que definamos y de todos los objetos que construyamos utilizando la herramienta (filtros, informes, indicadores, etc.). Es el corazon del sistema de BI.
  • Historial: historial de las modificaciones que realizemos con los objetos.
  • Estadisticas: tablas para mantener y controlar la actividad del sistema.

Microstrategy nos permite trabajar de forma directa con los principales motores de base de datos (DB2, Informix, MySql, Oracle, PostreSQL, Sybase o SQL Server). Igualmente, a través de ODBC podremos acceder a otras muchas bases de datos (comprobad las tablas de compatibilidad en la documentación).

Motores de bases de datos a utilizar con Microstrategy

En nuestro caso, utilizaremos ODBC, con el driver proporcionado por MySql. Y configuraremos las siguientes origenes de datos (podemos utilizar el Connectivity Configuration Wizard proporcionado por Microstrategy o el gestor de conexiones ODBC de Windows):

  • ENOBI_DW: base de datos donde se ubicara el Datawarehouse (corresponde a la base de datos con esquema ENOBI en MySql).
  • ENOBI_MD: base de datos donde se ubicara el Metadata de nuestro proyecto (corresponde a la base de datos con esquema METADATA en MySql).
  • ENOBI_HS: base de datos donde se ubicara el Historial (esquema HISTORIAL en MySql).
  • ENOBI_ES: base de datos donde estarán las estadísticas (esquema ESTADISTICAS en MySql).

Configuración Inicial del Sistema

Una vez definidos las conexiones ODBC e instalada correctamente la aplicación y su licencia, vamos a utilizar el asistente de configuración (Configuration Wizard) para dejar el sistema listo para empezar a trabajar con el.

El configuratión Wizard tiene 3 tareas a realizar, que son la siguientes:

Configuration Wizard

  • Tablas de repositorio: en este paso creamos en las bases de datos los catalogos de tablas necesarios para los diferentes componentes (como hemos visto METADATA, ESTADISTICAS e HISTORIAL). El proceso se conecta a las bases de datos y crea en ellas todas las tablas necesarias para gestionar el metadatos de microstrategy, llenando ademas el contenido de las tablas con los objetos predefinidos.

Creacion del repositorio de tablas del Metadata

  • Definiciones de MicroStrategy Intelligence Server: el Microstrategy Intelligence Server es el motor de procesamiento y gestion de los trabajos de las aplicaciones de informes, análisis y monitorización. Utiliza una arquitectura orientada al servicio (SOA), y estandariza en una única plataforma todas las necesidades de analisis y reporting, a traves de varios canales de acceso:Web browsers, Microsoft® Office, Desktop clients,y email. En este paso de la configuración le asociamos al Intelligence Server el esquema de base de datos del METADATA (que habremos dejado preparado en el paso anterior), e indicamos parametros adicionales de configuración (como el puerto TCP o si queremos registrarlo como un servicio). Tendremos un unico Intelligence Server en nuestro sistema.

Configuracion Intelligence Server

  • Orígenes de Proyecto: un origen de proyecto es la ubicación centralizada de los diferentes proyectos. Es un contenedor que luego nos permitira definir dentro de el los proyectos que tengamos en nuestra infraestructura de BI. Se pueden definir varios origenes de proyecto (no necesariamente solo uno). Al crear un origen de proyectos, le asociamos un tipo de origen y le indicamos el tipo de validación de usuarios que se va a realizar para el ( usuario de windows, usuario de Microstrategy, usuario LDAP, usuario de base de datos, etc). En nuestro caso creamos el origen de Proyecto ENOBI que va a incluir todos los elementos de nuestro proyecto.

Definición de Origenes de Proyecto - Tipo de validación de usuarios

Los tipos de Origen de proyecto son los siguiente, segun el  tipo de configuración:

  • Directo o 2 niveles: pensado para instalaciones de test, formación o prototipos. En este caso, no pasamos a través del Intelligence Server, sino que accedemos directamente al Metadata cuando creemos un proyecto (por eso hay que indicar que origen de datos contiene el Metadata).
  • Microstrategy Intelligence Server o 3 niveles: pensado para instalaciones en productivo. En este caso pasamos a través del Intelligence Server, y por tanto, utilizamos el origen de datos del Metadata que definimos anteriormente en él.

Esquema Arquitectura Microstrategy

En un origen de Proyectos podremos definir uno o varios proyectos utilizando el Project Builder o  el Microstrategy Desktop (y su asistente para la creación de proyectos).

Hemos concluido con estos paso la configuración básica de nuestro servidor de Microstrategy 9. Ha sido relativamente sencillo dejar el sistema preparado para comenzar a trabajar con las herramientas de Microstrategy.

Creación del proyecto ENOBI

Es el último paso para poder empezar a trabajar con las herramientas de Microstrategy. Un proyecto ha de estar siempre ubicado en un origen de Proyectos, como hemos visto. Para la creación del proyecto, tenemos dos herramientas:

  • Project Builder: es un asistente pensado para la creación de proyectos sencillos, demos y prototipos, por lo que tiene bastantes limitaciones. Para cualquier proyecto productivo, sera conveniente utilizar la herramienta Desktop. En la entrada 8 del blog, construimos un prototipo de nuestro proyecto utilizando esta herramienta (se explica allí de forma detallada todos los pasos seguidos).
  • Desktop – Asistente para la creación del proyectos: es la herramienta principal de desarrollo para trabajar con Microstrategy. En la herramienta Desktop vemos los diferentes origenes de proyecto que tenemos definidos en nuestro sistema, y seleccionaremos uno de ellos para crear en él el nuevo proyecto. A continuación lanzaremos el asistente, tal y como vemos en pantalla. Tiene una serie de pasos donde configuraremos los diferentes elementos que conformaran el modelo Dimensional del proyecto. Con la herramienta Architect se completa la configuración jerárquica de los atributos que forman las dimensiones.

Podeis ver el video de Microstrategy donde se detallan todos los pasos a seguir para la creación de un proyecto y sus componentes.

Asistente para la creación de Proyectos

Con la herramienta realizaremos una asociación entre las tablas de bases de datos del Data Warehouse (modelo físico), con los elementos lógicos de nuestro módelo (dimensiones y sus atributos; jerarquía entre los diferentes atributos que forman las dimensiones y finalmente, hechos e indicadores de negocio ). Detallaremos los pasos seguidos para realizar esto en la siguiente entrada del Blog.

Posted in Business Intelligence, Microstrategy | 3 Comments »

14. Implementación del sistema BI utilizando Microstrategy.

Posted by Roberto Espinosa en 20 enero 2010


Aunque ya utilizamos la Microstrategy Reporting Suite para la construcción del prototipo de nuestro proyecto (ver entrada del blog ), antes de realizar la implementación completa del proyecto vamos a hablar un poco de Microstrategy.

Microstrategy es una compañia norteamericana, fundada en Virginia en 1989. Esta especializada en ambitos de Inteligencia de Negocio. Después del ultimo baile de adquisiciones (Cognos por parte de IBM, Business Objects por parte de Sap, etc.), se ha quedado como uno de los pocos grandes fabricantes de software BI independientes.

Parte de la fuerza de Microstrategy radica en su especialización, y en que su producto es realmente una plataforma integrada de herramientas de Inteligencia de negocio, y no diferentes productos agregados para formar una suite (como es el caso de otros fabricantes, conseguido en ocasiones a base de adquisiciones). Aparece en el cuadrante superior de los informes Gartner (tal y como vemos en la imagen) y cuenta con unos de los mayores porcentajes de fidelidad por parte de los clientes.

Su producto principal es la suite Microstrategy 9, que incluye todos los elementos para crear la estructura de business intelligence en una empresa.

Arquitectura de Microstrategy Reporting Suite

Algunas de las características mas importantes de la versión 9 son la siguientes (podeis ampliar información en la entrada del blog BI Facil ):

Los elementos mas importantes que forman la herramienta de Microstrategy son los siguientes:

MicroStrategy metadata: repositorio que almacena las definción de los objetos de MicroStrategyy la información sobre el data warehouse.
MicroStrategy Intelligence Server: servidor analitico optimizado para el reporting empresarial y para el analisis Olap.
MicroStrategy Desktop: aplicación en entorno windows que proporciona un completo abanico de funciones analíticas  diseñadas para facilitar el desarrollo de informes.
MicroStrategy Web and Web Universal: interfaz de usuario altamente interactivo para la ejecución de informes y análisis.

Componentes de Microstrategy

•MicroStrategy project: lugar donde definimos y almacenamos todos los objetos del esquema y la información que necesitamos  para trabajar con nuestro sistema de reporting y analisis.
•MicroStrategy Architect,: herramienta para el diseño de los proyectos, que nos permite definir de forma gráfica todos los componentes requeridos para el proyecto desde una interfaz centralizada.

Los componentes de la plataforma de MicroStrategy trabajan de forma conjunta para proporcionar un entorno de analisis y reportig a la comunidad de usuarios de una organización, tal y como vemos en la imagen anterior.

Como parte de su estrategia para captar clientes de medianas empresas, y también para plantar cara al gran desarrollo de las soluciones BI Open Source, Microstrategy ha liberado una parte de su producto en la Reporting Suite. Podemos ver en la imagen la parte que incluye la Reporting Suite, y la parte adicional de la que podriamos disponer si compramos la Suite Microstrategy 9. La MRS incluye licencia gratuita indefinida para 1 CPU y 25, 50 o 100 usuarios nominales y también 60 dias de soporte técnico via email. De la misma manera, tenemos acceso a su centro de recursos, donde se dispone de una amplia base de conocimiento, manuales completos de los productos, foros de discusión o recursos para desarrolladores (ver la guia rapida para empezar aquí ). Se supone que con este tipo de licencia, las empresas podrán cubrir una parte de sus necesidades en el ámbito del reporting y BI,  conocer la herramienta y ampliar con la parte de pago las funcionalidades, según vayan surgiendo nuevas necesidades.

Web del Centro de Recursos de Microstrategy

Para el proyecto ENOBI vamos a utilizar la versión de evaluación gratuita de Microstrategy 9,que podremos probar durante 30 dias. Para contruir nuestro sistema, nos valdrá todo lo que aprendimos montando el prototipo de evaluación inicial (pues la herramienta de modelado y desarrollo, el MicroStrategy Desktop y MicroStrategy Architect son comunes a ambas versiones, y nos valdrá todo lo que aprendimos en su momento).

Podriamos haber utilizado la Reporting Suite, pero tenemos el objetivo de comparar una versión Propietaria de software BI con una versión Open (que será Pentaho). Y para que ese análisis sea mas amplio, es preferible tener la versión completa. De esta forma podremos realizar un cuadro comparativo de la funcionalidad con cada herramienta ( y especificar de una forma clara las ventajas de una y otra, puntos fuerte y debiles, en que herramienta es mas facil hacer que tipo de cosas, para que cosas se necesita desarrollo adicional o conocimientos técnicos mas profundos, en que puntos cambiamos la facilidad de montaje por horas de consultoria pero menos precio de licencias, etc).

Esa comparativa entre Microstrategy y Pentaho será el pilar principal de nuestra investigación a partir de este momento, que nos va a permitir conseguir un amplio conocimiento de las herramientas, e igualmente llevar a la práctica y profundizar en mas conceptos de la teoria de la inteligencia de negocio (reporting, cuadros de mando, olap, data mining).

Igualmente, intentaremos comparar dos productos en el ámbito de las ETL Opensource, como son Talend Open Studio (del que ya hemos visto unas cuantas cosas ), y Pentaho Data Integration (Kettle), con el que intentaremos reproducir todos los procesos realizados hasta el momento para la carga del DW.

Y para que vayais entrando en calor, nada como unos videos tutoriales que se publican en la Web de Microstrategy para conocer el producto:

Como información adicional para empezar a trabajar con Microstrategy os dejo el link a unos cursos de la herramienta realizados por Anibal Goicoechea (gracias por su aportacion, podeis visitar su blog).

Comparativas Microstrategy – Otros productos BI

Finalmente, os dejo unas comparativas de Microstrategy con los principales productos del mercado ( Sap Business Objects, IBM Cognos, Oracle OBIEE Plus, Microsoft y Qliktech ), que os pueden servir en el caso de que esteis realizando una selección del producto a utilizar (ver comparativa).

Comparativas con otros productos BI

Son muy interesantes, pues comparan el producto de Microstrategy con sus competidores a un gran nivel de detalle, remarcando que cosas se pueden hacer con MS y no con los competidores, ademas de incluir whitepapers independientes. No disponen de una comparativa con productos Open (intentaremos realizar nosotros al final de nuestro proyecto la nuestra con Pentaho).

Posted in Business Intelligence, Microstrategy | 4 Comments »

13.5. Exportación jobs en Talend.Planificacion procesos ETL.

Posted by Roberto Espinosa en 18 enero 2010


Una vez concluido el desarrollo de los procesos para la carga del DW, la siguiente tarea sera la planificación de estos para su ejecución regular, de forma que vayan reflejando en el DW todos los cambios que se vayan produciendo en el sistema operacional ( modificaciones en los datos maestros y nuevos hechos relacionados con los procesos de negocio de ventas).

Los jobs que hemos definido usando Talend se podrían ejecutar a petición desde la herramienta, o bien a nivel de sistema operativo, utilizando la correspondiente herramienta (CRON en Unix/Linux, AT en Windows). Para ello es necesario generar los ficheros de scripts a nivel de sistema operativo.

Para hacer esto, hemos de exportar el Job, pulsando con el botón derecho sobre el. Nos aparecera el correspondiente menú contextual, donde podremos seleccionar la opción “Export Job Scripts“. Como ya comentamos, Talend puede trabajar a nivel de generación de código con los lenguajes Java y Perl. Cuando creamos un proyecto, seleccionamos con que lenguaje vamos a trabajar(en nuestro caso hemos seleccionado Java), lo que determina que internamente se trabaje a todos los niveles con Java, al igual que a la hora de definir expresiones en los diferentes procesos y transformacion. De la misma manera, cuando exportemos los correspondientes scripts de un Job, estos se generarán utilizando dicho lenguaje.

Al exportar el Job, nos aparece un cuadro de diálogo, como el que veis a la derecha, donde se nos pide un directorio para realizar la generación de todos los elementos necesarios, ademas de indicar una serie de opciones:

Tipo de exportación: trabajo autonomo, Axis web service, JBoss ESB.

Versión del job: podemos realizar una gestión de versiones de las modificaciones que vamos realizando sobre este y luego descargar una versión en concreto.

Sistema operativo para generar el shell: indicamos para que tipo de sistema va a preparar los scripts para la posterior ejecución de los procesos.

Incluir objetos dependientes: podemos hacer que en el directorio de exportación se incluyan todos los elementos necesarios para la ejecución independiente del trabajo (módulos talend, librerias java, rutinas del sistema).  Esto nos permitirá llevarnos el job y ejecutarlo en cualquier sitio sin necesitar nada mas (solo la correspondiente maquina virtual java).

Source files: podemos generar también el código fuente de nuestros jobs (para analizarlo o modificarlo directamente). Recordemos que Talend realmente es un generador de código, que utiliza la plataforma Eclipse.

Contexto a utilizar: de todos los contextos que tenga definido el job, podemos indicar con cual se van a generar los scripts de ejecución (aunque luego podremos modificar el script para ejecutar con otro contexto,  no es mas que un parametro de ejecución).

Una vez exportados los jobs, vemos que en la carpeta donde se ha exportado, aparecen los siguientes elementos:

  • Directorio “NombreJob”: aparecen los scripts para ejecutar el job ( NombreJob_run.bat y NombreJob_run.sh), y la libreria NombreJob_version.jar, que es la que se llama desde el script para arrancar la ejecución del proceso. Es la libreria Java que se ha construido con todos los elementos y componentes que hemos utilizado para la definición de nuestro Job. Dento de estar carpeta cuelga otra donde se guardan los ficheros con los valores de las variables de contexto (en ficheros del tipo properties).

Script de ejecución de un job para Windows

En el script, observamos como se le pasa como parametro el contexto con el que queremos que se ejecute el Script. Es sencillo cambiarlo y teniendo preparados los juegos de variables correspondientes en diferentes ficheros de contexto, podremos trabajar con los mismos jobs trabajando sobre diferentes entornos o ejecutar los jobs con valores personalizados.

  • Directorio “Lib”: aparecen todas las librerias java necesarias para la ejecución independiente del job. En nuestro caso, por ejemplo, que hemos utilizado controles para envio de mail (aparece la libreria mail.jar), conexión a mysql (aparece la libreria mysql-connector-java*.jar), conexión a oracle (libreria ojdbc14-9i.jar), rutinas de usuario (userRoutines.jar), etc.

Para realizar la planificación de los jobs, podriamos utilizar el CRON del sistema operativo Unix/Linux (preparando su correspondiente fichero crontab ), o bien a nivel de Windows utilizando AT o alguna herramienta similar como WinAT. Talend proporciona una herramienta para preparar los ficheros crontab. La herramienta es el OpenScheduler (tal y como vemos en la imagen).

Talend Open Scheduler

De una forma visual, podemos elegir los diferentes parametros de ejecución del job  (dia del mes, dia de la semana, mes, hora, minutos). A partir de las entradas grabadas en el OpenScheduler, podemos generar un fichero con los parametros necesarios para incorporar la programación de los jobs a las tablas crontab de nuestro sistema y asi planificar la ejecución de los procesos en los momento indicados.

Planificación de Jobs para el proyecto Enobi

Utilizando los scripts generados, planificaremos en nuestro sistema un lote de trabajos que ejecutará, en primer lugar, la carga de las dimensiones. Una vez concluida esta, se lanzara la carga de la tabla de hechos de venta (pues llevan incluidos datos que dependen de los existentes en las dimensiones).

La siguiente fase de nuestro proyecto será la explotación del DW utilizando la herramienta de Microstrategy 9. En primer lugar, teniendo en cuenta el diseño definitivo, configuraremos el modelo de datos dentro de el, para posteriormente abordar la explotación del sistema. Esta incluirá todos los ambitos del Business Intelligence. Veremos ejemplos de informes, cubos olap y navegación dimensional, cuadros de mando e indicadores kpi´s y también funciones de Data Mining.

Posted in Business Intelligence, ETL, OpenSource, Talend | 2 Comments »

13.4.2. Tabla Hechos Venta. Ajuste diseño fisico y procesos carga ETL. Contextos en Talend.

Posted by Roberto Espinosa en 18 enero 2010


Vamos a desarrollar los procesos de carga de la tabla de hechos de ventas de nuestro proyecto utilizando Talend. Antes de esto, vamos a hacer algunas consideraciones sobre la frecuencia  de los procesos de carga que nos van a permitir introducir el uso de un nuevo elemento de Talend, los contextos.

En principio, vamos a tener varios tipos de carga de datos:

Carga inicial: será la primera que se realice para la puesta en marcha del proyecto, e incluira el volcado de los datos de venta desde una fecha inicial (a seleccionar en el proceso) hasta una fecha final.

Cargas semanales: es el tipo de carga mas inmediato. Se realiza para cada semana pasada (por ejemplo, el martes de cada semana se realiza la carga de la semana anterior), para tener un primer avance de información de la semana anterior (que posteriormente se refrescara para consolidar los datos finales de ese periodo). La carga de una semana en concreto también se podrá realizar a petición (fuera de los procesos batch automáticos).

Recargas mensuales: una vez se cierra un periodo mensual (lo que implica que ya no puede haber modificaciones sobre ese periodo), se refresca por completo el mes en el DW para consolidar la información y darle el status de definitiva para ese periodo. La ejecución es a petición y se indicara el periodo de tiempo que se quiere procesar.

Teniendo en cuenta esto, definiremos un unico proceso de traspaso al cual se pasaran los parametros que indicaran el tipo de carga a realizar. Para ello utilizaremos los contextos de Talend. Cada tipo de carga tendra un contexto personalizado que definira como se va a comportar el proceso.

Contextos en Talend

Los contextos de Talend son grupos de variables contextuales que luego podemos reutilizar en los diferentes jobs de nuestras transformaciones. Nos pueden ser utiles para muchas cosas, como para tener definidas variables con los valores de paths de ficheros, valores para conexión a bases de datos (servidor, usuario, contraseña, puerto, base de datos por defecto, etc), valores a pasar a los procesos (constantes o definidos por el usuario en tiempo de ejecución). Los valores de los contextos se inicializan con un valor que puede ser cambiado por el usuario mediante un prompt (petición de valor). Un mismo contexto puede tener diferentes “grupos de valores”. Es decir, en el contexto “conexion a base de datos”, podemos tener un grupo de valores llamado “test”, que incluira los valores para conectarnos al sistema de pruebas y un grupo llamado “productivo”, que incluira los valores para la conexión a la base de datos real (tal y como vemos en el ejemplo).

Definición de Contextos en Talend

Dentro del contexto, definiremos que grupo de valores es el que se utilizara por defecto. Esto nos va a permitir trabajar con los jobs y sus componentes olvidandonos de contra que sistema estamos trabajando. Tendremos, por ejemplo, el contexto de test activo, y es el que utilizaremos para las pruebas. Y podremos cambiar en cualquier momento, al ejecutar un job, para decirle que utilice el contexto “productivo”. Igualmente, podremos preparar un fichero o una tabla de base de datos con los valores de las variables de contexto, que serán pasadas al job para su utilización en la ejecución de un proceso (utilizando el componente tContextLoad).

Definición del proceso de carga

El diseño físico definitivo de la tabla de hechos será el siguiente:

Una vez hechas todas las consideraciones, veamos el esquema de como quedaria nuestro proceso de transformación.

Job completo en Talend para la carga de la tabla de Hechos

Vamos a ver en detalle cada uno de los pasos que hemos definido para realizar la lectura de datos del sistema origen y su transformación y traspaso al sistema destino (y teniendo en cuenta varios procesos auxiliares y la carga del contexto de ejecución).

1) Ejecución de un prejob que  lanzará un generara en el log un mensaje de inicio del proceso y un logCatcher (para recoger las excepciones Java o errores en el proceso).  Este generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job (al igual que hemos incluido en todos los jobs de carga del DW vistos hasta ahora).

  • Lanzador Prejob (componente tPrejob): sirve para realizar el lanzamiento de un pretrabajo, anterior al proceso principal.
  • Mensaje Log Inicio (componente tWarn): genera un mensaje de log indicando que se comienza la ejecución del job.
  • Control Errores (componente tLogCatcher): activamos el componente que “escuchara” durante toda la ejecución del job, esperando que se produzca algún tipo de error. En ese momento se activara para recuperar el error y pasarlo al componente siguiente para el envio de un email de notificación.
  • tFlowtoIterate: convertimos el flujo de registros de log a una iteración para poder realizar el envio del correo electrónico.
  • Envio Email Notif (componente tSendMail): generamos el envio de un email de notificación de errores, incluyendo el paso donde se paro el proceso, y el mesaje de error generado. Es una forma de avisar que ha fallado algo en el proceso.

2) Carga del contexto de ejecución: para que el proceso sepa que tipo de carga ha de  realizar y para que periodo de fechas, es necesario proporcionarle la información. Esto lo haremos utilizando los contextos. En este caso, tal y como vemos en la imagen, el contexto tendrá 3 variables, donde indicaremos el tipo de carga y la fecha inicio y fin del periodo a procesar.

Contexto para la ejecución del Job

Los valores para llenar el contexto los recuperaremos de un fichero de texto (también lo podiamos haber recuperado de los valores existentes en una tabla de la base de datos). El fichero contendrá lineas con la estructura “clave=valor”, donde clave sera el nombre de la variable y valor su contenido.

Para abrir el fichero, utilizaremos el paso LEE_FICHERO_PARAMETROS (componente tFileInputProperties), que nos permite leer ficheros de parametros. A continuación cargaremos los valores recuperados en el contexto utilizando el paso CARGA_CONTEXTO, del tipo tContextLoad. A partir de este momento ya tenemos cargado en memoria el contexto con los valores que nos interesan y podemos continuar con el resto de pasos.

Podriamos haber dejado preparados los valores de contexto en una tabla de base de datos y utilizar un procedimiento parecido para recuperarlos y con el componente tContextLoad  cargarlos en el job. Tened en cuenta que los ficheros que va a leer el job habrán sido previamente preparados utilizando alguna herramienta, donde se definira el tipo de carga a realizar y el periodo (y dichos valores se registraran en el fichero para su procesamiento).

3) Borrado previo a la recarga de los datos del periodo en la tabla de hechos (para hacer un traspaso desde cero): antes de cargar, vamos a hacer una limpieza en la tabla DWH_VENTAS para el periodo a tratar. De estar forma, evitamos inconsistencia en los datos, que podrían haber sido cargados con anterioridad y puede haber cambios para ellos. Con el borrado, nos aseguramos que se va a quedar la última foto completa de los datos. Para hacer esto, utilizamos el paso BORRAR_DATOS_PERIODO (del tipo tMySqlRow).

Observad como en el paso hemos incluido la ejecución de una sentencia sql de borrado (DELETE), y le hemos pasado como valores en las condiciones del where las fechas del periodo, utilizando las variables de contexto.

4) Lectura de datos desde los pedidos de venta (cabecera) y a partir de cada pedido, de las lineas (desde el ERP).

A continuación, procederemos a recuperar todos los pedidos de venta del periodo para obtener los datos con los que llenar la tabla de Hechos. Para ello, utilizamos el paso LEER_CABECERA_PEDIDO (del tipo tOracleInput), con el que accedemos a oracle y obtenemos la lista de pedidos que cumplen las condiciones (observar como también en la sentencia SQL ejecutada por este componente hemos utilizado las variables de contexto).

A continuación, para cada pedido, recuperamos todas las lineas que lo componen con el paso LEER_LINEAS_PEDIDO (también del tipo tOracleInput) y pasamos todos los datos al componente tMap para realizar las transformaciones, normalización y operaciones, antes de cargar en la base de datos.

5) Transformación de los campos, normalización, operaciones.

Los valores de los datos de cabeceras y lineas de pedido recuperados desde Sap los transformamos a continuación conforme a la especificaciones que hicimos en el correspondiente análisis (ver entrada blog). En este proceso realizamos conversión de tipos, llenado de campos vacios, cálculos, operaciones. Todo con el objetivo de dejar los datos preparados para la carga en la tabla de Hechos de la base de datos.

Transformaciones de los datos de pedidos antes de grabar en tabla Hechos

En este ejemplo,  hemos utilizado un elemento nuevo del control tMap, que son las variables (ver la parte central superior). Las variables nos permiten trabajar de forma mas agil con los procesos de transformación, filtrado, conversión y luego se pueden utilizar para asignar a los valores de salida (o ser utilizadas en expresiones que las contengan).

Por ejemplo, observar que hemos creado la variable UNIDADES, y en ella hemos hecho un calculo utilizando elementos del lenguaje Java:

row6.shkzg.equals("X")?-1 * Float.valueOf(row6.kwmeng):Float.valueOf(row6.kwmeng)

El campo SHKZG de los pedidos nos indica si un pedido es venta o abono. Por eso, si dicho campo tiene el valor X, hemos de convertir los importe a negativo. Observad también como luego utilizamos las variables definidas en la sección VAR en el mapeo de campos de salida.

Para los campos que son clave foranea de las correspondientes tablas de dimensiones (código de cliente, material, etc), hemos realizado las mismas transformaciones que realizamos cuando cargamos dichas tablas, para que todo quede de forma coherente y normalizada.

6) Inserción en la tabla de hechos y conclusión del proceso.

Como paso final, vamos realizando el insertado de los registros en la tabla DWH_VENTAS utilizando el componente tMysqlOutput (tal y como vemos en la imagen).

Una vez realizada toda la lectura de datos e inserción, concluiremos el proceso generando un mensaje de conclusión correcta del Job en la tabla de Logs con el paso MENSAJE_LOG_FIN (componente tipo tWarn).

Observad como hemos incluido, intercalados en los diferentes pasos del job, unos llamados VER_REGISTROS (del tipo tLogRow). Es un paso añadido para depuración y comprobación de los procesos (aparece en consola los valores de los registros que se van procesando). En el diseño definitivo del job estos pasos se podrían eliminar.

Para ver en detalle como hemos definido cada componente, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Conclusiones

Hemos terminado el desarrollo de todos los procesos de carga para llenar nuestro DW. Para cada una de las dimensiones y para la tabla de hechos, hemos construido un proceso con Talend para llenarlos. Como ultima actividad, nos quedaría combinar todos esos procesos para su ejecución conjunta y planificarlos para que la actualización del DW se produzca de forma regular y automatica.

Igualmente, veremos la forma de exportar los procesos en Talend para poder ejecutarlos independientemente de la herramienta gráfica (nos permitira llevar a cualquier sitio los procesos y ejecutarlos, pues al fin y al cabo es código java).

Todo esto lo veremos en la siguiente entrada del blog.

Posted in Business Intelligence, ETL, OpenSource, Talend | 2 Comments »

13.4.1. Tabla Hechos Venta. Particionado en MySql.

Posted by Roberto Espinosa en 15 enero 2010


Antes de comenzar la implementación del proceso ETL para la carga de la tabla de Hechos de Ventas, vamos a realizar alguna consideración sobre el particionado de tablas.

Cuando estamos costruyendo un sistema de business intelligence con su correspondiente datawarehouse, uno de los objetivos (aparte de todas las ventajas de sistemas de este tipo: información homogenea, elaborada pensando en el analisis, dimensional, centralizada, estatica, historica, etc., etc.) es la velocidad a la hora de obtener información. Es decir, que las consultas se realicen con la suficiente rapidez y no tengamos los mismos problemas de rendimiento que suelen producirse en los sistemas operacionales (los informes incluso pueden tardar horas en elaborarse).

Para evitar este problema, hay diferentes técnicas que podemos aplicar a la hora de realizar el diseño fisico del DW. Una de las técnicas es el particionado.Pensar que estamos en un dw con millones de registros en una unica tabla y el gestor de la base de datos ha de mover toda la tabla. Ademas, seguramente habrá datos antiguos a los que ya no accederemos casi nunca (datos de varios años atras). Si somos capaces de tener la tabla “troceada” en segmentos mas pequeños seguramente aumentaremos el rendimiento y la velocidad del sistema.

El particionado nos permite distribuir porciones de una tabla individual en diferentes segmentos conforme a unas reglas establecidas por el usuario. Según quien realize la gestión del particionado, podemos distinguir dos tipos de particionado:

Manual: El particionado lo podriamos realizar nosotros en nuestra lógica de procesos de carga ETL (creando tablas para separar los datos, por ejemplo, tabla de ventas por año o por mes/año). Luego nuestro sistema de Business Intelligence tendrá que ser capaz de gestionar este particionado para saber de que tabla tiene que leer según los datos que le estemos pidiendo (tendra que tener un motor de generación de querys que sea capaz de construir las sentencias para leer de las diferentes tablas que incluyen los datos). Puede resultar complejo gestionar esto.

Automatico: Las diferentes porciones de la tabla podrán ser almacenadas en diferentes ubicaciones del sistema de forma automatica según nos permita el SGBDR que estemos utilizando.La gestión del particionado es automática y totalmente transparente para el usuario, que solo ve una tabla entera (la tabla “lógica” que estaria realmente partida en varias tablas “fisicas”). La gestión la realiza de forma automática el motor de base de datos tanto a la hora de insertar registros como a la hora de leerlos.

La partición de tablas se hace normalmente por razones de mantenimiento, rendimiento o gestión.

Lógica Particionado de tablas

Según la forma de realizar el particionado, podriamos distinguir:

Partición horizontal (por fila): consiste en repartir las filas de una tabla en diferentes particiones. Por ejemplo, los clientes de un pais estan incluidos en una determinada partición y el resto de clientes en otra. En cada partición se incluyen los registros completos de cada cliente.

Partición vertical( por columna): consiste en repartir determinadas columnas de un registro en una partición y otras columnas en otra (partimos la tabla verticalmente,). Por ejemplo, en una partición tenemos las columnas de datos de direcciones de los clientes, y en otra partición las columnas de datos bancarios.

Cada motor de base de datos implementa el particionado de forma diferente. Nosotros nos vamos a centrar en la forma de implementarlo utilizando Mysql, que es la base de datos que estamos utilizando para nuestro proyecto.

Particionado de tablas en MySql

MySql implementa el particionado horizontal. Basicamente, se pueden realizar cuatro tipos de particionado, que son:

  • RANGE: la asignación de los registros de la tabla a las diferentes particiones se realiza según un rango de valores definido sobre una determinada columna de la tabla o expresión (ver manual online de MySql aquí ). Es decir, nosotros indicaremos el numero de particiones a crear, y para cada partición, el rango de valores que seran la condicion para insertar en ella, de forma que cuando un registro que se va a introducir en la base de datos tenga un valor del rango en la columna/expresion indicada, el registro se insertara en dicha partición.
  • LIST: la asignación de los registros de la tabla a las diferentes particiones se realiza según una lista de valores definida sobre una determinada columna de la tabla o expresión (ver manual online de MySql aquí ). Es decir, nosotros indicaremos el numero de particiones a crear, y para cada partición, la lista de valores que seran la condicion para insertar en ella, de forma que cuando un registro que se va a introducir en la base de datos tenga un valor incluido en la lista de valores, el registro se insertara en dicha partición.
  • HASH: este tipo de partición esta pensado para repartir de forma equitativa los registros de la tabla entre las diferentes particiones. Mientras en los dos particionados anteriores eramos nosotros los que teniamos que decidir, según los valores indicados, a que partición llevamos los registros, en la partición HASH es MySql quien hace ese trabajo. Para definir este tipo de particionado, deberemos de indicarle una columna del tipo integer o una función de usuario que devuelva un integer (ver manual online de MySql aquí ). En este caso, aplicamos una función sobre un determinado campo que devolvera un valor entero. Según el valor, MySql insertará el registro en una partición distinta.
  • KEY: similar al HASH, pero la función para el particionado la proporciona MySql automáticamente (con la función MD5) (ver manual online de MySql aquí ). Se pueden indicar los campos para el particionado, pero siempre han de ser de la clave primaria de la tabla o de un indice único.
  • SUBPARTITIONS: Mysql permite ademas realizar subparticionado. Permite la división de cada partición en multiples subparticiones. (ver manual online de MySql aquí).

Ademas, hemos de tener en cuenta que la definición de particiones no es estática. Es decir, MySql tiene herramientas para poder cambiar la configuración del particionado a posteriori, para añadir o suprimir particiones existentes, fusionar particiones en otras, dividir una particion en varias, etc. (ver aquí ).

El particionado tiene sus limitaciones y sus restricciones, pues no se puede realizar sobre cualquier tipo de columna o expresión (ver restricciones al particionado aquí), tenemos un limite de particiones a definir y habrá que tener en cuenta algunas cosas para mejorar el rendimiento de las consultas y evitar que estas se recorran todas las particiones de una tabla (ver el artículo MySql Partitions in Practice, donde se nos explica con un ejemplo trabajando sobre una base de datos muy grande, como realizar particionado y que cosas tener en cuenta para optimizar los accesos a las consultas). Para entender como funciona el particionado, hemos replicado los ejemplos definidos en este articulo con una tabla de pruebas de 1 millón de registros (llenada, por cierto,con datos de prueba generados con Talend y el componente tRowGenerator).

Ejemplo componente tRowGenerator para producir datos de test

En concreto, hemos creado dos tablas iguales (con la misma estructura). Una con particionado por año en un campo de la clave del tipo fecha, y la segunda con la misma estructura sin particionado. En ambas tablas tenemos un millon de registros repartidos entre los años 2008 y 2017. Una vez creadas las tablas, utilizamos la sentencia de MySql  explain y explain partitions para analizar como se ejecutaran las sentencias sql (analisis de indices). Ademas, comprobamos tiempos de ejecución con diferentes tipos de sentencia SQL. Los resultados son mas que obvios:

Analisis tiempos ejecucion

En las mayoria de los casos se obtiene un mejor tiempo de respuesta de la tabla particionada, y en los casos en los que no, el tiempo de ejecución es practicamente igual al de la tabla no particionada (diferencias de milesimas de segundo). Observar cuando indicamos condiciones fuera del indice (ultima sentencia SQL), como los tiempos de respuesta son aun mas relevantes. Y siempre conforme vamos leyendo de mas particiones (por incluir mas años en la condición), el tiempo de respuesta de la consulta entre una y otra tabla se va acercando.

Particionado de la tabla de hechos de Ventas en nuestro DW

Para nuestro DW, hemos decidir implementar un particionado del tipo LIST. Como os habreis podido dar cuenta, seguramente los particionados por RANGE o por LIST son los mas adecuados para un sistema de Business Intelligence pues nos van a permitir de una forma facil reducir el tamaño de las casi siempre monstruosas tablas de hechos, de una forma fácil y automática.

Vamos a crear 10 particiones y repartiremos los diferentes años en cada una de las particiones, empezando por 2005 –> Particion 1, 2006 –> Particion 2, 2007 –> Particion 3, …, 2013 –> Particion 9, 2014 –> Partición 10. A partir de 2015, volvemos a asignar cada año a las particiones y así hasta el año 2024 (tiempo de sobra para lo que seguramente será la vida de nuestro DW).

Como el campo año no lo tenemos en el diseño físico de la tabla de hechos, aplicaremos sobre la columna fecha la funcion YEAR para realizar el particionado. La sentencia para la creación de la tabla de hechos quedaría algo parecido a esto:

CREATE  TABLE IF NOT EXISTS `enobi`.`dwh_ventas` (
`fecha_id` DATE NOT NULL ,
`material_id` INT(11) NOT NULL ,
`cliente_id` INT(11) NOT NULL ,
`centro_id` INT(11) NOT NULL ,
`promocion_id` INT(11) NOT NULL ,
`pedido_id` INT(11) NOT NULL ,
`unidades` FLOAT NULL DEFAULT NULL COMMENT 'Unidades Vendidas' ,
`litros` FLOAT NULL DEFAULT NULL COMMENT 'Equivalencia en litros de las unidades vendidas' ,
`precio` FLOAT NULL DEFAULT NULL COMMENT 'Precio Unitario' ,
`coste_unit` FLOAT NULL DEFAULT NULL COMMENT 'Coste Unitario del Producto')
PARTITION BY LIST(YEAR(fecha_id)) (
    PARTITION p1 VALUES IN (2005,2015),
    PARTITION p2 VALUES IN (2006,2016),
    ..................................
    PARTITION p9 VALUES IN (2013,2023),
    PARTITION p10 VALUES IN (2014,2024)
);

Con este forma de definir el particionado estamos sacando ademas partido de la optimización de lo que en MySql llaman “Partitioning Pruning” ( ver aqui ). El concepto es relativamente simple y puede describirse como “No recorras las particiones donde no puede haber valores que coincidan con lo que estamos buscando”. De esta forma, los procesos de lectura serán mucho mas rápidos.

A continuación, veremos en la siguiente entrada del Blog los ajustes de diseño de nuestro modelo físico en la tabla de hechos (teniendo en cuenta todo lo visto referente al particionado) y los procesos utilizando la ETL Talend para su llenado.

Posted in Bases de Datos, Business Intelligence, Mysql, OpenSource | 17 Comments »

Ejemplo Talend para conectarnos a Sap

Posted by Roberto Espinosa en 13 enero 2010


(Read in English Language here)

Antes de continuar con el proceso ETL para la carga de la tabla de Hechos de ventas, vamos a hacer una pausa para ver como utilizar Talend para conectarnos a Sap utilizando los componentes tSapConnection, tSapInput y tSapOutput. En nuestro proyecto, podriamos haber utilizado estos componentes para hacer la lectura de datos desde el ERP (pero hemos utilizado el componente tOracleInput para leer directamente de la base de datos).

Aunque el componente Sap de Talend es libre, para poder utilizarlo hace falta una librería Java proporcionada por Sap (sapjco.jar), que tendremos que tener instalada en nuestro sistema. Esta libreria solo se puede descargar de Sap si somos usuarios registrados (http://service.sap.com/connectors). La versión del sapjco que hemos instalado es la 2.1.8 (hay una posterior, la 3.0.4, pero con esa no funciona Talend).

La forma de instalar la libreria sapjco.jar es la siguiente:

  • Una vez descargado el correspondiente fichero (según la versión de sistema operativo que estemos utilizando), lo descomprimimos en un directorio de nuestra elección. La prueba, en nuestro caso, la hemos realizado utilizando Windows Vista.
  • Si tenemos una versión mas antigua de la dll librfc32.dll en el directorio de windows system32, la sustituimos con la que viene de Sap.
  • Incluimos el directorio de instalación en la variable de entorno PATH (en nuestro caso c:\sapjco ).
  • Finalmente, añadimos a la variable de entorno CLASSPATH el fichero sapjco.jar con su ruta completa (por ejemplo, CLASSPATH=c:\sapjco\sapjco.jar ).

A continuación, instalamos la libreria en el directorio de clases de Talend y comprobamos que este correctamente instalada. Para ello, dejamos caer el fichero sapjco.jar en el directorio <directorio_instalacion_talend>\lib\java. A continuación abrimos Talend, y en la pestaña Modules, comprobamos que aparezca el modulo sapjco.jar correctamente instalado (tal y como vemos en la imagen).

Finalmente, vamos a ver un ejemplos práctico de conexión a Sap para recuperar información, utilizando modulos de función (RFC) implementados en Sap y a las que podremos acceder desde Talend (esto es realmente lo que nos permite hacer el componente, acceder a Sap a traves de sus RFC´s y BAPIS).

Las RFC´s (Remote Function Call) son la base para la comunicación entre Sap y cualquier sistema externo. Son componentes de programación (un programa Abap, por ejemplo), encapsulado en una función, con su correspondiente interfaz de entrada y salida de datos, que ademas puede ser llamado desde dentro del propio Sap, o de forma remota si esta habilitada la opción “Modulo Acceso Remoto” (tal y como vemos en la imagen inferior). En este caso, es cuando podremos llamarlas, por ejemplo, desde Talend.

Definicion de la RFC "RFC_READ_TABLE" en Sap

Sap tiene programadas multitud de RFC´s de forma estandar, y ademas nosotros podremos construir las nuestras con codigo que realize las tareas que deseemos. Ademas, existe otro tipo de RFC´s dentro de sap, las llamadas BAPIS, que incluyen reglas adicionales integradas con el funcionamiento de la aplicación Sap (por ejemplo, la BAPI BAPI_SALESORDER_CREATEFROMDAT2 nos permite la creación de un pedido de ventas a partir de los datos que pasamos a la función en la interfaz).

Ejemplo: Lectura del contenido de una tabla utilizando la RFC “RFC_READ_TABLE”.

Vamos a realizar un Job en Talend para leer el contenido de una tabla de Sap, en concreto, vamos a recuperar todos los materiales que son de un determinado tipo. El Job completo tendrá la siguiente estructura:

En Talend utilizaremos el componente tSapInput para hacer la llamada a la RFC de Sap. Para poder hacer esto, tendremos que conocer cual es la interfaz que tiene definida esta en Sap para saber que parametros le podemos pasar y que resultados y en que tipos de estructuras de datos podemos recibir. En la transacción SE37 de Sap podemos ver como estan definidos los modulos de función, y ver como se va a realizar la comunicación con dicho componente.

Por ejemplo, en modulo de función RFC_READ_TABLE (como vemos en la imagen inferior), tiene 5 parametros de entrada, definidos en la pestaña IMPORT. Los que vamos a utilizar en nuestro ejemplo serán: QUERY_TABLE (la tabla de la que queremos obtener información), DELIMITER (delimitador para los datos obtenidos).

Definicion RFC en Sap - Import (parametros Entrada)

Existe tambien la pestaña EXPORT, en la que podriamos ver que parametros de salida tenemos (para el caso de variables o estructuras simples). En el caso de trabajar con tablas, estas aparecerán en la pestaña TABLAS. Las tablas son estructuras complejas de Sap (como una matriz de datos). Las tablas se pueden utilizar tanto para recibir datos de la RFC como para pasarselos. En nuestro ejemplo, utilizaremos la tabla DATA para recibir los registros recuperados de la base de datos.

Definicion RFC en Sap - Tables (parametros Entrada/Salida)

A continuación, volveremos a Talend y completaremos los diferentes campos del componente:

  • Cliente: mandante de Sap del cual recuperaremos los datos.
  • Userid: usuario para la conexión. Habrá de tener permisos para ejecutar la RFC y para acceder a los datos deseados.
  • Password: contraseña.
  • Language: lenguaje de conexión.
  • Host Name: Host donde esta ubicado el servidor Sap.
  • System Number: numero de instancia Sap del servidor (normalmente la 00 donde solo hay un servidor).
  • Function name: Nombre de la RFC a la cual vamos a invocar.

Ejemplo de Uso de componente tSapInput

  • Initialize input: inicializacion de los parametros de entrada. Son los valores que vamos a pasar al módulo de función. En nuestro caso, observar que hemos pasado valores simples (variables) y también hemos pasado valores a algunas de las tablas.
    • Input single: los parametros “QUERY_TABLE” y “DELIMITER” son del tipo input_single (entrada sencilla) y los inicializamos pasandoles un valor, en concreto el nombre de la tabla que queremos leer y el delimitador a utilizar.
    • Table input: introducimos valores en dos tablas. En la tabla OPTIONS, en el campo TEXT, indicamos una condición para restringir la lectura de datos (como si fuera una condición del where). En la tabla FIELDS, en el campo FIELDNAME, le indicamos a Sap que campos de la tabla son los que queremos recuperar (en este caso el código del material, su tipo y su linea de producto). De esta forma, limitamos tanto el número de registros devueltos, como los campos obtenidos (no queremos ver todos los campos de cada registro de esta tabla). Observar como para indicar varios valores para el campo FIELDNAME de la tabla FIELDS, hemos puesto varias entradas separadas por coma.
  • Outputs: definición de las estructuras donde vamos a gestionar los datos devueltos por Sap. Aquí indicaremos el tipo de valor recuperado (table_output para cuando el resultado sea una tabla), el nombre de la tabla en Sap (en el campo TableName (Structure Name) y el nombre del Schema (será un nombre para el flujo de datos, podemos ponerle cualquiera).  En nuestro ejemplo, estamos leyendo de la tabla de Sap DATA, que es una tabla de registros, y cada registro tiene un unico campo que se llama WA. Los pasos a seguir en esta sección para una correcta definición de intercambio de datos son los siguientes:
  • Creamos en primer lugar el flujo de salida pulsado el boton del signo “+”. Pulsado en Schema le daremos un nombre a este flujo (registros_devueltos en nuestro ejemplo) e indicaremos los campos que componen la estructura de salida del componente tSapInput. En este caso, solo tendremos un campo, llamado WA (tal y como vemos en la imagen), que corresponde con el campo de la tabla DATA de Sap.

Definicion de la estructura de salida "registros_devueltos"

  • A continuación, habrá que asociar esta columna a la componente de Sap donde se recuperan los datos. Para ello pulsaremos en el campo Mapping,y se nos abrira una nueva ventana. Aquí nos aparecera el flujo de datos definido en el paso anterior mas  el campo Schema XPatchQuerys, que es el que nos permite Mapear el campo de Talend con el campo del diccionario de datos de Sap, y así poder recibir los datos de Sap correctamente (los valores introducidos en XPatchQuerys deberán ir entre comillas dobles, utilizando el simbolo “).
Mapeo entre la estructura de salida en Talend y la de Sap

Con este ejemplo, hemos podido de una forma relativamente sencilla recuperar datos de Sap en un único control. Conociendo los diferentes RFC´s existentes en Sap y las Bapis, seguramente podremos realizar tareas mucho mas complejas y aprovechar funcionalidades que ya estan definidas en Sap. Incluso puede ser una forma de realizar interfases con Sap utilizando estos componentes ya definidos y paquetizados.

Para ver en detalle como hemos definido cada componente, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Posted in ETL, OpenSource, Sap, Talend | 1 Comment »

13.3. ETL Talend Dimension Cliente.Tipos de Mapeo para lookup. Gestión de SCD (Dimensiones lentamente cambiantes).

Posted by Roberto Espinosa en 12 enero 2010


El proyecto ENOBI sigue avanzando en la parte mas compleja y que seguramente mas recursos consumira, los procesos ETL. Como ya indicamos, en algunos proyectos puede suponer hasta el 80% del tiempo de implantación. Y no solo eso, el que los procesos esten desarrollados con la suficiente consistencia, rigor, calidad, etc. va a determinar el exito posterior del proyecto y que la explotación del sistema de Business Intelligence sea una realidad. Seguramente si los procesos de extraccion, transformación y carga no esta bien desarrollados, eso pueda acabar afectando al uso correcto del sistema

Para concluir los procesos ETL de las Dimensiones del proyecto, vamos a abordar la carga de la Dimensión Cliente, que incluye todos los atributos por los que analizaremos a nuestros clientes. Vamos a obviar la publicación de los proceso de carga de la Dimensión Logistica y Promoción, pues son muy sencillos y no aportan nada nuevo.

Al detallar los procesos de la carga de la Dimension Cliente, entraremos en detalle en las diferente formas que tiene Talend de realizar los mapeos de tablas de lookup. Es decir, cuando tenemos un valor para el que tenemos que recuperar un valor adicional en otra tabla de la base de datos (por ejemplo, para un código de cliente recuperar su nombre; para la familia de producto, introducida en el maestro de materiales, recuperar de la tabla de parametrización su descripción, etc ), ver de que maneras Talend nos permite realizar dicha consulta.

Igualmente, veremos mas ejemplos de utilización de Java dentro de los componentes, y la potencia que ello nos proporciona (aunque nos obliga a tener conocimientos amplios de este lenguaje).

Para completar el ejemplo, aunque en realidad en nuestra dimensión no vamos a gestionar las dimensiones lentamente cambiantes (SCD Slowly Change Dimension), vamos a incluir un ejemplo de tratamiento de este tipo de dimensiones, utilizando el componente que tiene Talend para ese cometido, que implementa el algoritmo correspondiente para su procesamiento (elemento tMySQLSCD).

Proceso ETL en Talend completo para la dimensión Cliente

Tal y como vemos en la imagen anterior, los pasos del proceso ETL para llenar la Dimensión Cliente serán los siguientes:

1) Ejecución de un prejob que  lanzará un generara en el log un mensaje de inicio del proceso y un logCatcher (para recoger las excepciones Java o errores en el proceso).  Este generará el envio de un email de aviso en el caso de que se produzca algún problema en cualquier paso del job.

  • Lanzador Prejob (componente tPrejob): sirve para realizar el lanzamiento de un pretrabajo, anterior al proceso principal.
  • Mensaje Log Inicio (componente tWarn): genera un mensaje de log indicando que se comienza la ejecución del job.
  • Control Errores (componente tLogCatcher): activamos el componente que “escuchara” durante toda la ejecución del job, esperando que se produzca algún tipo de error. En ese momento se activara para recuperar el error y pasarlo al componente siguiente para el envio de un email de notificación.
  • tFlowtoIterate: convertimos el flujo de registros de log a una iteración para poder realizar el envio del correo electrónico.
  • Envio Email Notif (componente tSendMail): generamos el envio de un email de notificación de errores, incluyendo el paso donde se paro el proceso, y el mesaje de error generado. Es una forma de avisar que ha fallado algo en el proceso. En la siguiente imagen tenéis un ejemplo de un email de notificación de error enviado a una cuenta de gmail.

Ejemplo envio Email de notificacion de error

2) Recuperamos del maestro de cliente en el ERP, todos los clientes existentes en el fichero maestro (con el componente tOracleInput).

Job DimCliente - Lectura Maestro Clientes Sap

3) Realizamos una sustitución de valores erroneos o en blanco en los registros seleccionados según los criterios establecidos (con el componente tReplace), como ya vimos en los procesos ETL de la Dimensión Producto.

4) Completamos el mapeo de dimensión Cliente, llenando el resto de campos que provienen de otras tablas en la base de datos (los campos de lookup),  con sus correspondientes consultas SQL (utilizando el componente tMap).

Job DimCliente - Mapeo Cliente

Podeis observar como al realizar el mapeo del maestro de clientes con las correspondientes tablas de lookup (donde estan el resto de campos y descripciones), hemos estado utilizado sintaxis del lenguaje Java. Esto nos da mayor potencia a las transformaciones y nos permitirán hacer casi de todo, aunque tendremos que conocer bien Java, sus tipos de datos, la forma de convertirlos. Algunos ejemplos son:

  • Relational.ISNULL(row2.psofg)?”SIN ASIGNAR”:row2.psofg : el operador Java que nos permite asignar un valor u otro a un resultado segun si se cumple una condición o no. En este caso, si row2.psofg es nulo, al resultado se le dara el valor “SIN ASIGNAR”. En caso contrario, se le dara el valor del campo row.psofg.
  • StringHandling.UPCASE(row2.ort01 ) : es un metodo de la clase StringHandling, que nos permite pasar una cadena a mayúsculas.
  • Long.valueOf(StringHandling.RIGHT(row2.konzs,10)) : utilizamos el metodo RIGHT de la clase StringHandling para obtener una subcadena, y el resultado lo convertimos al tipo de datos numérico Long con el metodo de este valueOf.

Tipos de Mapeo en el componente tMap

Cuando utilizamos el componente tMap para completar los datos de nuestro flujo con valores proveniente de otras tablas (u otros ficheros u origenes de datos), vemos que siempre tenemos un flujo Main (en nuestro caso con los datos que llegan del fichero maestro de Sap) y uno o varios flujos lookup (lo podeis observar en la imagen anterior). Estos flujos de lookup nos permiten “rellenar” valores que residen en otro lugar, buscandolos por una clave determinada. La clave puede venir del propio flujo Main o de otros flujos de lookup (de forma anidada). Pensar por elemplo el caso de recuperar, a partir del código de cliente, un dato asociado (como el comercial asignado). Posteriormente, para el código de comercial, busco en otro lookup, utilizando ese código, el nombre de dicho comercial.

Los flujos de lookup  pueden ser de tres tipos, como vemos en la imagen. Veamos en que consiste cada uno de ellos:

  • Load Once: la rama de lookup del componente tMap se ejecuta una unica vez y siempre antes de la ejecución del componente tMap. En este caso, la ejecución unica de la rama de lookup ha de generar todos los registros para poder buscar valores en ellos (será una carga de todo un fichero maestro, por ejemplo). Si los datos para el lookup tuvieran muchos registros, podría ser un cuello de botella para el proceso, e igual convendría utilizar el tipo Reload at each row.
  • Reload at each row: la rama del lookup se ejecuta para cada registro que llegan del flujo Main. Este tipo de mapeo nos permite ejecutar la consulta de lookup para un valor concreto (podremos pasar un valor unico que sera el que realmente busquemos. Ver ejemplo posterior de este tipo de lookup). Puede tener sentido utilizarlo con tablas de lookup muy grandes que no tiene sentido gestionar en una consulta de atributos (pensar en una tabla maestro de clientes de millones de registros).
  • Reload at each row (cache): idem al anterior, pero los registros que se van recuperando se guardan en la cache. En las siguientes consultas, se mira primero en la cache, y si ya existe, no se lanza el proceso. En el caso de que no exista, entonces si se relanza la ejecución para buscar los valores que faltan.

En este caso, en todos los flujos de lookup hemos utilizado el tipo Load Once (mas adelante veremos un ejemplo de uso Reload at each row).

5) Verificamos que realmente haya modificaciones con los datos existentes en la base de datos del DW (también con el componente tMap), y para los registros que si tienen modificaciones (o son nuevos registros), realizamos la actualización. En principio, no vamos a realizar gestión de Dimensiones Lentamente Cambiantes, sino que siempre tendremos la foto de los datos tal y como están los ficheros maestros en el momento actual.

Job DimCliente - Verificacion Modificaciones

Para discriminar el paso de registros al paso siguiente de actualización en la base de datos del DW, se ejecuta la siguiente expresión condicional (vemos que es 100% lenguaje Java). La expresión va comparando campo por campo entre los valores recuperados de nuestro ERP y los existentes en la tabla de la dimensión cliente DWD_CLIENTE.

!row8.cliente_desc.equals(row10.cliente_desc) ||
row8.agrupador_id!=row10.agrupador_id||
!row8.agrupador_desc.equals(row10.agrupador_desc)||
!row8.comercial_id.equals(row10.comercial_id)||
row8.canal_id!=row10.canal_id||
!row8.canal_desc.equals(row10.canal_desc)||
row8.tipocl_id!=row10.tipocl_id||
!row8.tipocl_desc.equals(row10.tipocl_desc)||
!row8.pais_id.equals(row10.pais_id)||
!row8.region_id.equals(row10.region_id)||
!row8.provincia_id.equals(row10.provincia_id)||
!row8.cpostal_id.equals(row10.cpostal_id)||
!row8.poblacion_id.equals(row10.poblacion_id)||
!row8.nielsen_id.equals(row10.nielsen_id)||
row8.clubvinos_id!=row10.clubvinos_id

Cuando el lookup lo ejecutamos para cada registro que llega al control tMap (en este caso utilizamos el tipo Reload at each row), la sentencia SQL que se ejecuta en el flujo de lookup es la siguiente (observa que en la condición del where utilizamos una variable que hemos generado en el control tMap, y será la que contiene el código de cada cliente que queremos verificar). En este caso, el paso asociado al flujo lookup se ejecuta una vez para cada registro que llegue al componente tMap y siempre posteriormente:

"SELECT dwd_cliente.cliente_id,
 dwd_cliente.cliente_desc,
 dwd_cliente.agrupador_id,
 dwd_cliente.agrupador_desc,
 dwd_cliente.comercial_id,
 dwd_cliente.canal_id,
 dwd_cliente.canal_desc,
 dwd_cliente.tipocl_id,
 dwd_cliente.tipocl_desc,
 dwd_cliente.pais_id,
 dwd_cliente.region_id,
 dwd_cliente.provincia_id,
 dwd_cliente.cpostal_id,
 dwd_cliente.poblacion_id,
 dwd_cliente.nielsen_id,
 dwd_cliente.clubvinos_id
FROM    dwd_cliente
WHERE cliente_id = " + (globalMap.get("var.cliente_id"))

En este caso, la sentecia SQL (y el correspondiente componente que la contiene), se ejecutara una vez por cada registro que llega por el flujo Main al componente tMap. Y la sentencia SQL solo recuperara un registro de la base de datos, aunque se estará ejecutando continuamente (le hemos pasado con la variable var.cliente_id el valor a buscar).

6) Concluimos el proceso guardándonos en el log el correspondiente mensaje de finalización correcta del proceso, con el componente MENSAJE_LOG_FIN del tipo tWarn.

TRATAMIENTO DE LAS DIMENSIONES LENTAMENTE CAMBIANTES

Como ejemplo y para estudiar su funcionamiento, incluimos un paso para la gestión de las dimensiones lentamente cambiantes (que se grabaran en una tabla paralela a la de la dimensión cliente). El tipo de componente en Talend para realizar esto será el tMySqlSCD.

Para entender que son exactamente las dimensiones lentamente cambiantes, os recomiendo un poco de literatura. En el blog Business Intelligence Facil, se explican de una forma muy clara que son y como gestionarlas ( ver aquí ), así como de las claves subrogadas. Tambien Jopep Curto nos da muy buenas definiciones en su blog.

Una vez tengamos clara la teoria, vamos a ver como aplicarlo a la practica utilizando los componentes de Talend.

Componente para gestion dimensión lentamente cambiante

El algoritmo de la dimensión SCD se gestiona con el correspondiente editor, tal y como vemos en la imagen siguiente:

Editor Componente SCD

Para utilizar el editor, se indica un nombre de tabla existente en la base de datos, que sera la tabla para la cual vamos a gestionar la SCD (ha de incluir los campos necesarios para la gestión de versiones según lo indicado en el editor SCD). El control recibirá un flujo con los registros a procesar contra la tabla indicada. En el editor SCD indicamos como se va a comportar la actualización contra la tabla según los diferentes tipos de atributos.

Los controles que forman el editor de dimensiones SCD son los siguientes:

  • Unused: aquí apareceran todos los campos disponibles para utilizar en el editor SCD. Desde este sitio iremos arastrando los campos al resto de sitios.
  • Source keys: son las claves principales de los datos (la clave en el sistema original). Para un maestro de clientes, aquí indicaremos la clave que identifica a este en el sistema origen.
  • Surrogate keys: es el nombre que le damos a la clave subrogada. Es decir, aquella clave inventada que nos va a permitir gestionar versiones de nuestros datos en el DW.
  • Type 0 fields: aqui indicaremos los campos que son irrelevantes para los cambios. Si aqui metemos, por ejemplo, el campo nombre, cualquier cambio en el sistema origen con respecto a los datos existentes en el DW no se va a tener en cuenta (se ignorará).
  • Type 1 fields: aquí indicaremos los campos para los que, cuando haya un cambio, se machacará el valor existente con el valor recibido, pero sin gestionar versionado.
  • Type 2 fields: aquí indicaremos los campos para los que queremos que, cuando haya un cambio, se produzca un nuevo registro en la tabla (con una nueva subrogated key). Es decir, aquí pondremos los campos que son dimensiones lentamente cambiantes y para los que queremos gestionar un versionado completo.
  • Versioning: aqui indicamos los valores para el versionado (fecha de inicio y fecha de fin), y si queremos llevar un control de numero de versión o flags de registro activo (requeriran campos adicionales en la tabla para este cometido).
  • Type 3 fields: aquí indicaremos los campos para los que queremos guardarnos una versión anterior del valor (es decir, cuando haya un cambio, siempre tendremos dos versiones, la ultima y la anterior).

Para concluir la explicación de las dimensiones SCD, observar las diferencias de catalogo entre el flujo de entrada y el flujo de salida (en el de salida se han incluido atributos propios para la gestión de la dimension lentamente cambiante, gestión de versiones, fechas de validez, etc):

Esquema de traspaso de Datos en Dimensiones SCD

Para entender mejor el ejemplo, observar las entradas en MySql de la tabla DWD_CLIENTE_SCD. Observar como el cliente tuvo un cambio en su nombre y se generó un  nuevo registro en la tabla con una nueva clave subrogada. Todo se ha realizado de una forma automatica por el componente de Talend, sin tener que gestionar nosotros nada.

Registros para el mismo cliente en MySql con Subrogated key

Finalmente, observar que hemos utilizado un componente nuevo para duplicar un flujo de datos (el componente tReplicate). Este componente nos permite a partir de un unico flujo, generar tantos flujos como sea necesarios (todos serán iguales y procesarán los mismos registros).

Duplicacion de flujos de datos con el componente tReplicate

Para ver en detalle como hemos definido cada componente del Job, podeís acceder a la documentación HTML completa generada por Talend aquí. Podeis descargaros el fichero zip que contiene dicha documentación aquí.

Posted in Business Intelligence, ETL, OpenSource, Talend | 1 Comment »

 
A %d blogueros les gusta esto: