El Rincon del BI

Descubriendo el Business Intelligence…

Paso de parametros y operaciones dinamicas en una transformación de PDI.

Posted by Roberto Espinosa en 28 mayo 2010


Antes de continuar con el llenado de las tablas de hechos, vamos a ver un ejemplo de una transformación con paso de parametros, y como con dichos valores, podemos interactuar de forma dinámica contra la base de datos. Igualmente, veremos la forma de escribir mensajes de log o de abortar una transformación cuando no se cumplan determinadas condiciones.

Paso de parametros al ejecutar la transformacion

El objetivo de la transformación es el siguiente:

Pasaremos como parametros una tabla de bd de entrada, una tabla de bd de salida, un texto con las condiciones del where a aplicar en la lectura de la tabla de entrada y el modo de ejecución del proceso. Con dichos valores, la transformación realizará las siguientes acciones:

  • Comprobación de parametros: todos los parametros han de tener valores. En el caso que no se indiquen, se cancelara la transformación y se mandara un mensaje al log de ejecución.
  • Se prepara la sentencia SQL para borrar todos los registros existentes en la tabla  DESTINO. A continuación, se ejecuta dicha sentencia (solo en ejecución en modo REAL). Si hay errores, se pasa el mensaje al log.
  • A continuación, se realiza la lectura de la tabla origen indicada en los parámetros, añadiendo las correspondientes condiciones del where.
  • Como paso final, todos los registros recuperados de la tabla origen se insertan en la tabla destino (si es en modo REAL) o se descargan los datos a un fichero (en modo TEST). También se gestionan los errores en la carga de la tabla destino. Adenas, en todos los pasos de actualización de tablas hemos configurado el control de errores (Define Error Handling), que nos permite en el caso de errores pasar un mensaje al log (vimos la forma de configurarlo también en la entrada anterior del blog).

Transformacion con Paso Parametros

Vamos a ver un poco mas en detalle los pasos utilizados y algunas cosas interesantes que nos pueden ser utiles para el tratamiento de determinadas casuísticas:

  • Uso de formulas para validar condiciones: en la entrada anterior del blog vimos como utilizar el step Formula para hacer calculos sobre los valores de los campos. También lo podemos utilizar para comprobar que se cumplan determinadas condiciones (como que los valores de los parametros pasados a la transformación tengan un valor). En nuestro caso, con las formulas calculamos el valor de un campo llamado CORRECTO que tendra el valor Y si se han pasado los parámetros correctamente, o el valor N en caso contrario. En el paso anterior a este hemos sustituido con un control del tipo If field value is null el valor nulo de los parametros por el texto “VACIO” para hacer más fácil la comprobación. La formula será la siguiente:

IF (OR([TORIGEN]=”VACIO” ; [TDESTINO]=”VACIO” ; [WORIGEN] = “VACIO”) ; “N” ; “Y”)

  • Escritura de mensajes de log y cancelación de procesos: en el caso de que los parametros pasados a la transformación no esten bien definidos, se muestra un mensaje de log y se aborta la ejecución de la transformación. Para ello, utilizamos los pasos del tipo Write to log y el del tipo Abort. En este caso, los pasos se ejecutan desde un Switch / Case, donde comprobamos el valor del campo CORRECTO, que hemos preparado en la formula anterior. Como ejemplo del texto que hemos sacado en log en esta situación, el siguiente:

2010/05/28 16:49:52 – ESCRIBO LOG 2.0 -
2010/05/28 16:49:52 – ESCRIBO LOG 2.0 – ————> Linenr 1——————————
2010/05/28 16:49:52 – ESCRIBO LOG 2.0 – MENSAJE = REVISE PARAMETROS TRANSFORMACION:TABLA ORIGEN: VACIO,TABLA DESTINO:VACIO
2010/05/28 16:49:52 – ESCRIBO LOG 2.0 -
2010/05/28 16:49:52 – ESCRIBO LOG 2.0 – ====================

  • Ejecución de sentencias SQL dinámicas: en el paso EJECUTA_SQL_BORRADO hemos utilizado un step del tipo Execute SQL script. Este paso nos permite pasarle una sentencia SQL (cuyo contenido hemos construido de forma dinámica en el paso anterior de la transformación con un paso del tipo Formula, y dejado en una variable del tipo texto). Otra forma de ejecutar sentencias sql construidas en tiempo de ejecución es el paso Execute row SQL script, donde podemos utilizar tanto parametros o variables de la transformación, como campos del flujo de datos, tal y como vimos en la entrada anterior del blog (en la imagen se explica su funcionamiento).

Sentecias SQL Dinámicas

  • Uso de table input con nombres de tabla, campos o condiciones variables: con este paso recuperamos los registros de la tabla de base de datos especificada en los parametros de la transformación. Tal y como veis en la imagen, sustituimos el nombre de tabla y la condición del where por las correspondientes variables. Estas determinan el comportamiento de la sentencia  sql y que registros son recuperados de la base de datos. Ademas, no estamos especificando los campos a recuperar en la sentencia sql (hemos indicado el valor * ).

Table Input con uso de variables

  • Uso de table output con nombre de tabla variable: los registros recuperados en el paso anterior son grabados en base de datos, pero esta vez en la tabla especificada en los parametros de la transformación como tabla de salida. Podeis ver como hemos configurado el control para indicar el nombre de la tabla a partir del contenido del parámetro. Igualmente, hemos desmarcado el flag “Specify database fields” para no indicar los campos que queremos insertar, y que estos se recuperen del flujo de datos. La lista de campos a insertar aparece vacía, como podeís apreciar en la imagen.

Table Output con nombre de tabla en variable y sin especificar campos

En ninguno de los pasos Text File Output ni Table Output hemos indicado los campos con los que estamos trabajando (como hemos visto). Esto nos permite olvidarnos del catalogo de campos, y que todo sea gestionado de forma dinámica (en tiempo de ejecución). Aunque tendremos la restricción, en el caso del table output, que los campos destino (de la tabla donde vamos a insertar la información) han de tener las mismas propiedades que los origen (y el mismo número de campos). Para el caso de los ficheros de texto, no habrá ningun problema, pues se recuperan del metadata los nombres de los campos y el contenido del fichero se construira de forma dinámica (tal y como veis en la imagen). Como hemos configurado el step para que genere una linea dentro del fichero con los nombres de los campos, la primera linea del fichero incluye esta información (linea de cabeceras). Teniendo en cuenta esta restricción, podremos utilizar la transformación para cualquier tabla origen/destino que cumpla ese requisito.

Estructura de fichero de texto generado en el Text File Output

Para indicar los campos que queremos recuperar realmente, podiamos haber añadido otro parametro más a la transformación para indicar los campos que queremos que se lean (e introducirlos en la sentencia SQL de lectura). Este parametro consistiria en una lista de nombres de campo separados por coma. Esto nos permite introducir el uso de otros tres pasos o steps de los que tenemos disponibles en kettle: Split Fields, Split Fields to Rows y Row Flattener.

Uso de Split Fields

Partimos de un campo cuyo contenido tiene la siguiente estructura: “valor1, valor2, valor3, valor4, valor5″. Cada valor representa el nombre de un campo de la tabla. Tenemos dos opciones para normalizar o procesar el contenido del campo:

  • Split Fields: el contenido de un campo lo multiplico en n campos, indicando un caracter que determina donde “cortar” cada uno de los nuevos campos a partir del original. Seguimos teniendo un único registro o fila, pero que ha pasado de tener 1 campo a n.
  • Split Fields to Row: el contenido de un campo lo multiplico en n registros, indicando igualmente el caracter de delimitación. Pasamos de 1 registro o filas a n.

Configuración de los pasos Split Fields

Como paso final (despues del Split Fields to Row), podriamos utilizar el paso Row Flattener para juntar los diferentes registros, en uno único (sería equivalente a utilizar el Split Fields, pero  utilizando dos pasos).

Os dejo el link al  fichero xml de la transformación por si quereis ver en detalle los pasos aquí descritos. El ejemplo se ha centrado en la lectura e inserción en tablas de bd indicadas de forma dinámica, pero lo podiamos haber utilizar para cualquier otro cometido donde estemos utilizando variables ( y que los parametros indicados a la transformación configuran el valor de estas variables y su comportamiento).

About these ads

3 comentarios to “Paso de parametros y operaciones dinamicas en una transformación de PDI.”

  1. Arcel said

    Excelente trabajo, tengo un pequeño problema, le doy al link para descargarme el ejemplo, me aparece el xml y lo guardo utilizando notepad ++ pero cuando intento abrirlo con Kettle me da el siguiente error was not recognized as a kettle file type
    Alguna recomendación? Gracias!!

  2. Arcel said

    Retiro la pregunta, ya vi como bastante sencillo a travez de chrome!!

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 172 seguidores

%d personas les gusta esto: