(DRAFT)_Grupo_Santander_-_PowerCenter_8.x_-_Normativa_Desarrollo_v.1.0_(DRAFT).pdf

PowerCenter 8.x: Normativa de Desarrollo v.1.0

PowerCenter 8.x – Normativa de Desarrollo

Índice 1. HISTORIAL DE CAMBIOS ............................................................................................................... 5 2. INTRODUCCIÓN .............................................................................................................................. 6 3. NORMAS DE DISEÑO Y DESARROLLO ........................................................................................ 7 3.1. ARQUITECTURA DE POWERCENTER .............................................................................................. 7 3.2. TRANSFORMACIONES BÁSICAS...................................................................................................... 9 3.2.1. Source Qualifier ................................................................................................................ 9 3.2.1.1. Ficha Técnica....................................................................................................................... 9 3.2.1.2. Propósito.............................................................................................................................. 9 3.2.1.3. Parametrización ................................................................................................................... 9 3.2.1.4. Best Practices .................................................................................................................... 10

3.2.2. Expression ...................................................................................................................... 11 3.2.2.1. Ficha Técnica..................................................................................................................... 11 3.2.2.2. Propósito............................................................................................................................ 11 3.2.2.3. Definición de Expresiones.................................................................................................. 13 3.2.2.4. Funciones Disponibles ....................................................................................................... 16 3.2.2.5. Parametrización ................................................................................................................. 19 3.2.2.6. Best Practices .................................................................................................................... 19 3.2.2.7. Uso de Puertos de Tipo Variable ....................................................................................... 20

3.2.3. Filter ................................................................................................................................ 24 3.2.3.1. Ficha Técnica..................................................................................................................... 24 3.2.3.2. Propósito............................................................................................................................ 25 3.2.3.3. Parametrización ................................................................................................................. 25 3.2.3.4. Best Practices .................................................................................................................... 25

3.2.4. Sorter .............................................................................................................................. 26 3.2.4.1. Ficha Técnica..................................................................................................................... 26 3.2.4.2. Propósito............................................................................................................................ 26 3.2.4.3. Parametrización ................................................................................................................. 28 3.2.4.4. Best Practices .................................................................................................................... 28 3.2.4.5. Cálculo de Tamaño de Caches .......................................................................................... 28 3.2.4.6. Eliminación de Registros Duplicados ................................................................................. 30

3.2.5. Aggregator ...................................................................................................................... 31 3.2.5.1. Ficha Técnica..................................................................................................................... 31 3.2.5.2. Propósito............................................................................................................................ 32 3.2.5.3. Parametrización ................................................................................................................. 34 3.2.5.4. Best Practices .................................................................................................................... 35 3.2.5.5. Cálculo de Tamaño de Caches .......................................................................................... 35 3.2.5.6. Uso de Puertos de Tipo Variable ....................................................................................... 38 3.2.5.7. Sorted Input ....................................................................................................................... 38 3.2.5.8. Eliminación de Registros Duplicados ................................................................................. 40

3.2.6. Joiner .............................................................................................................................. 41 3.2.6.1. Ficha Técnica..................................................................................................................... 41 3.2.6.2. Propósito............................................................................................................................ 42 3.2.6.3. Tipos de Cruce................................................................................................................... 42 3.2.6.4. Parametrización ................................................................................................................. 46 3.2.6.5. Best Practices .................................................................................................................... 47 3.2.6.6. Cálculo de Tamaño de Caches .......................................................................................... 48 3.2.6.7. Sorted Input ....................................................................................................................... 50 3.2.6.8. Self-Join ............................................................................................................................. 52

3.2.7. Lookup ............................................................................................................................ 53 3.2.7.1. Ficha Técnica..................................................................................................................... 53 3.2.7.2. Propósito............................................................................................................................ 54 3.2.7.3. Lookup Condicional............................................................................................................ 59 3.2.7.4. Parametrización ................................................................................................................. 62 3.2.7.5. Best Practices .................................................................................................................... 64 3.2.7.6. Cálculo de Tamaño de Caches .......................................................................................... 64 3.2.7.7. Uso Opcional de Caches ................................................................................................... 68

2/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.7.8. Uso de Caches Persistentes .............................................................................................. 70 3.2.7.9. Uso del Parámetro Lookup SQL Override.......................................................................... 71

3.2.8. Update Strategy .............................................................................................................. 74 3.2.8.1. Ficha Técnica..................................................................................................................... 74 3.2.8.2. Propósito............................................................................................................................ 74 3.2.8.3. Estrategias de Carga a Nivel de Sesión............................................................................. 75 3.2.8.4. Estrategias de Carga a Nivel de Mapping.......................................................................... 76 3.2.8.5. Parametrización ................................................................................................................. 79 3.2.8.6. Tratamiento de Registros Rechazados .............................................................................. 79 3.2.8.7. Best Practices .................................................................................................................... 81

3.2.9. Router ............................................................................................................................. 82 3.2.9.1. Ficha Técnica..................................................................................................................... 82 3.2.9.2. Propósito............................................................................................................................ 83 3.2.9.3. Parametrización ................................................................................................................. 84 3.2.9.4. Best Practices .................................................................................................................... 84

3.2.10. Sequence Generator..................................................................................................... 85 3.2.10.1. Ficha Técnica................................................................................................................... 85 3.2.10.2. Propósito.......................................................................................................................... 85 3.2.10.3. Parametrización ............................................................................................................... 85 3.2.10.4. Best Practices .................................................................................................................. 85

3.2.11. Union ............................................................................................................................. 85 3.2.11.1. Ficha Técnica................................................................................................................... 85 3.2.11.2. Propósito.......................................................................................................................... 86 3.2.11.3. Parametrización ............................................................................................................... 87 3.2.11.4. Best Practices .................................................................................................................. 87

3.2.12. Transaction Control....................................................................................................... 87 3.2.12.1. Ficha Técnica................................................................................................................... 87 3.2.12.2. Propósito.......................................................................................................................... 88 3.2.12.3. Parametrización ............................................................................................................... 89 3.2.12.4. Best Practices .................................................................................................................. 90

3.3. BEST PRACTICES ....................................................................................................................... 91 3.3.1. Nomenclatura.................................................................................................................. 91 3.3.1.1. General – Entidades .......................................................................................................... 91 3.3.1.2. General – Entornos ............................................................................................................ 91 3.3.1.3. Dominios ............................................................................................................................ 92 3.3.1.4. Nodos................................................................................................................................. 92 3.3.1.5. Repositorios ....................................................................................................................... 93 3.3.1.6. Integration Services ........................................................................................................... 93 3.3.1.7. Carpetas ............................................................................................................................ 94 3.3.1.8. Variables y Parámetros...................................................................................................... 94 3.3.1.9. Transformaciones .............................................................................................................. 95 3.3.1.10. Mapplets .......................................................................................................................... 96 3.3.1.11. Mappings ......................................................................................................................... 96 3.3.1.12. Sesiones y Otras Tareas.................................................................................................. 97 3.3.1.13. Worklets ........................................................................................................................... 97 3.3.1.14. Workflows ........................................................................................................................ 98 3.3.1.15. Deployment Groups ......................................................................................................... 98 3.3.1.16. Ficheros de Parámetros................................................................................................... 99 3.3.1.17. Ficheros Log .................................................................................................................... 99 3.3.1.18. Fuentes y Destinos ........................................................................................................ 100 3.3.1.19. Conexiones .................................................................................................................... 101 3.3.1.20. Shortcuts........................................................................................................................ 101

3.3.2. Descripciones................................................................................................................ 102 3.3.2.1. Normativa de Descripciones ............................................................................................ 102 3.3.2.2. Descripciones a Nivel de Fuente o Destino ..................................................................... 103 3.3.2.3. Descripciones a Nivel de Mapplet .................................................................................... 104 3.3.2.4. Descripciones a Nivel de Mapping ................................................................................... 104 3.3.2.5. Descripciones a Nivel de Sesión o Tarea ........................................................................ 105 3.3.2.6. Descripciones a Nivel de Workflow .................................................................................. 105

3.3.3. Diseño de Mappings ..................................................................................................... 106 3.3.3.1. Conectar sólo los puertos necesarios .............................................................................. 107 3.3.3.2. No cruzar flechas ............................................................................................................. 107 3.3.3.3. Funciones y operadores................................................................................................... 108 3.3.3.4. Evitar conversiones de tipo innecesarias ......................................................................... 108 3.3.3.5. Reducir el número de transformaciones en los mapping ................................................. 109

3/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.4. Diseño de sesiones y worflows ..................................................................................... 110 3.3.4.1. Utilizar Opción ‘Fail parent if this task fails’ ...................................................................... 111 3.3.4.2. Establecer Límite en Número de Errores por Sesión ....................................................... 112 3.3.4.3. Utilizar Enlaces Condicionales ......................................................................................... 113 3.3.4.4. Eliminar Ficheros Intermedios.......................................................................................... 114 3.3.4.5. Utilizar Opción ‘Fail task if any command fails’ en Tareas de tipo Comando ................... 115 3.3.4.6. Utilizar Variables de Entorno en Tareas de Tipo Comando ............................................. 115 3.3.4.7. Mantener el Log de Todas las Ejecuciones a Nivel de Workflow y Sesión ...................... 116 3.3.4.8. Parametrizar Nombres de Ficheros de Origen y Destino................................................. 118 3.3.4.9. Parametrizar Nombres de Ficheros FTP y Directorio Remoto ......................................... 119 3.3.4.10. Escritura de Logs Compatibles ...................................................................................... 121 3.3.4.11. Asistente para el Cálculo de Tamaños de Cachés......................................................... 123 3.3.4.12. Opciones de Auto Memory Attributes............................................................................. 123

3.3.5. Estructura de Directorios para Ficheros Fuente y Destino ........................................... 126 3.3.6. Estructura de Directorios para Scripts de Proyecto...................................................... 130 3.3.7. Tratamiento de Ficheros Host....................................................................................... 132 3.3.8. Uso de Conexiones FTP a Sistemas Host.................................................................... 138 3.3.9. Uso de Tabla de Conversión EBCDIC - ASCII Alternativa ........................................... 145 3.3.10. Reemplazo de Caracteres Especiales Utilizando REPLACECHR ............................. 147 3.3.11. Uso de Shortcuts......................................................................................................... 147 3.3.12. Generación dinámica de ficheros de salida con FileName ........................................ 151 3.3.13. Uso de opción Update Override.................................................................................. 154 3.3.13.1. Con Transformaciones Update Strategy ........................................................................ 154 3.3.13.2. Sin Transformaciones Update Strategy ......................................................................... 158

3.3.14. Utilización de contadores de rendimiento ................................................................... 159 4. PLANIFICACIÓN DE PROCESOS DE CARGA .......................................................................... 166 4.1. EJECUCIÓN DE PROCESOS DE CARGA DESDE LÍNEA DE COMANDO ............................................. 166 4.1.1. Sintaxis de Comandos pmcmd ..................................................................................... 166 4.1.2. Códigos de Retorno ...................................................................................................... 168 4.1.3. Uso de Ficheros de Parámetros ................................................................................... 169 4.1.4. Modificación de Ficheros de Parámetros en Tiempo de Ejecución.............................. 170 4.1.4.1. Uso del Script pmchangeparm.sh .................................................................................... 170

4.1.5. Ejemplos de Ejecución de Procesos............................................................................. 172 4.1.5.1. Consideraciones Generales ............................................................................................. 172 4.1.5.2. Variables de Sistema Operativo....................................................................................... 173 4.1.5.3. Resolución de la variable INFA_HOME ........................................................................... 173 4.1.5.4. Plantilla de script para Planificación................................................................................. 174 4.1.5.5. Ejemplo de script para Planificación ................................................................................ 175 4.1.5.6. Ejecución de Workflows sin Fichero de Parámetros ........................................................ 176 4.1.5.7. Ejecución de Workflows con Fichero de Parámetros ....................................................... 177 4.1.5.8. Ejecución de Workflows con Modificación de Fichero de Parámetros en Tiempo de Ejecución ............................................................................................................................................ 177 4.1.5.9. Ejecución de Workflows a Partir de Una Tarea Determinada .......................................... 178 4.1.5.10. Ejecución de Una Tarea Determinada dentro de Un Workflow...................................... 178 4.1.5.11. Parada de Workflows en Ejecución................................................................................ 179

5. PROCEDIMIENTOS DE ADMINISTRACIÓN DE LA HERRAMIENTA ....................................... 180 5.1. DEFINICIÓN DE ENTORNOS DE TRABAJO .................................................................................... 180 5.1.1. Definición de Repositorios ............................................................................................ 182 5.1.1.1. Repositorios Globales ...................................................................................................... 182 5.1.1.2. Repositorios Locales........................................................................................................ 182

5.1.2. Definición de Grupos y Usuarios .................................................................................. 183 5.1.2.1. Grupos y Usuarios en Desarrollo ..................................................................................... 183 5.1.2.2. Grupos y Usuarios en Pre-producción ............................................................................. 184 5.1.2.3. Grupos y Usuarios en Producción.................................................................................... 185

5.1.3. Definición de Carpetas.................................................................................................. 187 5.1.3.1. Carpetas en Desarrollo .................................................................................................... 187 5.1.3.2. Carpetas en Pre-producción ............................................................................................ 193 5.1.3.3. Carpetas en Producción................................................................................................... 197

6. APÉNDICE .................................................................................................................................... 201 6.1. TAMAÑOS DE COLUMNA PARA CÁLCULO DE CACHES ................................................................. 201 6.2. TABLA DE CONVERSIÓN EBCDIC-ASCII ALTERNATIVA (IBM-284) ............................................ 201

4/201

PowerCenter 8.x – Normativa de Desarrollo

1. Historial de cambios Fecha

Versión Descripción del cambio / versión

Elaborado

20/04/2009

1.0

Arquitectura Técnica BI

Versión Inicial

Revisado

5/201

PowerCenter 8.x – Normativa de Desarrollo

2. Introducción Este documento recopila los estándares y procedimientos establecidos hasta la fecha en el Grupo Santander para el desarrollo y administración de la plataforma de integración de datos Informatica ® PowerCenter . Los estándares y procedimientos descritos son de obligado cumplimiento en todas las entidades del grupo.

6/201

PowerCenter 8.x – Normativa de Desarrollo

3. Normas de diseño y desarrollo 3.1. Arquitectura de PowerCenter La organización de componentes para en un entorno de PowerCenter v.8.x se basa en un dominio con un nodo gateway o primario donde convivirán dos Repository Services, uno global y otro local, y dos Integration Services. Por defecto se definirá un Integration Service en modo ASCII y un Integration Service en modo Unicode en el nodo gateway. Dependiendo de las necesidades del entorno se añadirán a la arquitectura nuevos nodos worker o secundarios con Integration Services adicionales. Dentro del dominio se instalará de forma adicional una instancia de Metadata Reports. La figura siguiente muestra la distribución de componentes en un entorno de PowerCenter v.8.x configurado de acuerdo a la arquitectura descrita:

Figura 1: Distribución de Componentes en Informatica PowerCenter v.8.x

7/201

PowerCenter 8.x – Normativa de Desarrollo

La figura siguiente muestra la conectividad entre componentes en un entorno de PowerCenter v.8.x configurado de acuerdo a la arquitectura descrita:

Figura 2: Conectividad entre Componentes en Informatica PowerCenter 8.x

8/201

PowerCenter 8.x – Normativa de Desarrollo

3.2. Transformaciones básicas 3.2.1. Source Qualifier 3.2.1.1. Ficha Técnica

Source Qualifier Propósito

Extracción de datos de ficheros planos y fuentes relacionales

Nomenclatura

sq_NombreOrigen(es)

Reutilización

No Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.1.2. Propósito La transformación Source Qualifier se utiliza para extraer datos de fuentes relacionales o ficheros planos. Toda fuente de datos de este tipo que utilicemos en un mapping ha de estar conectada a una transformación de tipo Source Qualifier. Cada Source Qualifier representa el conjunto de registros que PowerCenter extrae de la fuente asociada al mismo. Si una transformación Source Qualifier se asocia a una tabla relacional la extracción de datos de dicha fuente se realizará a través de una consulta SQL. PowerCenter generará una consulta SELECT por defecto sobre la tabla asociada. Las propiedades de la transformación nos permitirán modificar la consulta generada. Una misma transformación Source Qualifier puede asociarse a múltiples tablas relacionales, siempre que éstas se encuentren en la misma base de datos. Si una transformación Source Qualifier se asocia a un fichero plano éste será procesado en su totalidad. PowerCenter no genera SQL para extraer datos de ficheros planos. Si nuestro proceso de carga necesita filtrar parte de los datos del fichero plano a tratar se utilizará una transformación de tipo Filter.

3.2.1.3. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


SQL Query: Disponible únicamente si una transformación Source Qualifier se asocia

a una o múltiples tablas relacionales. Si no se modifica ninguno de sus parámetros, la transformación Source Qualifier generará por defecto una consulta de tipo SELECT que incluya todos los puertos conectados a otras transformaciones en nuestro flujo de datos. Si la consulta generada por defecto resulta suficiente para seleccionar aquellos registros que sean necesarios en nuestro proceso de carga no será necesario modificar ningún parámetro de la transformación. Si por el contrario es necesario modificar la consulta generada por defecto podemos o bien utilizar los parámetros descritos a continuación, o bien utilizar el parámetro SQL Query para introducir directamente la consulta a utilizar por el Source Qualifier. Es importante tener en

9/201

PowerCenter 8.x – Normativa de Desarrollo

cuenta que una vez definida la consulta a utilizar por el Source Qualifier mediante este parámetro el resto de las propiedades de la transformación serán ignoradas. Si se asocia una consulta al Source Qualifier mediante el parámetro SQL Query se sobreescriben automáticamente las propiedades User-Defined Join, Source Filter, Number of Sorted Ports y Select Distinct de la transformación.


User Defined Join: Disponible únicamente si una transformación Source Qualifier se asocia a múltiples tablas relacionales. Este parámetro permite definir las condiciones de cruce entre dos o más tablas relacionales asociadas al Source Qualifier. No es necesario especificar la cláusula WHERE al definir dichas condiciones.


Source Filter: Disponible únicamente si una transformación Source Qualifier se asocia

a una o múltiples tablas relacionales. Este parámetro permite definir las condiciones de la consulta asociada al Source Qualifier. La transformación añadirá una cláusula WHERE a la consulta generada por defecto con las condiciones definidas mediante este parámetro.


Number of Sorted Ports: Disponible únicamente si una transformación Source

Qualifier se asocia a una o múltiples tablas relacionales. Este parámetro permite definir el orden en el cual se obtendrán los resultados de la consulta asociada al Source Qualifier. La transformación añadirá una cláusula ORDER BY a la consulta generada por defecto con tantos puertos como hayamos definido mediante este parámetro, de acuerdo al orden en el que aparecen en la transformación.


Tracing Level: Nivel de detalle relativo a la transformación Source Qualifier que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.


Select Distinct: Disponible únicamente si una transformación Source Qualifier se asocia a una o múltiples tablas relacionales. Este parámetro permite eliminar registros duplicados en los resultados de la consulta asociada al Source Qualifier. La transformación añadirá una cláusula DISTINCT a la consulta generada por defecto.


Pre SQL: Disponible únicamente si una transformación Source Qualifier se asocia a una o múltiples tablas relacionales. Comando SQL que PowerCenter ejecutará en la base de datos origen antes de empezar a leer registros.


Post SQL: Disponible únicamente si una transformación Source Qualifier se asocia a una o múltiples tablas relacionales. Comando SQL que PowerCenter ejecutará en la base de datos origen tras finalizar la carga de registros en los destinos.

3.2.1.4. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Utilizar las propiedades del Source Qualifier para seleccionar únicamente aquellos

registros que sean necesarios en nuestro proceso de carga. Reducir el volumen de datos a tratar resultará útil a la hora de optimizar nuestro proceso de carga.


Conectar únicamente aquellos puertos que sean necesarios en nuestro proceso de

carga para reducir el volumen de datos a tratar. La consulta asociada al Source Qualifier incluirá solamente los puertos conectados a otras transformaciones en nuestro flujo de datos.


No modificar manualmente la consulta asociada al Source Qualifier mediante el parámetro SQL Query si es posible utilizar con el mismo fin el resto de parámetros de la transformación. Una vez definida la consulta a utilizar por el Source Qualifier mediante este parámetro el resto de las propiedades de la transformación serán ignoradas. Si se asocia una consulta al Source Qualifier mediante el parámetro SQL Query se sobreescriben automáticamente las propiedades User-Defined Join, Source Filter, Number of Sorted Ports y Select Distinct de la transformación.

10/201

PowerCenter 8.x – Normativa de Desarrollo


Si es necesario modificar la consulta asociada al Source Qualifier mediante el

parámetro SQL Query organizar los puertos conectados a otras transformaciones de forma que aparezcan en la parte superior de la transformación en lugar de mantenerlos dispersos. De esta forma facilitaremos la visualización de los puertos utilizados.


Si es necesario modificar la consulta asociada al Source Qualifier mediante el

parámetro SQL Query comprobar que los puertos utilizados en la consulta aparecer en el mismo orden que en la transformación. En caso contrario estaríamos leyendo unos campos por otros.


Mantener

todos los puertos en la transformación Source Qualifier independientemente de si son utilizados o no. De esta forma facilitaremos futuros cambios al proceso de carga sin impacto alguno en el rendimiento del mismo.

3.2.2. Expression 3.2.2.1. Ficha Técnica

Expression Propósito

Cálculos a nivel de registro

Nomenclatura

exp_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Pasiva

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.2.2. Propósito La transformación Expression se utiliza para realizar cálculos a nivel de registro. Este tipo de transformación nos permite realizar cualquier tipo de cálculo no agregado sobre nuestros datos. Si es necesario realizar cálculos sobre grupos de registros, como sumas o valores medios, utilizaremos la transformación Aggregator (ver sección 3.2.5). La transformación Expression es equivalente al uso de funciones en una consulta SQL. En el ejemplo siguiente utilizamos como origen una tabla que contiene información de contacto para todos nuestros clientes (ODS_CLIENTES). Deseamos calcular la antigüedad de cada cliente a partir de la fecha de alta en el sistema (DATE_INSERTED) indicada en nuestra tabla. La transformación Expression exp_CALC_DIAS_COMO_CLIENTE nos permite realizar dicho cálculo para cada registro.

11/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 3: Ejemplo de Uso de Transformación Expression En nuestro ejemplo hemos definido dos tipos de puertos en la transformación Expression exp_CALC_DIAS_COMO_CLIENTE:


Input Only: Indica los puertos que se utilizarán en los cálculos, en este caso la fecha de alta en el sistema (DATE_INSERTED).


Output Only: Indica los puertos que contienen los cálculos, en este caso la

antigüedad del cliente en días, que definimos como la diferencia entre la fecha de alta en el sistema y la fecha actual (DIAS_COMO_CLIENTE_OUT). Este tipo de puerto nos permite especificar una expresión que corresponda al cálculo que se desea realizar (DIAS_COMO_CLIENTE_OUT = DATE_DIFF(SYSDATE, DATE_INSERTED, ‘DD’)). La definición de este tipo de expresiones se describe en detalle en la sección 3.2.2.3.

El resultado de nuestra transformación Expression sería equivalente a la siguiente consulta SQL en Oracle: SELECT […] TRUNC(SYSDATE - DATE_INSERTED) AS DIAS_COMO_CLIENTE […] FROM ODS_CLIENTES Mientras que funcionalmente podemos considerar que el uso de una transformación Expression en PowerCenter es equivalente al uso de funciones de base de datos, hemos de tener en cuenta que estas últimas son distintas para cada tipo de base de datos. Por el contrario, las funciones disponibles en PowerCenter son propias de la plataforma y totalmente independientes del tipo de sistema origen o destino que utilicemos en nuestro proceso de carga. La expresión definida en nuestro ejemplo funcionará de la misma forma independientemente de que la tabla ODS_CLIENTES resida en Oracle o DB2 o incluso si obtenemos nuestros datos de un fichero plano.

12/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.2.3. Definición de Expresiones Tal y como hemos visto en nuestro ejemplo, PowerCenter permite la definición de expresiones para algunos tipos de transformación utilizando un lenguaje propio similar a SQL. Dichas expresiones se crean y validan utilizando un asistente accesible desde cualquier punto de la herramienta donde sea aplicable su uso, el Expression Editor.

Figura 4: Uso del Expression Editor En el caso de la transformación Expression podemos definir una expresión en un puerto de tipo Output o Variable utilizando cualquier combinación de los siguientes elementos: •

Puertos de tipo Input o Input/Output

•

Puertos de tipo Variable (Ver sección 3.2.2.7)

•

Variables y parámetros del mapping

•

Variables predefinidas (SESSSTARTTIME y SYSDATE)

•

Operadores (+, -, *, /, % ,=, >, =, = 10 GROUP BY PRODUCT_CODE

3.2.5.3. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Cache Directory: Especifica el directorio utilizado para crear los ficheros temporales

de cache utilizados por la transformación. Por defecto dichos ficheros se crean en el directorio asignado a la variable de servidor $PMCacheDir. Si es necesario sobreescribir este valor compruebe que el directorio utilizado existe y dispone de espacio suficiente para crear dichos ficheros.


Tracing Level: Nivel de detalle relativo a la transformación Aggregator que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.


Aggregator Data Cache Size: Memoria asignada al cache temporal de datos de la transformación. Por defecto la transformación asigna 2 MB de memoria a este cache.


Aggregator Index Cache Size: Memoria asignada al cache temporal de índices de la transformación. Por defecto la transformación asigna 1 MB de memoria a este cache.

34/201

PowerCenter 8.x – Normativa de Desarrollo


Sorted Input: Indica si el flujo de datos se encuentra ordenado por aquellos puertos

por los que deseamos agrupar. La utilización de esta propiedad puede mejorar considerablemente el rendimiento de la transformación y reducir la necesidad de recursos para la misma. La sección 3.2.5.7 describe en detalle el uso de esta propiedad.

3.2.5.4. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Utilizar siempre que sea posible la opción Sorted Input. El uso de datos ordenados

reduce el volumen de datos a mantener en los caches de la transformación. Esta propiedad se describe en detalle en la sección 3.2.5.7.


Filtrar lo antes posible dentro del flujo de datos. Reducir el volumen de datos a tratar resultará útil a la hora de optimizar nuestro proceso de carga.


Limitar el número de puertos de tipo Input/Output y Output para reducir el volumen de datos que la transformación ha de mantener en cache. Eliminar de la transformación aquellos puertos que no sean necesarios para nuestros cálculos agregados.


Evitar expresiones complejas al definir condiciones de filtrado para las funciones de

agregación. Si es necesario, calcular el resultado de evaluar la condición de filtrado como paso previo en una transformación de tipo Expression, asignando el valor de dicha evaluación a un campo de salida de tipo integer o boolean. Enlazar dicho campo con la transformación Aggregator y evaluar el mismo en la condición de filtrado de la función correspondiente.


Utilizar puertos de tipo Variable para optimizar aquellos cálculos donde una misma expresión haya de evaluarse varias veces para un mismo registro. El uso de este tipo de puertos se describe en detalle en la sección 3.2.5.6.


Parametrizar, en la medida de lo posible, suficiente memoria en los parámetros de cache de la transformación para evitar que se vuelquen dichos caches a disco.

3.2.5.5. Cálculo de Tamaño de Caches La transformación Aggregator utiliza dos tipos de caches temporales para realizar las operaciones de agregación. Dichos caches almacenarán aquellas columnas necesarias para realizar los cálculos agregados. La transformación crea los siguientes tipos de cache:


Un cache temporal de índices (Aggregator Index Cache) con las columnas utilizadas como clave de agregación.


Un cache temporal de datos (Aggregator Data Cache) con las columnas a utilizar en los cálculos agregados y otras columnas auxiliares.

Las propiedades de la transformación nos permiten parametrizar la memoria asignada a estos caches temporales. Si al procesar los datos la transformación no dispone de suficiente espacio para mantener en memoria dichos caches se crearán ficheros temporales para volcar a disco los datos que no pueda mantener en memoria. Es muy importante asignar memoria suficiente a estos caches para minimizar el acceso a disco, ya que esta operación ralentiza considerablemente el procesado de los datos. La utilización de datos ordenados nos permite reducir al mínimo el uso de caches en una transformación Aggregator. El uso de la propiedad Sorted Input se describe en detalle en la sección 3.2.5.7.

35/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.5.5.1. Cálculo del Cache de Indices El cache de índices de una transformación de tipo Aggregator almacena las columnas utilizadas como clave de agregación. Utilice la siguiente fórmula para calcular el tamaño mínimo del cache de índices de la transformación:

Aggregator – Cálculo Cache de Indices # grupos [( S tamaño columna) + 17]

Columnas en Cache Columnas utilizadas como clave de agregación

La siguiente transformación de tipo Aggregator, agg_PRODUCT_SALES, se utiliza para calcular ventas por producto a partir de la información obtenida de un fichero de pedidos. El proceso calcula el total de unidades vendidas por producto (QTY_TOT) y el total de ventas por producto (SALES_TOT), agrupando por código de producto (PRODUCT_CODE). Esta transformación no utiliza la propiedad Sorted Input.

Figura 24: Ejemplo de Transformación Aggregator para Cálculo de Caches Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de índices de la transformación:

Nombre Columna PRODUCT_CODE

Tipo Columna Columna utilizada como clave de agregación

Tipo de Datos

Tamaño

Decimal (10)

10

TOTAL

10

En nuestro ejemplo todos los posibles códigos de producto para los cuales pueden haberse recibido pedidos se almacenan en la tabla de productos (PRODUCT). Esta tabla contiene

36/201

PowerCenter 8.x – Normativa de Desarrollo

90,000 registros. Cada código de producto representa un posible grupo dentro de nuestra transformación. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de índices de la transformación: 90,000 * (10 + 17) = 2,430,000 Esta transformación requiere un tamaño de cache de índices de 2,430,000 bytes.

3.2.5.5.2. Cálculo del Cache de Datos

El cache de datos de una transformación de tipo Aggregator almacena las columnas a utilizar en los cálculos agregados así como otras columnas auxiliares. Utilice la siguiente fórmula para calcular el tamaño mínimo del cache de datos de la transformación:

Aggregator – Cálculo Cache de Datos

Columnas en Cache

# grupos [( S tamaño columna) + 7] •

Puertos de tipo Input no definidos como clave de agrupación utilizados en cálculos agregados.

•

Puertos de tipo Input/Output no utilizados como clave de agrupación.

•

Puertos de tipo Variable.

•

Puertos que contienen cálculos agregados. (*)

(*) El espacio de cache utilizado puede variar dependiendo de la función. Multiplique por tres el tamaño de la columna para obtener un valor medio aproximado independiente de la función utilizada.

Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de datos de la transformación agg_PRODUCT_SALES:

Nombre Columna

Tipo Columna

Tipo de Datos

Tamaño

QTY_TOT

Puerto que contiene cálculos agregados

Decimal (10)

30 (*)

SALES_TOT

Puerto que contiene cálculos agregados

Decimal (10)

30 (*)

TOTAL

60

(*) No olvide multiplicar el tamaño de la columna por tres.

37/201

PowerCenter 8.x – Normativa de Desarrollo

Podemos comprobar que no utilizaremos PRODUCT_CODE en el cálculo ya que se utiliza como clave de agregación y por tanto se almacenará en el cache de índices. En nuestro ejemplo todos los posibles códigos de producto para los cuales pueden haberse recibido pedidos se almacenan en la tabla de productos (PRODUCT). Esta tabla contiene 90,000 registros. Cada código de producto representa un posible grupo dentro de nuestra transformación. Esta tabla contiene 90,000 registros. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de datos de la transformación: 90,000 * (60 + 7) = 6,030,000 Esta transformación requiere un tamaño de cache de datos de 6,030,000 bytes.

3.2.5.6. Uso de Puertos de Tipo Variable La transformación de tipo Aggregator permite la definición de puertos de tipo Variable. Este tipo de puertos son equivalentes a declaraciones de variables locales a la transformación. El uso de este tipo de puertos nos permite:


Simplificar expresiones complejas.
Optimizar aquellos cálculos donde una misma expresión haya de evaluarse varias veces para un mismo registro.

En el ejemplo siguiente utilizaremos una transformación de tipo Aggregator para calcular ventas por trimestre a partir de la información obtenida de un fichero de pedidos. Las ventas para cada trimestre se calcularán por separado. Para determinar qué pedidos pertenecen a cada trimestre obtenemos el mes correspondiente a cada pedido utilizando un puerto de tipo Variable (MONTH). Este valor se utilizará como filtro para los cálculos agregados. Podemos comprobar que en nuestro ejemplo hemos calculado el mes al que pertenece cada pedido ejecutando la función GET_DATE_PART() una sola vez por registro. Si prescindimos del puerto de tipo Variable MONTH sería necesario calcular este valor tres veces para cada cálculo agregado, por lo que ejecutaríamos la función GET_DATE_PART() doce veces por registro.

Figura 25: Uso de Puertos de Tipo Variable

3.2.5.7. Sorted Input La forma más eficaz de optimizar el rendimiento de una transformación de tipo Aggregator consiste en ordenar el flujo de datos por los campos definidos como claves de agrupación. La utilización de esta técnica de optimización ofrece las siguientes ventajas:


Menor tiempo de ejecución: la transformación no necesita procesar todos los registros del flujo de datos antes de comenzar los cálculos de agregación. De esta forma los resultados están disponibles de forma gradual y la operación es considerablemente más rapida.

38/201

PowerCenter 8.x – Normativa de Desarrollo


Mínimo consumo de recursos: el uso de datos ordenados permite a la transformación Aggregator reducir al mínimo el uso de caches.

Se indican a continuación los pasos a seguir para optimizar el rendimiento de una transformación de tipo Aggregator mediante la ordenación del flujo de entrada:


Ordenar el flujo de datos por aquellos puertos por los que deseamos agrupar.
Seleccionar la opción Sorted Input en la transformación Aggregator. En una primera versión de nuestro ejemplo asumiremos que el flujo de datos no se encuentra ordenado. Asignaremos la suficiente memoria a los caches de datos e índices de la transformación Aggregator para almacenar todos los registros de nuestro flujo de datos.

Figura 26: Uso de Transformación Aggregator sin Sorted Input La transformación Aggregator procesará los registros del flujo de datos en su totalidad, almacenando en las caches temporales los datos necesarios para realizar los cálculos. Dado que el fujo de datos no se encuentra ordenado la transformación no puede realizar los cálculos hasta que todos los registros hayan sido procesados y almacenados en los caches. Una vez procesados todos los registros la transformación Aggregator proporciona los resultados al flujo de datos, eliminando los caches y liberando los recursos dedicados a los mismos. En la versión optimizada de nuestro mapping ordenaremos el flujo de datos de entrada por aquellos puertos por los que deseamos agrupar. En nuestro ejemplo utilizaremos una transformación de tipo Sorter para ordenar los registros del fichero de pedidos por código de producto. Cada código de producto define un grupo de registros sobre el cual realizar los cálculos deseados. Una vez ordenado el flujo de entrada seleccionaremos la opción Sorted Input en la transformación Aggregator. En este caso necesitaremos asignar a los caches de datos e índices de la transformación únicamente la memoria necesaria para almacenar un grupo de registros en lugar del flujo de datos completo.

39/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 27: Uso de Transformación Aggregator con Sorted Input La transformación Aggregator comenzará a procesar los registros del flujo de datos, comparando los valores del código de producto asociado a cada registro con el del registro anterior. Dado que el flujo de datos se encuentra ordenado por aquel puerto por el cual deseamos agrupar, la transformación Aggregator es capaz de determinar de una forma sencilla qué registros pertenecen a cada grupo. Si se detecta un nuevo código de producto la transformación realizará los cálculos agregados para los registros del grupo cuya lectura se ha completado. Una vez procesado un grupo de registros la transformación Aggregator devuelve los resultados al flujo de datos, eliminando los caches y liberando los recursos dedicados a los mismos. La transformación Aggregator procesa grupo a grupo en lugar de realizar los cálculos para todos los grupos al mismo tiempo, por lo que el cálculo es considerablemente más rapido. De igual manera la transformación almacenará en cache un grupo de registros en cada momento, minimizando el uso de recursos. Se aconseja utilizar datos ordenados para optimizar las operaciones de agregación siempre que sea posible. Sin embargo, antes de decidir si ha de optimizarse una transformación de tipo Aggregator utilizando esta técnica hemos de considerar el coste de ordenar los datos en términos de recursos y tiempo de procesamiento, ya que el mismo puede exceder el beneficio obtenido al utilizar datos ordenados.

3.2.5.8. Eliminación de Registros Duplicados La transformación Aggregator nos permite eliminar registros duplicados de nuestro flujo de datos. Esta propiedad es equivalente al uso de la cláusula DISTINCT en lenguaje SQL. En el ejemplo siguiente utilizamos una transformación de tipo Source Qualifier y una transformación de tipo Filter para extraer de un fichero inicial (f_CLIENTES) la información de aquellos clientes que residan en Madrid. En nuestro ejemplo deseamos eliminar cualquier registro duplicado que pueda existir en el flujo de datos. Para ello utilizaremos la transformación de tipo Aggregator agg_CLIENTES_MADRID_NO_DUPL, agrupando por todos los puertos de la misma.

40/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 28: Ejemplo de Eliminación de Registros Duplicados en Transformación Aggregator El resultado de nuestra transformación Aggregator sería equivalente a la siguiente consulta SQL: SELECT DISTINCT NIF, NOMBRE, DIRECCION, […] FROM f_CLIENTES_MADRID

3.2.6. Joiner 3.2.6.1. Ficha Técnica

Joiner Propósito

Cruce de flujos de datos heterogéneos

41/201

PowerCenter 8.x – Normativa de Desarrollo

Nomenclatura

jnr_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

Sí

3.2.6.2. Propósito La transformación Joiner se utiliza para cruzar flujos de datos heterogéneos. Mientras que la transformación Source Qualifier nos permite unir únicamente tablas de una misma base de datos, la transformación Joiner hace posible cruzar dos flujos de datos de cualquier tipo, como por ejemplo:


Dos ficheros planos
Un fichero plano y una tabla
Una tabla en Oracle y otra en DB2
Dos tablas en distintas instancias de base de datos En lenguaje SQL un JOIN es un operador relacional que combina registros de múltiples tablas en un único conjunto de resultados. La transformación Joiner funciona de una manera similar, con la excepción de que los datos a cruzar pueden tener su origen en fuentes de distinto tipo. Una transformación Joiner permite cruzar únicamente dos flujos de datos. Uno de dichos flujos se definirá como Master y el otro como Detail. Esta propiedad nos permitirá seleccionar los registros de uno u otro flujo para ciertos tipos de cruce. Si es necesario cruzar más de dos flujos de datos se utilizarán una serie de transformaciones Joiner en cascada.

3.2.6.3. Tipos de Cruce La transformación Joiner permite realizar los siguientes tipos de cruces:


Normal Join
Master Outer
Detail Outer
Full Outer Para ilustrar las diferencias entre los distintos tipos de cruce utilizaremos el ejemplo que muestra la figura. Disponemos de dos ficheros planos, f_PARTS_SIZE y f_PARTS_COLOR con información sobre tamaños y colores disponibles para piezas de automóbiles respectivamente.

42/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 29: Unión de dos ficheros utilizando una transformación Joiner Los ficheros utilizados en nuestro ejemplo contienen los siguientes registros:

PARTS_SIZE (Master) PART_ID

DESCRIPTION

SIZE

1

Seat Cover

Large

2

Ash Tray

Small

3

Floor Mat

Medium

PARTS_COLOR (Detail) PART_ID

DESCRIPTION

COLOR

1

Seat Cover

Blue

3

Floor Mat

Black

4

Fuzzy Dice

Yellow

Utilizaremos una transformación de tipo Joiner para unir los datos de ambos ficheros. Para diferenciar los campos comunes a ambos orígenes renombraremos f_PARTS_SIZE.PART_ID, f_PARTS_SIZE.DESCRIPTION COMO PART_ID1, DESCRIPTION1 y f_PARTS_COLOR.PART_ID, f_PARTS_COLOR.DESCRIPTION como PART2, DESCRIPTION2 en nuestra transformación. Para unir ambos ficheros por PART_ID utilizaremos la siguiente condición: PART_ID1 = PART_ID2 En este caso hemos seleccionado el flujo de datos originado en Master.

f_PARTS_SIZE como

43/201

PowerCenter 8.x – Normativa de Desarrollo


Normal Join Este tipo de cruce nos permite seleccionar únicamente los registros de ambos flujos que cumplen la condición de cruce especificada. Los registros que no cumplen la condición de cruce se eliminan. En nuestro ejemplo obtendremos el siguiente resultado:

PART_ID

DESCRIPTION

SIZE

COLOR

1

Seat Cover

Large

Blue

3

Floor Mat

Medium

Black

Se indica a continuación la consulta SQL a utilizar para obtener el mismo resultado: SELECT * FROM PARTS_SIZE, PARTS_COLOR WHERE PARTS_SIZE.PART_ID = PARTS_COLOR.PART_ID


Master Outer Join Este tipo de cruce nos permite seleccionar todos los registros del flujo de datos definido como Detail mas los registros del flujo definido como Master que cumplen la condición de cruce. Los registros del flujo definido como Master que no cumplen la condición de cruce se eliminarán del resultado de la transformación. Los registros del flujo definido como Detail para los que no haya una correspondencia en el flujo definido como Master aparecerán con un valor de NULL en los campos de este último. En nuestro ejemplo obtendremos el siguiente resultado:

PART_ID

DESCRIPTION

SIZE

COLOR

1

Seat Cover

Large

Blue

3

Floor Mat

Medium

Black

4

Fuzzy Dice

NULL

Yellow

Se indica a continuación la consulta SQL a utilizar para obtener el mismo resultado: SELECT * FROM PARTS_SIZE LEFT OUTER JOIN PARTS_COLOR ON (PARTS_SIZE.PART_ID = PARTS_COLOR.PART_ID)


Detail Outer Join Este tipo de cruce nos permite seleccionar todos los registros del flujo de datos definido como Master mas los registros del flujo definido como Detail que cumplen la condición de cruce. Los

44/201

PowerCenter 8.x – Normativa de Desarrollo

registros del flujo definido como Detail que no cumplen la condición de cruce se eliminarán del resultado de la transformación. Los registros del flujo definido como Master para los que no haya una correspondencia en el flujo definido como Detail aparecerán con un valor de NULL en los campos de este último. En nuestro ejemplo obtendremos el siguiente resultado:

PART_ID

DESCRIPTION

SIZE

COLOR

1

Seat Cover

Large

Blue

2

Ash Tray

Small

NULL

3

Floor Mat

Medium

Black

Se indica a continuación la consulta SQL a utilizar para obtener el mismo resultado: SELECT * FROM PARTS_SIZE RIGHT OUTER JOIN PARTS_COLOR ON (PARTS_COLOR.PART_ID = PARTS_SIZE.PART_ID)


Full Outer Join Este tipo de cruce nos permite seleccionar todos los registros de ambos flujos, independientemente de que cumplan o no la condición de cruce especificada. Los registros que no cumplan la condición de cruce aparecerán con un valor de NULL en aquellos campos de uno u otro flujo. En nuestro ejemplo obtendremos el siguiente resultado:

PART_ID

DESCRIPTION

SIZE

Color

1

Seat Cover

Large

Blue

2

Ash Tray

Small

NULL

3

Floor Mat

Medium

Black

4

Fuzzy Dice

NULL

Yellow

Se indica a continuación la consulta SQL a utilizar para obtener el mismo resultado: SELECT * FROM PARTS_SIZE FULL OUTER JOIN PARTS_COLOR ON (PARTS_SIZE.PART_ID = PARTS_COLOR.PART_ID)

Este tipo de cruce precisa de un paso adicional de consolidación de claves. Se indican a continuación el valor de los registros procesados en la transformación Joiner de nuestro ejemplo cuando utilizamos un cruce de tipo Full Outer Join:

45/201

PowerCenter 8.x – Normativa de Desarrollo

PART_ID1

PART_ID2

DESCRIPTION1

DESCRIPTION2

SIZE

Color

Seat Cover

Seat Cover

Large

Blue

1

1

2

NULL

Ash Tray

NULL

Small

NULL

3

3

Floor Mat

Floor Mat

Medium

Black

NULL

4

NULL

Fuzzy Dice

NULL

Yellow

Los campos PART_ID y DESCRIPTION aparecerán con un valor de NULL en uno u otro flujo para aquellos registros que no cumplan la condición de cruce. Para seleccionar los valores no nulos en cada caso utilizaremos una transformación de tipo Expression con un puerto de salida para cada uno de estos campos y una expresión condicional para obtener el valor no nulo en cada caso. Fig. 7 muestra la transformación a utilizar en nuestro ejemplo.

Figura 30: Consolidación de claves de unión

3.2.6.4. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Case-Sensitive String Comparison: Indica si la transformación Joiner ha de diferenciar entre mayúsculas y minúsculas al realizar cruces entre campos alfanuméricos.


Cache Directory: Especifica el directorio utilizado para crear los ficheros temporales

de cache utilizados por la transformación. Por defecto dichos ficheros se crean en el directorio asignado a la variable de servidor $PMCacheDir. Si es necesario

46/201

PowerCenter 8.x – Normativa de Desarrollo

sobreescribir este valor compruebe que el directorio utilizado existe y dispone de espacio suficiente para crear dichos ficheros.


Join Type: Tipo de cruce a realizar: Normal, Master Outer, Detail Outer, o Full Outer. La sección 3.2.6.3 detalla el uso de cada tipo de cruce.


Tracing Level: Nivel de detalle relativo a la transformación Joiner que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.


Joiner Data Cache Size: Memoria asignada al cache temporal de datos de la transformación. Por defecto la transformación asigna 2 MB de memoria a este cache.


Joiner Index Cache Size: Memoria asignada al cache temporal de índices de la transformación. Por defecto la transformación asigna 1 MB de memoria a este cache.


Sorted Input: Indica si los flujos a cruzar se encuentran ordenados por los campos

utilizados como clave de cruce. La utilización de esta propiedad puede mejorar considerablemente el rendimiento de la transformación y reducir la necesidad de recursos para la misma. Las secciones 3.2.6.7 y 3.2.6.8 describen en detalle el uso de esta propiedad.

3.2.6.5. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Utilizar siempre que sea posible la opción Sorted Input. El uso de esta propiedad se describe en detalle en la sección 3.2.6.7.


Si no se utiliza la propiedad Sorted Input, definir como Master aquel flujo de datos con

un menor número de registros. La transformación Joiner procesa en primer lugar los registros del flujo definido como Master, los cuales se almacenan en caches temporales. La transformación procesará a continuación los registros del flujo de datos marcado como Detail, comparando cada registro del flujo Detail con los registros del flujo Master en cache para comprobar si cumple la condición de cruce. Una vez procesados todos los registros la transformación Joiner elimina los caches y libera los recursos dedicados a los mismos. Definiendo como Master el flujo con menor número de registros minimizaremos los recursos requeridos por la transformación.


Si se utiliza la propiedad Sorted Input, definir como Master aquel flujo de datos con un

menor número de valores duplicados para la clave de cruce. El uso de datos ordenados permite a la transformación Joiner reducir al mínimo el uso de caches, ya que únicamente es necesario mantener en cache los valores duplicados de la clave de cruce.


Si es necesario realizar un cruce entre tablas que residan en una misma instancia,

utilizar un Source Qualifier en lugar de una transformación Joiner para realizar dicho cruce a nivel de base de datos. De esta forma reduciremos el volumen de datos a tratar en nuestro proceso.


Si es necesario cruzar más de dos flujos de datos utilizando una serie de transformaciones Joiner en cascada cruzar los flujos de menor a mayor en cuanto a número de registros.


Parametrizar, en la medida de lo posible, suficiente memoria en los parámetros de cache de la transformación para evitar que se vuelquen dichos caches a disco.

47/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.6.6. Cálculo de Tamaño de Caches La transformación Joiner utiliza dos tipos de caches temporales para optimizar las operaciones de cruce. Dichos caches temporales almacenarán columnas específicas de los registros del flujo marcado como Master. La transformación crea los siguientes tipos de cache:


Un cache temporal de índices (Joiner Index Cache) con las columnas del flujo Master utilizadas como clave de cruce.


Un cache temporal de datos (Joiner Data Cache) con las columnas del flujo Master a incluir en el resultado de la operación de cruce pero no utilizadas como clave del mismo.

Las propiedades de la transformación nos permiten parametrizar la memoria asignada a estos caches temporales. Si al procesar los datos la transformación no dispone de suficiente espacio para mantener en memoria dichos caches se crearán ficheros temporales para volcar a disco los datos que no pueda mantener en memoria. Es muy importante asignar memoria suficiente a estos caches para minimizar el acceso a disco, ya que esta operación ralentiza considerablemente el procesado de los datos. La utilización de datos ordenados nos permite reducir al mínimo el uso de caches en una transformación Joiner. El uso de la propiedad Sorted Input se describe en detalle en la sección 3.2.6.7.

3.2.6.6.1. Cálculo del Cache de Indices El cache de índices de una transformación de tipo Joiner almacena las columnas del flujo marcado como master que se utilizan como clave de cruce. Utilice la siguiente fórmula para calcular el tamaño mínimo del cache de índices de la transformación:

Joiner – Cálculo Cache de Indices # registros master [( S tamaño columna) + 16]

Columnas en Cache Columnas master utilizadas como clave de cruce

La siguiente transformación de tipo Joiner, jnr_PRODUCT_ORDER, se utiliza para cruzar datos de una tabla de productos (PRODUCT) y un fichero de pedidos (ORDERS) por código de producto (PRODUCT_CODE). Esta trasnformación no utiliza la propiedad Sorted Input.

48/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 31: Ejemplo de Transformación Joiner para Cálculo de Caches Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de índices de la transformación:

Nombre Columna PRODUCT_CODE

Tipo Columna Columna master utilizada como clave de cruce

Tipo de Datos

Tamaño

Decimal (10)

16

TOTAL

16

En nuestro ejemplo hemos definido el flujo de datos con origen en la tabla de productos (PRODUCT) como master. Esta tabla contiene 90,000 registros. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de índices de la transformación: 90,000 * (16 + 16) = 2,880,000 Esta transformación requiere un tamaño de cache de índices de 2,880,000 bytes.

3.2.6.6.2. Cálculo del Cache de Datos

El cache de datos de una transformación de tipo Joiner almacena las columnas del flujo de datos Master definidas como de salida hasta que se realize la operación de cruce. Utilice la siguiente fórmula para calcular el tamaño mínimo del cache de datos de la transformación:

Joiner – Cálculo Cache de Datos # registros master [( S tamaño columna) + 8]

Columnas en Cache Columnas master marcadas como de salida no utilizadas como clave de cruce

49/201

PowerCenter 8.x – Normativa de Desarrollo

Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de datos de la transformación jnr_PRODUCT_ORDER:

Nombre Columna

Tipo Columna

Tipo de Datos

Tamaño

PRODUCT_NAME

Columna master no utilizada como clave de cruce

String (23)

32

PRODUCT_CATEGORY

Columna master no utilizada como clave de cruce

String (21)

30

TOTAL

62

Podemos comprobar que no utilizaremos PRODUCT_CODE en el cálculo ya que se utiliza en la condición de cruce y por tanto se almacenará en el cache de índices. En nuestro ejemplo hemos definido el flujo de datos con origen en la tabla de productos (PRODUCT) como master. Esta tabla contiene 90,000 registros. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de datos de la transformación: 90,000 * (62 + 8) = 6,300,000 Esta transformación requiere un tamaño de cache de datos de 6,300,000 bytes.

3.2.6.7. Sorted Input La forma más eficaz de optimizar el rendimiento de una transformación de tipo Joiner consiste en ordenar los flujos de datos a cruzar. La utilización de esta técnica de optimización ofrece las siguientes ventajas:


Menor tiempo de ejecución: la transformación no necesita comparar cada registro de

un flujo de datos de entrada con todos los registros del otro ya que los registros de ambos flujos se encuentran ordenados, por lo que la operación de cruce es considerablemente más rapida.


Mínimo consumo de recursos: el uso de datos ordenados permite a la transformación Joiner reducir al mínimo el uso de caches.

Se indican a continuación los pasos a seguir para optimizar el rendimiento de una transformación de tipo Joiner mediante la ordenación de los flujos de entrada:


Ordenar cada flujo de datos por los puertos utilizados en la condición de cruce.
Seleccionar la opción Sorted Input en la transformación Joiner. En el ejemplo siguiente utilizamos la transformación Joiner jnr_ODS_ORDER_AMOUNT para cruzar datos de un fichero plano con información de pedidos (f_ORDER) y de una tabla Oracle con información de producto (PRODUCT). Cruzaremos ambos flujos de datos por código de producto (PRODUCT_CODE). En una primera versión de nuestro mapping asumiremos que los flujos de datos a cruzar no se encuentran ordenados. En primer lugar marcaremos como Master en la transformación Joiner el flujo de entrada con menor número de registros, en este caso el flujo con origen en la tabla de productos. Asignaremos a continuación la suficiente memoria a los caches de datos e índices de la transformación Joiner.

50/201

PowerCenter 8.x – Normativa de Desarrollo

La transformación Joiner procesará en primer lugar los registros del flujo de datos marcado como Master, en este caso el flujo con origen en la tabla de productos. Todos los registros de este flujo se almacenarán en los caches de la transformación. La transformación procesará a continuación los registros del flujo de datos marcado como Detail, en este caso el flujo con origen en el fichero de pedidos. Dichos registros no se almacenarán en los caches de la transformación. Cada registro del flujo Detail se compara con los registros del flujo Master en cache para comprobar si cumple la condición de cruce. Una vez procesados todos los registros la transformación Joiner elimina los caches y libera los recursos dedicados a los mismos.

Figura 32: Uso de transformación Joiner sin Sorted Input En la versión optimizada de nuestro mapping ordenaremos los flujos de datos de entrada por los puertos utilizados en la condición de cruce. En este caso modificaremos las propiedades de la transformación Source Qualifier asociada a la tabla de productos para ordenar por código de producto, y utilizaremos una transformación de tipo Sorter para ordenar los registros del fichero de pedidos por código de producto. Una vez ordenados ambos flujos de entrada marcaremos en la transformación Joiner aquel flujo con menor número de registros duplicados para la clave de cruce como Master, en este caso el flujo con origen en la tabla de productos, y seleccionaremos la opción Sorted Input. En este caso necesitaremos únicamente la memoria por defecto asignada a los caches de datos e índices de la transformación Joiner.

51/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 33: Uso de transformación Joiner con Sorted Input La transformación Joiner comenzará procesando al mismo tiempo bloques de registros de ambos flujos de entrada, comparando los registros de uno y otro flujo para determinar si cumplen la condición de cruce. Ya que los registros de ambos flujos se encuentran ordenados por la clave de cruce la transformación no necesita comparar cada registro de un flujo de datos con todos los registros del otro, por lo que la operación de cruce es considerablemente más rapida. Tras obtener un nuevo bloque de registros de uno u otro flujo de entrada la transformación compara el último registro obtenido de cada flujo. Dado que los registros de ambos flujos se encuentran ordenados por la clave de cruce la transformación Joiner es capaz de controlar si ha de obtener nuevos bloques de registros de uno u otro flujo. De esta manera la transformación evita el almacenar registros en cache, minimizando el uso de recursos. Se aconseja utilizar datos ordenados para optimizar las operaciones de cruce siempre que sea posible.Sin embargo, antes de decidir si ha de optimizarse una transformación de tipo Joiner utilizando esta técnica hemos de considerar el coste de ordenar los datos en términos de recursos y tiempo de procesamiento, ya que el mismo puede exceder el beneficio obtenido al utilizar datos ordenados. Por ejemplo, no sería aconsejable el uso de esta técnica de optimización en aquellos procesos donde existan diferencias notables en el volumen de datos de cada flujo de entrada. Si hemos de cruzar un flujo Master con 100.000 registros y un flujo Detail con 150.000.000 será aconsejable ajustar la memoria asignada a los caches de datos e índices de la transformación Joiner en lugar de ordenar los registros de ambos flujos.

3.2.6.8. Self-Join

52/201

PowerCenter 8.x – Normativa de Desarrollo

El uso de datos ordenados nos permite dividir un flujo de datos y volver a unir el mismo utilizando una transformación de tipo Joiner incluso si modificamos el número de registros en algún punto tras dividir el flujo original. Esta técnica se conoce como Self-Join. En el ejemplo siguiente utilizamos una transformación de tipo Source Qualifier para extraer de una tabla de clientes (CUSTOMER) aquellos registros que pertenezcan a clientes de tres estado de sur de E.E.U.U. (Florida, Georgia o Carolina del Sur).

Figura 34: Ejemplo de Self-Join Para este proceso de extracción necesitamos generar un fichero de salida por estado, incluyendo en cada registro información del cliente así como el número total de clientes en el estado. Una vez obtenidos los datos mediante nuestro Source Qualifier ordenaremos el flujo por la clave de cruce a utilizar con posterioridad, en este caso el código de estado, para lo cual hemos utilizado la transformacion de tipo Sorter srt_CUSTOMER_STATE, y dividiremos el flujo en dos. La transformación de tipo Aggregator agg_CUSTOMER_STATE_COUNT se utiliza para calcular el número de clientes en cada estado. La transformación de tipo Joiner jnr_CUSTOMER_STATE nos permite cruzar la información de cliente con el contador de clientes por estado que acabamos de calcular. Para que este cruce sea posible hemos de utilizar la opción Sorted Input en la transformación Joiner. El uso de esta técnica nos permite reducir el número de veces que hemos de procesar un origen de datos cuando necesitemos realizar cálculos a distintos niveles de agregación pero manteniendo los resultados en un mismo flujo. En nuestro ejemplo sería necesario leer dos veces de la tabla de clientes si no fuera posible utilizar datos ordenados para realizar los cálculos requeridos.

3.2.7. Lookup 3.2.7.1. Ficha Técnica

Lookup

53/201

PowerCenter 8.x – Normativa de Desarrollo

Propósito

Búsquedas sobre ficheros planos y fuentes relacionales

Nomenclatura

lkp_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Pasiva

Conectada/Desconectada

Conectada/Desconectada

Utiliza Caches

Sí

3.2.7.2. Propósito La transformación Lookup se utiliza para realizar búsquedas sobre ficheros planos y fuentes relacionales. Las propiedades de la transformación nos permiten definir una condición de búsqueda que especifica cómo han de compararse los registros proporcionados a la transformación desde el flujo de datos con los registros del fichero o tabla de referencia al realizar una operación de búsqueda. Si una transformación Lookup se asocia a una tabla relacional la extracción de datos de dicha fuente se realizará a través de una consulta SQL. PowerCenter generará una consulta SELECT por defecto sobre la tabla asociada. Las propiedades de la transformación nos permitirán modificar la consulta generada. Una misma transformación Lookup puede asociarse a múltiples tablas relacionales, siempre que éstas se encuentren en la misma base de datos. Si una transformación Lookup se asocia a un fichero plano éste será procesado en su totalidad. PowerCenter no genera SQL para extraer datos de ficheros planos. En el ejemplo siguiente utilizaremos una transformación de tipo Lookup para implementar un proceso de conversión de moneda. Nuestro proceso de carga utiliza como fuente un fichero plano con información sobre un conjunto de cuentas en Latinoamérica (f_CTA_SALDOS_MES_LATAM). Este fichero incluye el saldo medio mensual de cada cuenta en la moneda del país correspondiente. Para este proceso necesitamos cargar una tabla con el saldo medio de cada cuenta en euros (ODS_CTA_SALDOS_MES). El tipo de cambio a aplicar para cada moneda se encuentra en una tabla llamada ODS_TIPO_CAMBIO con la siguiente estructura:

ODS_TIPO_CAMBIO FECOTIZ Fecha Cotización CODMON Código Moneda DESMON Descripción Moneda CMBEUR Tipo Cambio - EUR/1 Unidad CMBMON Tipo Cambio - Unidades/1 EUR Se incluye a continuación un ejemplo de los datos almacenados en dicha tabla:

Divisa

Código

Reino Unido - Libra esterlina GBP

Fecha 03/13/2006

EUR/1 Unidad

Unidades/1 EUR

1,4507

0,6903

54/201

PowerCenter 8.x – Normativa de Desarrollo

México – Peso

Argentina – Peso

Chile – Peso

MXN

ARS

CLP

03/14/2006

1,4479

0,691

03/15/2006

1,4511

0,6893

03/16/2006

1,4517

0,689

03/17/2006

1,4472

0,6912

03/18/2006

1,4421

0,6936

03/19/2006

1,4414

0,6948

03/13/2006

0,07874

12,759

03/14/2006

0,07844

12,78

03/15/2006

0,07795

12,8526

03/16/2006

0,07798

12,8464

03/17/2006

0,07779

12,879

03/18/2006

0,07718

12,9868

03/19/2006

0,07688

13,0651

03/13/2006

0,2841

3,843

03/14/2006

0,2721

3,6784

03/15/2006

0,2715

3,6872

03/16/2006

0,2705

3,699

03/17/2006

0,2694

3,715

03/18/2006

0,2673

3,7433

03/19/2006

0,2792

3,9044

03/13/2006

0,001653

665,481

03/14/2006

0,001578

634,506

03/15/2006

0,001573

636,379

03/16/2006

0,001576

635,149

03/17/2006

0,001572

636,666

03/18/2006

0,001561

641,224

03/19/2006

0,001642

669,499

En nuestro proceso de carga utilizaremos en primer lugar una transformación de tipo Source Qualifier para extraer del fichero de entrada el saldo medio de cada cuenta así como la moneda de origen y la fecha de extracción. Emplearemos a continuación una transformación Lookup sobre la tabla de referencia ODS_TIPO_CAMBIO para obtener el tipo de cambio a aplicar en cada caso. Utilizaremos por último dicho tipo de cambio en una transformación Expression para realizar la conversión de moneda.

55/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 35: Ejemplo de Uso Transformación Lookup En nuestro ejemplo hemos definido tres tipos de puertos en la transformación Lookup lkp_ODS_TIPO_CAMBIO:


Input: Indica los valores por los cuales realizaremos la búsqueda en nuestra tabla de

referencia. En nuestro ejemplo la transformación Source Qualifier proporciona al Lookup la fecha de cotización (FECOTIZ_IN) y el código de moneda (CODMON_IN) para los cuales queremos obtener el tipo de cambio a euros (CMBEUR).


Lookup: Indica los puertos en nuestra tabla de referencia que pueden utilizarse como clave en la condición de búsqueda. En nuestro ejemplo hemos definido todas las columnas de la tabla ODS_TIPO_CAMBIO como posibles claves de búsqueda.


Output: Indica los puertos en la tabla de referencia que pueden definirse como resultado de la búsqueda. En nuestro ejemplo hemos definido como tal el tipo de cambio a euros (CMBEUR) y el tipo de cambio a la moneda original (CMBMON), aunque como podemos comprobar hemos conectado a la transformación Expression únicamente el tipo de cambio a euros, suficiente en este caso para realizar la conversión de moneda requerida.

56/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 36: Ejemplo de Uso Transformación Lookup – Tipos de Puertos Las propiedades de nuestra transformación Lookup nos permiten definir una condición de búsqueda que especifica cómo han de compararse los puertos de tipo Input de cada registro de entrada con los puertos de tipo Lookup de los registros almacenados en la transformación al realizar una operación de búsqueda. En nuestro caso buscaremos el tipo de cambio a euros (CMBEUR) por fecha de cotización (FECOTIZ=FECOTIZ_IN) y código de moneda (CODMON=CODMON_IN).

Figura 37: Lookup Condition

57/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 38: Transformación Lookup – Lookup SQL Nuestra transformación Lookup se encuentra asociada a una tabla relacional, por lo que al igual que en el caso de una transformación Source Qualifier la extracción de datos de dicha tabla de referencia se realizará a través de una consulta SQL. PowerCenter generará una consulta SELECT por defecto sobre la tabla de referencia. Dicha consulta incluye las columnas de la tabla de referencia asociadas a los siguientes puertos: •

Puertos de tipo Lookup utilizados en la condición de búsqueda, en nuestro caso FECOTIZ y CODMON.

•

Puertos de tipo Output conectados a otra transformación, en nuestro caso CMBEUR.

En nuestro ejemplo la transformación lkp_ODS_TIPO_CAMBIO utilizará la siguiente consulta para obtener los datos necesarios de la tabla de referencia: SELECT ODS_TIPO_CAMBIO.CMBEUR as CMBEUR, ODS_TIPO_CAMBIO.FECOTIZ as FECOTIZ, ODS_TIPO_CAMBIO.CODMON as CODMON FROM ODS_TIPO_CAMBIO Cuando la transformación Lookup recibe el primer registro del flujo de datos se lanza la consulta asociada sobre la tabla ODS_TIPO_CAMBIO y se almacenan los resultados en los caches de la transformación. Todas las operaciones de búsqueda posteriores se realizarán sobre los datos almacenados en cache en lugar de acceder a la tabla. Una vez obtenidos los datos de la tabla de referencia la transformación comienza a procesar los registros del flujo de datos. Para cada registro de entrada se buscará una correspondencia en los resultados almacenados en cache de acuerdo a la condición de búsqueda definida para la transformación. En nuestro ejemplo se comparan los puertos de tipo Input

58/201

PowerCenter 8.x – Normativa de Desarrollo

FECOTIZ_IN y CODMON_IN de cada registro de entrada con los puertos de tipo Lookup FECOTIZ y CODMON de cada registro almacenado en cache. Fig. 42 ilustra la operación de búsqueda para un registro de nuestro flujo de datos. En este caso queremos obtener el tipo de cambio para el peso mexicano (MXN) con fecha 13/03/2006. La transformación Lookup (a) buscará el valor correspondiente en los registros almacenados en cache (b) de acuerdo a la condición de búsqueda definida para la transformación (FECOTIZ=FECOTIZ_IN AND CODMON=CODMON_IN). Si se halla un registro con dichos valores (FECOTIZ=’13/03/2006’ AND CODMON=’MXN’) se asignará el tipo de cambio correspondiente a dicho registro al puerto de tipo Output CMBEUR (c). Si no existe ningún registro para dichos valores se asignará un valor NULL a este puerto.

Figura 39: Ejemplo Operación de Búsqueda

3.2.7.3. Lookup Condicional

En nuestro ejemplo hemos utilizado una transformación Lookup para cruzar los datos del fichero de entrada con los datos de la tabla de referencia de manera equivalente a una transformación de tipo Joiner. Para este proceso la conversión de moneda se ha de aplicar a todos los registros del fichero de entrada, por lo que la operación de búsqueda del tipo de cambio se realiza una vez por registro. En caso de que dicha operación de búsqueda no sea necesaria para todos los registros del flujo de datos es posible configurar nuestra transformación Lookup de forma que únicamente se realice la operación de búsqueda para aquellos registros que cumplan una determinada condición. Esta técnica se conoce como Lookup Condicional. En el ejemplo siguiente utilizaremos una transformación de tipo Lookup para implementar un proceso de conversión de moneda utilizando un lookup condicional. Nuestro proceso de carga utiliza como fuente un fichero plano que indica el saldo medio mensual de un conjunto de cuentas (f_CTA_SALMED_MES). El saldo medio mensual se facilita en moneda extranjera para un porcentaje reducido de cuentas y en euros o pesetas para la mayor parte de las

59/201

PowerCenter 8.x – Normativa de Desarrollo

mismas. Para este proceso necesitamos cargar una tabla con el saldo medio de cada cuenta en euros (ODS_CTA_SALMED_MES). En nuestro proceso de carga utilizaremos en primer lugar una transformación de tipo Source Qualifier para extraer del fichero de entrada el saldo medio de cada cuenta así como la moneda de origen y la fecha de extracción. Utilizaremos a continuación una transformación Expression para realizar la conversión de moneda. El cálculo de conversión a euros emplea una transformación Lookup sobre la tabla de referencia ODS_TIPO_CAMBIO para obtener el tipo de cambio a aplicar si el saldo medio mensual de la cuenta se facilita en moneda extranjera. Una transformación Lookup puede utilizarse en modo conectado o desconectado. En el ejemplo anterior nuestro Lookup se utilizaba en modo conectado, enlazando los puertos de entrada y salida requeridos con las transformaciones correspondientes. Para implementar un Lookup condicional emplearemos un Lookup en modo desconectado, sin enlaces con otras transformaciones. Un Lookup desconectado se usa del mismo modo que una función, permitiéndonos definir para el mismo uno o más parámetros de entrada y un único parámetro de salida.

Figura 40: Ejemplo de Uso Lookup Condicional – Tipos de Puertos De igual forma que en el ejemplo anterior, en nuestro nuevo proceso hemos definido tres tipos de puertos en la transformación Lookup lkp_ODS_TIPO_CAMBIO:


Input: Indica los parámetros de entrada de nuestro Lookup desconectado. En nuestro ejemplo la transformación Source Qualifier proporciona al Lookup la fecha de cotización (FECOTIZ_IN) y el código de moneda (CODMON_IN) para los cuales queremos obtener el tipo de cambio a euros (CMBEUR).


Lookup: Indica los puertos en nuestra tabla de referencia que pueden utilizarse como clave en la condición de búsqueda. En nuestro ejemplo hemos definido todas las columnas de la tabla ODS_TIPO_CAMBIO como posibles claves de búsqueda.


Output: Indica los puertos en la tabla de referencia que pueden definirse como resultado de la búsqueda. En nuestro ejemplo hemos definido como tal el tipo de cambio a euros (CMBEUR) y el tipo de cambio a la moneda original (CMBMON).

De forma adicional, en nuestro proceso utilizamos un nuevo tipo de puerto en la transformación Lookup lkp_ODS_TIPO_CAMBIO:

60/201

PowerCenter 8.x – Normativa de Desarrollo


Return: Indica el parámetro de salida del Lookup desconectado. Podemos seleccionar como puerto de tipo Return un único puerto de tipo Output dentro de nuestra transformación. En nuestro ejemplo hemos definido como tal el tipo de cambio a euros (CMBEUR).

La configuración de los parámetros restantes de la transformación lkp_ODS_TIPO_CAMBIO es independiente de su uso en modo conectado o desconectado. La operación de búsqueda funciona de la misma manera en ambos casos, variando únicamente la forma en que se invoca. En el caso de un Lookup en modo conectado, la operación de búsqueda se invoca de forma automática para cada registro de entrada que recibe la transformación. En el caso de un Lookup en modo desconectado, la operación de búsqueda se invoca de forma explícita desde una expresión. Tras configurar nuestro Lookup desconectado ya podemos utilizarlo en cualquier expresión del mismo modo que si de una función se tratara. El Expression Editor muestra la nueva transformación en la carpeta Lookups dentro de la opción Functions. Seleccione el Lookup deseado para obtener información sobre los parámetros de entrada y salida del mismo. Utilizaremos la sintaxis siguiente para invocar la operación de búsqueda desde cualquier expresión: :LKP.(, , ...)

Figura 41: Ejemplo de Uso Lookup Condicional – Lookup como Función

61/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 42: Ejemplo de Uso Lookup Condicional – Expresión Cambio de Moneda En nuestro ejemplo utilizaremos la siguiente expresión condicional en la transformación exp_CONVERSION_EURO para realizar el cambio de moneda: DECODE(CTAMON, -- Si SALMED_MES en euros no es necesaria conversión 'EUR', SALMED_MES, -- Si SALMED_MES en pesetas aplicar tipo de cambio fijo 'PTA', SALMED_MES / 166.386, -- Si SALMED_MES en moneda extranjera utilizaremos Lookup -- para obtener el tipo de cambio :LKP.LKP_ODS_TIPO_CAMBIO(FECPROC,CTAMON) ) La expresión se evalúa para cada registro en nuestro flujo de datos, invocándose la operación de búsqueda únicamente para aquellos registros donde el saldo medio mensual se proporcione en moneda extranjera. Supongamos que en nuestro ejemplo el fichero de entrada f_CTA_SALMED_MES contiene 500,000 registros, pero únicamente 10,000 registros donde el saldo medio mensual no se facilita en euros o pesetas. La utilización de esta técnica supone en este caso un ahorro de 480,000 operaciones de búsqueda.

3.2.7.4. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Lookup SQL Override: Disponible únicamente si la transformación se asocia a una tabla relacional. Si una transformación Lookup se asocia a una tabla relacional la extracción de datos de la misma se realizará a través de una consulta SQL. Este parámetro nos permite introducir directamente la consulta a utilizar en caso de que sea necesario modificar la consulta por defecto. Sección 3.2.7.9 describe en detalle el uso del parámetro Lookup SQL Override.


Lookup Table Name: Disponible únicamente si la transformación se asocia a una

tabla relacional. Indica el nombre de la tabla de referencia utilizada por la transformación. No es necesario especificar un valor para este parámetro si utilizamos el parámetro Lookup SQL Override para modificar la consulta por defecto asociada a la transformación.

62/201

PowerCenter 8.x – Normativa de Desarrollo


Lookup Caching Enabled: La transformación Lookup utiliza por defecto dos tipos de

caches temporales para optimizar las operaciones de búsqueda. En caso de que se determine que dichos caches no son necesarios utilizaremos este parámetro para deshabilitar la creación de los mismos. Sección 3.2.7.7 describe en detalle el uso opcional de caches en transformaciones de tipo Lookup.


Lookup Policy on Multiple Match: Determina el tratamiento de un registro de entrada

para el cual existan múltiples correspondencias de acuerdo a la condición de búsqueda definida para la transformación. Este parámetro nos permite indicar que se utilice como resultado la primera o última correspondencia o que se genere un error de transformación.


Lookup Condition: Condición de búsqueda que especifica cómo han de compararse los registros proporcionados a la transformación desde el flujo de datos con los registros del fichero o tabla de referencia al realizar una operación de búsqueda.


Connection Information: Disponible únicamente si la transformación se asocia a una

tabla relacional. Indica la conexión a utilizar para acceder a la tabla de referencia. Este parámetro nos permite seleccionar una de las conexiones de tipo relacional o aplicación definidas desde la herramienta cliente Workflow Manager, o especificar la variable de sesión $Source o $Target.


Source Type: Indica si la transformación se asocia a una tabla relacional o a un fichero plano de referencia.


Tracing Level: Nivel de detalle relativo a la transformación Lookup que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.


Lookup Cache Directory Name: Especifica el directorio utilizado para crear los

ficheros temporales de cache utilizados por la transformación. Por defecto dichos ficheros se crean en el directorio asignado a la variable de servidor $PMCacheDir. Si es necesario sobreescribir este valor compruebe que el directorio utilizado existe y dispone de espacio suficiente para crear dichos ficheros.


Lookup Cache Persistent: Disponible únicamente si se habilita la opción Lookup Caching Enabled. Indica si la transformación utiliza un cache persistente.


Lookup Data Cache Size: Memoria asignada al cache temporal de datos de la transformación. Por defecto la transformación asigna 2 MB de memoria a este cache.


Lookup Index Cache Size: Memoria asignada al cache temporal de índices de la transformación. Por defecto la transformación asigna 1 MB de memoria a este cache.


Cache File Name Prefix: Disponible únicamente si se habilitan las opciones Lookup Caching Enabled y Lookup Cache Persistent. Indica el prefijo a utilizar para los ficheros de cache permanente utilizados por la transformación. No incluir las extensiones .idx o .dat al asignar un valor a este parámetro.


Re-cache from Lookup Source: Disponible únicamente si se habilita la opción Lookup Caching Enabled.


Datetime Format: Disponible únicamente si una transformación Lookup se asocia a un fichero plano.


Thousand Separator: Disponible únicamente si una transformación Lookup se asocia a un fichero plano


Decimal Separator: Disponible únicamente si una transformación Lookup se asocia a un fichero plano.

63/201

PowerCenter 8.x – Normativa de Desarrollo


Case Sensitive String Comparisson: Indica si la transformación Lookup ha de

diferenciar entre mayúsculas y minúsculas al realizar cruces\comparar entre campos alfanuméricos.


Sorted Input: Disponible únicamente si una transformación Lookup se asocia a un fichero plano. Indica si el fichero de referencia a utilizar se encuentra ordenado por las columnas incluidas en la condición de búsqueda.

3.2.7.5. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Lookup desconectado cuando la operación de búsqueda haya de invocarse para un porcentaje reducido de registros.


Utilizar un Joiner en lugar de un Lookup para cruzar flujos de datos con volúmenes muy elevados.


Utilizar cache siempre que la operación de búsqueda haya de invocarse para un porcentaje superior al 10% de registros en nuestro flujo de datos.


No conectar a otras transformaciones más puertos de los necesarios para reducir el volumen de datos a mantener en cache.


Mantener todos los puertos en la transformación Lookup independientemente de si son utilizados o no. De esta forma facilitaremos futuros cambios al proceso de carga sin impacto alguno en el rendimiento del mismo.


Utilizar caches permanentes para datos estáticos o para procesos que utilicen la misma tabla o fichero de referencia.


Limitar en la medida de lo posible los datos a mantener en cache modificando la

consulta por defecto asociada al mismo para filtrar datos de la tabla de referencia que no sean necesarios.

3.2.7.6. Cálculo de Tamaño de Caches La transformación Lookup utiliza dos tipos de caches temporales para optimizar las operaciones de búsqueda. La transformación crea los siguientes tipos de cache:


Un cache temporal de índices (Lookup Index Cache) con las columnas utilizadas como clave en la condición de búsqueda.


Un cache temporal de datos (Lookup Data Cache) con las columnas definidas como resultado de la búsqueda.

Las propiedades de la transformación nos permiten parametrizar la memoria asignada a estos caches temporales. Si al procesar los datos la transformación no dispone de suficiente espacio para mantener en memoria dichos caches se crearán ficheros temporales para volcar a disco los datos que no pueda mantener en memoria. Es muy importante asignar memoria suficiente a estos caches para minimizar el acceso a disco, ya que esta operación ralentiza considerablemente el procesado de los datos.

64/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.7.6.1. Cálculo del Cache de Indices El cache de índices de una transformación de tipo Lookup almacena los puertos de tipo Lookup utilizados en la condición de búsqueda. Utilice la siguiente fórmula para calcular el tamaño del cache de índices de la transformación:

Lookup – Cálculo Cache de Indices # registros [( S tamaño columna) + 16] * 2

Columnas en Cache Puertos de tipo Lookup utilizados en la condición de búsqueda

En nuestro ejemplo la transformación de tipo Lookup, lkp_ODS_TIPO_CAMBIO, se emplea para implementar un proceso de conversión de moneda utilizando la tabla de referencia ODS_TIPO_CAMBIO para obtener el tipo de cambio a aplicar en cada caso. Esta transformación utiliza la propiedad Lookup Caching Enabled.

Figura 43: Ejemplo de Transformación Lookup para Cálculo de Cache de Indices Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de índices de la transformación:

Nombre Columna

Tipo Columna

Tipo de Datos

Tamaño

FECOTIZ

Puerto de tipo Lookup utilizados en la condición de búsqueda

Date/Time

24

CODMON

Puerto de tipo Lookup utilizados en la condición

String(3)

12

65/201

PowerCenter 8.x – Normativa de Desarrollo

de búsqueda TOTAL

36

En nuestro ejemplo la tabla asociada a la transformación lkp_ODS_TIPO_CLIENTE contiene 100,000 registros. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de índices de la transformación: 100,000 * (36 + 16) *2 = 10,400,000 Esta transformación requiere un tamaño de cache de índices de 10,400,000 bytes.

3.2.7.6.2. Cálculo del Cache de Datos

El cache de datos de una transformación de tipo Lookup almacena los puertos definidos como resultado de la operación de búsqueda. En el caso de los Lookups conectados, este cache almacenará los puertos de tipo Output conectados a otra transformación y no utilizados en la condición de búsqueda. En el caso de los Lookups desconectados, este cache almacenará el puerto de tipo Return de la transformación. Utilice la siguiente fórmula para calcular el tamaño mínimo del cache de datos de la transformación:

Lookup – Cálculo Cache de Datos

Columnas en Cache

# registros [( S tamaño columna) + 8] •

Para Lookups Conectados, Puertos de tipo Output conectados y no utilizados en la condición de búsqueda.

•

Para Lookups Desconectado, Puerto de tipo Return.

La siguiente transformación de tipo Lookup, lkp_ODS_TIPO_CAMBIO, se emplea para implementar un proceso de conversión de moneda utilizando la tabla de referencia ODS_TIPO_CAMBIO para obtener el tipo de cambio a aplicar en cada caso. Esta transformación utiliza la propiedad Lookup Caching Enabled.

66/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 44: Ejemplo de Transformación Lookup para Cálculo de Cache de Datos Utilizaremos los tamaños de columna indicados en la Tabla 6.1 para calcular el tamaño de registro en el cache de datos de la transformación lkp_ODS_TIPO_CAMBIO:

Nombre Columna CMBEUR

Tipo Columna Puerto de tipo Output conectado y no utilizado en la condición de búsqueda

Tipo de Datos

Tamaño

Decimal (15)

24

TOTAL

24

67/201

PowerCenter 8.x – Normativa de Desarrollo

Podemos comprobar que no utilizaremos CMBMON en el cálculo ya que aunque se trata de un puerto de tipo Output no se haya conectado a ninguna otra transformación. En nuestro ejemplo la tabla asociada a la transformación lkp_ODS_TIPO_CLIENTE contiene 100,000 registros. Utilice la siguiente fórmula para determinar el tamaño mínimo de los caches de datos de la transformación: 100,000 * (24 + 8) = 3,200,000 Esta transformación requiere un tamaño de cache de datos de 3,200,000 bytes.

3.2.7.7. Uso Opcional de Caches La transformación Lookup utiliza por defecto dos tipos de caches temporales para optimizar las operaciones de búsqueda. En caso de que se determine que dichos caches no son necesarios es posible modificar el parámetro Lookup Caching Enabled de forma que las operaciones de búsqueda se ejecuten directamente sobre la tabla de referencia. En nuestro ejemplo hemos utilizado una transformación de tipo Lookup para implementar un proceso de conversión de moneda. Utilizaremos el parámetro Lookup Caching Enabled para deshabilitar la creación de caches temporales en el mismo.

Figura 45: Ejemplo de Uso Lookup – Caches Deshabilitados Fig. 49 ilustra la operación de búsqueda para un registro del flujo de datos en nuestra transformación Lookup una vez deshabilitado el uso de caches. En este caso queremos obtener el tipo de cambio para el peso mexicano (MXN) con fecha 13/03/2006. La transformación Lookup (a) lanzará la consulta SELECT asociada a la transformación directamente sobre la tabla de referencia (b) añadiendo a la misma una cláusura WHERE con la condición de búsqueda definida para la transformación (FECOTIZ=FECOTIZ_IN AND CODMON=CODMON_IN). Si se halla un registro con dichos valores (FECOTIZ=’13/03/2006’ AND CODMON=’MXN’) se asignará el tipo de cambio correspondiente a dicho registro al puerto de tipo Output CMBEUR (c). Si no existe ningún registro para dichos valores se asignará un valor NULL a este puerto.

68/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 46: Ejemplo Operación de Búsqueda – Caches Deshabilitados Se recomienda habilitar el uso de caches siempre que sea posible para optimizar el rendimiento de las operaciones de búsqueda. Si no se utilizan caches cada operación de búsqueda lanza una consulta separada sobre la tabla de referencia, con la consiguiente penalización en los tiempos de procesamiento. Esta opción ha de reservarse para aquellos casos en los que sea inviable almacenar el volumen de datos necesario en los caches temporales de la transformación. Para determinar cuándo deshabilitar el uso de caches en una transformación Lookup podemos utilizar el siguiente procedimiento: 1. Utilizar la transformación Lookup en un mapping. 2. Seleccionar un conjunto de datos del origen. 3. Ejecutar el mapping con la cache del Lookup deshabilitada y guardar el log de sesión. 4. Ejecutar el mapping con la cache del Lookup habilitada y guardar el log de sesión. 5. Revisar el log de sesión con cache y determinar cuánto tiempo tardan en generarse los ficheros de cache. LS=tiempo Lookup en segundos. 6. Revisar el log de sesión sin cache y determinar cuántos registros se insertan por segundo. NRS= tiempo de carga/nº de registros insertados. 7. Revisar el log de sesión con cache y determinar cuántos registros se insertan por segundo. CRS= tiempo de carga/nº de registros insertados. 8. Usar la siguiente fórmula para determinar el punto de equilibrio, es decir, el punto a partir del cual se haría necesario el uso de la cache. (LS*NRS*CRS)/(CRS-NRS) = X

69/201

PowerCenter 8.x – Normativa de Desarrollo

Si X < nº de registros en origen, deshabilitar el uso de caches. Si X > nº de registros en origen, utilizar caches. La opción Lookup SQL Override se encuentra disponible únicamente cuando la propiedad Lookup Caching Enabled se habilita para la transformación. La opción Lookup Caching Enabled se encuentra disponible tanto en Lookups en modo conectado como desconectado. Es posible utilizar la opción Lookup SQL Override para modificar la consulta por defecto asociada a la transformación únicamente si el uso de caches se encuentra habilitado. El uso de dicha opción se detalla en la sección 3.2.7.9. Si una transformación Lookup se asocia a un fichero plano esta opción no se encuentra disponible. PowerCenter siempre utiliza caches cuando un Lookup se asocia a un fichero plano.

3.2.7.8. Uso de Caches Persistentes Supongamos que en nuestro caso la transformación Lookup lkp_ODS_TIPO_CAMBIO, utilizada para implementar el proceso de conversión de moneda descrito, se define como reutilizable a nivel global. Incluiremos instancias de dicha transformación reutilizable en cualquier proceso de carga que necesite realizar una conversión de moneda. Por defecto cada instancia de esta transformación creará y gestionará su propio cache temporal, accediendo para ello a la tabla de referencia ODS_TIPO_CAMBIO en tiempo de ejecución. Supongamos ahora que dicha tabla de referencia se actualiza únicamente una vez al día. Si el acceso a esta tabla supone una penalización considerable en términos de tiempo de procesamiento podemos utilizar caches persistentes para elimina la necesidad de acceder a base de datos cada vez que utilicemos una instancia de esta transformación. Dado que los datos de la tabla de referencia se actualizan una vez al día podemos configurar nuestros procesos de forma que únicamente el primero a ejecutar tras la actualización de esta tabla recree los caches sobre la misma accediendo directamente a la base de datos. El resto de procesos se configuraría para utilizar los caches persistentes que se mantienen en el servidor de PowerCenter.

70/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 47: Configuración de Cache Persistente …


Lookup Caching Enabled: La transformación Lookup utiliza por defecto dos tipos de

caches temporales para optimizar las operaciones de búsqueda. En caso de que se determine que dichos caches no son necesarios utilizaremos este parámetro para deshabilitar la creación de los mismos. Sección 3.2.7.7 describe en detalle el uso opcional de caches en transformaciones de tipo Lookup.


Lookup Cache Persistent: Disponible únicamente si se habilita la opción Lookup Caching Enabled. Indica si la transformación utiliza un cache persistente.


Cache File Name Prefix: Disponible únicamente si se habilitan las opciones Lookup Caching Enabled y Lookup Cache Persistent. Indica el prefijo a utilizar para los ficheros de cache permanente utilizados por la transformación. No incluir las extensiones .idx o .dat al asignar un valor a este parámetro. Asignar un valor a este parámetro si deseamos reutilizar un mismo cache persistente en distintas sesiones.


Re-cache from Lookup Source: Considerar espacio en disco requerido para mantener los caches permanentes en el servidor de PowerCenter.

3.2.7.9. Uso del Parámetro Lookup SQL Override Si una transformación Lookup se asocia a una tabla relacional la extracción de datos de la misma se realizará a través de una consulta SQL. PowerCenter generará una consulta SELECT por defecto sobre la tabla de referencia incluyendo las columnas asociadas a los siguientes puertos: •

Puertos de tipo Lookup utilizados en la condición de búsqueda.

•

Puertos de tipo Output conectados a otra transformación si el Lookup se utiliza en modo conectado o puerto de tipo Return si el Lookup se utiliza en modo desconectado.

Si es necesario modificar la consulta generada por defecto podemos utilizar el parámetro Lookup SQL Override para introducir directamente la consulta a utilizar. En el ejemplo siguiente utilizaremos una transformación de tipo Lookup en modo desconectado para implementar un proceso de conversión de moneda. Nuestra transformación Lookup utiliza la tabla de referencia ODS_TIPO_CAMBIO para obtener el tipo de cambio a euros (CMBEUR) a partir del código de moneda (CODMON_IN). Utilizaremos el parámetro Lookup SQL Override para obtener únicamente el tipo de cambio vigente a partir de la fecha del sistema.

71/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 48: Uso de transformación Lookup con SQL Override PowerCenter generará una consulta SELECT por defecto para nuestra transformación Lookup sobre la tabla de referencia ODS_TIPO_CAMBIO incluyendo las columnas asociadas a los siguientes puertos: •

Puertos de tipo Lookup utilizados en la condición de búsqueda, en nuestro caso CODMON.

•

Puerto de tipo Return, en nuestro caso CMBEUR.

En nuestro ejemplo hemos utilizado el parámetro Lookup SQL Override para modificar manualmente la consulta por defecto a utilizar por la transformación, añadiendo una cláusula WHERE para filtrar por fecha de sistema: SELECT ODS_TIPO_CAMBIO.CMBEUR as CMBEUR, ODS_TIPO_CAMBIO.CODMON as CODMON FROM ODS_TIPO_CAMBIO WHERE FECOTIZ = TRUNC(SYSDATE) El parámetro Lookup SQL Override nos permite asociar a nuestra transformación Lookup cualquier consulta SELECT válida sobre la base de datos en la que se encuentre la tabla de referencia. Se indican a continuación varios puntos a tener en cuenta al modificar la consulta por defecto asociada a una transformación Lookup:


Renombrar cada columna en nuestra consulta con un alias (SELECT

AS ) para que el nombre de cada columna coincida con el nombre del puerto correspondiente en la transformación.


Verificar que el tipo de datos de cada columna incluida en nuestra consulta es compatible con el tipo de datos del puerto correspondiente en la transformación.

72/201

PowerCenter 8.x – Normativa de Desarrollo


Si la consulta modificada contiene puertos que no existen en la tabla de referencia

original, añadir los mismos a la transformación de forma manual como puertos de tipo Lookup. Definir dichos puertos como de tipo Output de forma adicional si han de incluirse en el resultado de la búsqueda.


El valor asignado a la propiedad Lookup Table Name no aplica una vez modificada la consulta por defecto asociada a la transformación. La consulta modificada puede incluir cruces entre distintas tablas.

En una nueva versión de nuestro ejemplo modificaremos nuestra transformación Lookup para obtener a partir del código de moneda (CODMON_IN) el tipo de cambio a euros vigente (CMBEUR) así como la máxima cotización de la moneda (MAX_CMBEUR) y la fecha de registro de la misma (MAX_FECOTIZ). En nuestro ejemplo utilizamos dos puertos, MAX_CMBEUR y MAX_FECOTIZ, que no existen en la tabla de referencia ODS_TIPO_CAMBIO. En este caso será necesario añadir ambos puertos de forma manual a nuestra transformación como puertos de tipo Lookup, asignando a cada puerto el tipo de datos adecuado en cada caso. De forma adicional definiremos ambos campos como de tipo Output, ya que deseamos incluirlos en el resultado de la búsqueda.

Figura 49: Uso de transformación Lookup con SQL Override Tras configurar nuestro Lookup de la manera indicada utilizaremos nuevamente el parámetro Lookup SQL Override para asignar la consulta a utilizar por la transformación: SELECT a.CODMON as CODMON, b.CMBEUR as CMBEUR, a.FECOTIZ as MAX_FECOTIZ, a.CMBEUR as MAX_CMBEUR FROM ODS_TIPO_CAMBIO a, ODS_TIPO_CAMBIO b WHERE a.CODMON = b.CODMON AND

73/201

PowerCenter 8.x – Normativa de Desarrollo

b.FECOTIZ = TRUNC(SYSDATE) AND a.CMBEUR = ( SELECT MAX(CMBEUR) FROM ODS_TIPO_CAMBIO c WHERE a.CODMON = c.CODMON GROUP BY c.CODMON ) La opción Lookup SQL Override se encuentra disponible únicamente cuando la propiedad Lookup Caching Enabled se habilita para la transformación. Si una transformación Lookup se asocia a un fichero plano éste será procesado en su totalidad. PowerCenter no genera SQL para extraer datos de ficheros planos.

3.2.8. Update Strategy 3.2.8.1. Ficha Técnica

Update Strategy Propósito

Implementación de estrategia de carga a nivel de mapping para destinos relacionales

Nomenclatura

upd_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.8.2. Propósito PowerCenter nos permite definir la estrategia de carga para un destino relacional a dos niveles distintos:


A nivel de sesión: las propiedades de la sesión nos permiten indicar que todos los

registros han de tratarse de la misma forma al aplicarse a destinos relacionales, ya sea para insertar, actualizar o eliminar registros, o que por el contrario la operación a realizar para cada registro se controla desde el mapping asociado a la misma.


A nivel de mapping: la transformación Update Strategy nos permite controlar a nivel

de registro la operación a realizar en destino. Cada registro puede marcarse para su inserción, actualización, eliminación o rechazo.

La transformación Update Strategy se utiliza para implementar a nivel de mapping la estrategia de carga para destinos relacionales. Las propiedades de la transformación nos permiten definir una expresión condicional que será evaluada para cada registro a procesar.

74/201

PowerCenter 8.x – Normativa de Desarrollo

La transformación marcará cada registro según la operación a realizar en la tabla de destino dependiendo del resultado de evaluar dicha expresión condicional.

3.2.8.3. Estrategias de Carga a Nivel de Sesión PowerCenter permite indicar a nivel de sesión que todos los registros han de tratarse de la misma forma al aplicarse a destinos relacionales. Para ello utilizaremos la opción Treat Source Rows as.

Figura 50: Opción ‘Treat source rows as’ configurada como Insert. Este parámetro indica que la estrategia de carga (Insert, Update, o Delete) se implementa a nivel de sesión Los siguientes tipos de estrategias de carga pueden definirse a nivel de sesión:


Inserción de registros Opción por defecto. Seleccione Insert para la opción Treat Source Rows as. Seleccione la opción Insert para todos los destinos de la sesión. PowerCenter genera una consulta SQL de tipo INSERT para cada registro en destino.


Actualización de registros Seleccione Update para la opción Treat Source Rows as. Seleccione la opción Update para todos los destinos de la sesión. PowerCenter genera una consulta SQL de tipo UPDATE para cada registro en destino.


Eliminación de registros Seleccione Delete para la opción Treat Source Rows as. Seleccione la opción Delete para todos los destinos de la sesión. PowerCenter genera una consulta SQL de tipo DELETE para cada registro en destino. La definición de una estrategia de carga a nivel de sesión nos permite realizar un único tipo de operación sobre todos los destinos relacionales de la misma. Si dentro de una misma

75/201

PowerCenter 8.x – Normativa de Desarrollo

sesión es necesario realizar distintos tipos de operaciones será necesario implementar dicha estrategia de carga a nivel de mapping.

3.2.8.4. Estrategias de Carga a Nivel de Mapping Si en un proceso de carga es necesario realizar distintas operaciones sobre un mismo destino relacional será necesario implementar nuestra estrategia de carga a nivel de mapping. Para ello configuraremos la opción Treat Source Rows as a nivel de sesión como Data Driven, incluyendo en nuestro mapping las transformaciones de tipo Update Strategy necesarias para marcar cada registro según la operación a realizar en la tabla de destino.

Figura 51: Opción ‘Treat source rows as’ configurada como Data Driven. Este parámetro indica que la estrategia de carga se implementa a nivel de mapping Las propiedades de la transformación Update Strategy nos permiten definir una expresión condicional que será evaluada para cada registro a procesar. La transformación marcará cada registro según la operación a realizar en la tabla de destino dependiendo del resultado de evaluar dicha expresión condicional. Dentro de esta expresión utilizaremos las constantes indicadas a continuación para marcar cada registro de acuerdo a la operación que sea requerida en destino:

Operación en Destino

Constante

Consulta SQL

Registro a insertar

DD_INSERT

INSERT

Registro a actualizar

DD_UPDATE

UPDATE

Registro a eliminar

DD_DELETE

DELETE

Registro a rechazar

DD_REJECT

N/A

76/201

PowerCenter 8.x – Normativa de Desarrollo

En el ejemplo siguiente implementaremos un proceso de carga incremental donde utilizaremos transformaciones de tipo Update Strategy para especificar la operación a realizar para cada registro en destino. Nuestro proceso de carga utiliza como fuente un fichero plano con información de clientes (f_CLIENTES_MMYYY) que se extrae mensualmente de un sistema operacional. Emplearemos este fichero para actualizar una tabla de clientes en nuestro datamart (ODS_CLIENTES). Nuestro proceso compara los registros de cliente en destino con la información contenida en el fichero de origen, insertando los registros pertenecientes a nuevos clientes que no se encuentren en el datamart y actualizando los registros de cliente cuya información haya cambiado. En nuestro proceso de carga utilizaremos en primer lugar una transformación de tipo Source Qualifier para extraer del fichero de entrada la información de cada cliente tal y como aparece en nuestro sistema origen. Emplearemos a continuación una transformación Lookup sobre la tabla de destino ODS_CLIENTES para obtener la información de cada cliente tal y como aparece en nuestro datamart.

Figura 52: Ejemplo de Carga Incremental – Múltiples Transformaciones Update Strategy Una vez obtenido el registro de cada cliente tanto del fichero de origen como de la tabla de destino utilizaremos la transformación de tipo Router rtr_INSERT_OR_UPDATE para comparar ambos y determinar qué operación se ha de realizar en destino. Definiremos dos grupos distintos en dicha transformación, cada uno asociado a una condición de filtrado:


Insert, para aquellos registros de cliente que no existen en la tabla de destino (IsNull(CIF_lkp)).


Update, para aquellos registros de cliente que existen en la tabla de destino y que

presentan alguna diferencia con los registros en origen (NOT IsNull(CIF_lkp) AND (NOMBRE != NOMBRE_lkp OR DIRECCION != DIRECCION_lkp OR CP != CP_lkp OR LOCALIDAD != LOCALIDAD_lkp OR PROVINCIA != PROVINCIA_lkp OR COMUNIDAD != COMUNIDAD_lkp OR TELEFONO != TELEFONO_lkp OR FAX != FAX_lkp)).

Tras definir dichos grupos comprobaremos que en la trasformación se crean de forma automática dos grupos adicionales:


Input: Grupo de entrada utilizado para proporcionar registros a la transformación.

77/201

PowerCenter 8.x – Normativa de Desarrollo


Default: Grupo de salida al cual pertenecerán todos los registros que no cumplan la condición de filtrado de ningún otro grupo. En nuestro caso este grupo incluye los registros de cliente que existen en la tabla de destino y que no presentan ninguna diferencia con los registros en origen, para los cuales no será necesario realizar ninguna operación.

Nuestro proceso de carga utilizará por último dos transformaciones de tipo Update Strategy para marcar los registros como inserciones o actualizaciones.


upd_INSERT, asociada al grupo Insert de la transformación Router. Asignaremos la

constante DD_INSERT a la propiedad Update Strategy Expression para marcar estos registros como inserciones. PowerCenter genera una consulta SQL de tipo INSERT para cada registro en destino.

Figura 53: Transformación upd_INSERT


upd_UPDATE, asociada al grupo Update de la transformación Router. Asignaremos

la constante DD_UPDATE a la propiedad Update Strategy Expression para marcar estos registros como actualizaciones. PowerCenter genera una consulta SQL de tipo UPDATE para cada registro en destino.

78/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 54: Transformación upd_UPDATE La sesión asociada al mapping de carga incremental en nuestro ejemplo se configura con la opción Data driven para el parámetro Treat source rows. Dicha configuración indica que hemos utilizado transformaciones de tipo Update Strategy en nuestro mapping para marcar cada registro según la operación a realizar en la tabla de destino.

3.2.8.5. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Update Strategy Expression: Expresión condicional que será evaluada para cada registro a procesar. La transformación marcará cada registro según la operación a realizar en la tabla de destino dependiendo del resultado de evaluar dicha expresión condicional. Dentro de esta expresión utilizaremos una de las constantes disponibles (DD_INSERT, DD_UPDATE, DD_DELETE, DD_REJECT) para marcar cada registro.


Forward Rejected Rows: Indica si la transformación mantiene o elimina directamente

del flujo de datos los registros marcados como rechazados en la misma. Si seleccionamos esta opción PowerCenter incluirá los registros rechazados en el log de sesión y en el fichero de registros rechazados (.bad) generado para el destino correspondiente. Si no seleccionamos esta opción PowerCenter incluirá los registros rechazados únicamente en el log de sesión. Por defecto dicha opción se encuentra habilitada.


Tracing Level: Nivel de detalle relativo a la transformación Update Strategy que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.

3.2.8.6. Tratamiento de Registros Rechazados La transformación Update Strategy permite el marcado de registros como rechazados para su eliminación del flujo de datos. Es importante comprender el tratamiento que dichos registros reciben en PowerCenter en comparación a aquellos registros filtrados a través de transformaciones de tipo Filter o Router. En una nueva versión de nuestro ejemplo utilizaremos la transformación de tipo Update Strategy upd_INSERT_UPDATE_REJECT para realizar directamente la comparación entre el registro de cada cliente del fichero de origen y de la tabla en nuestro datamart y determinar

79/201

PowerCenter 8.x – Normativa de Desarrollo

qué operación se ha de realizar en destino. Los registros de cliente que existen en la tabla de destino y que no presentan ninguna diferencia con los registros en origen, para los cuales no será necesario realizar ninguna operación, se marcarán como rechazados para su eliminación del flujo de datos.

Figura 55: Ejemplo de Carga Incremental – Una Única Transformación Update Strategy Nuestra transformación upd_INSERT_UPDATE_REJECT utiliza la siguiente expresión condicional: IIF(IsNull DD_INSERT, IIF(NOMBRE != NOMBRE_lkp OR DIRECCION != IIF IsNull(CIF_lkp), IsNull IIF DIRECCION_lkp OR CP != CP_lkp OR LOCALIDAD != LOCALIDAD_lkp OR PROVINCIA != PROVINCIA_lkp OR COMUNIDAD != COMUNIDAD_lkp OR TELEFONO != TELEFONO_lkp OR FAX != FAX_lkp), DD_UPDATE, DD_REJECT) Dicha expresión define tres grupos distintos de registros, de acuerdo al tratamiento que se desea para los mismos:


Registros a insertar, marcados como DD_INSERT, para aquellos registros de cliente que no existen en la tabla de destino (IsNull(CIF_lkp)).


Registros a actualizar, marcados como DD_UPDATE, para aquellos registros de

cliente que existen en la tabla de destino y que presentan alguna diferencia con los registros en origen (NOT IsNull(CIF_lkp) AND (NOMBRE != NOMBRE_lkp OR DIRECCION != DIRECCION_lkp OR CP != CP_lkp OR LOCALIDAD != LOCALIDAD_lkp OR PROVINCIA != PROVINCIA_lkp OR COMUNIDAD != COMUNIDAD_lkp OR TELEFONO != TELEFONO_lkp OR FAX != FAX_lkp)).


Registros a rechazar, marcados como DD_REJECT, para aquellos registros de

cliente que existen en la tabla de destino y que no presentan ninguna diferencia con los registros en origen (NOT IsNull(CIF_lkp) AND (NOMBRE = NOMBRE_lkp AND DIRECCION = DIRECCION_lkp AND CP = CP_lkp AND LOCALIDAD = LOCALIDAD_lkp AND PROVINCIA = PROVINCIA_lkp AND COMUNIDAD = COMUNIDAD_lkp AND TELEFONO = TELEFONO_lkp AND FAX = FAX_lkp)).

En nuestro ejemplo hemos decidido marcar como rechazados aquellos registros de cliente que existen en la tabla de destino y que no presentan ninguna diferencia con los registros en origen. Dichos registros no requieren de ninguna operación en destino. Estos registros

80/201

PowerCenter 8.x – Normativa de Desarrollo

pertenecían al grupo de salida Default en la transformación de tipo rtr_INSERT_OR_UPDATE utilizada en la versión original del proceso de carga.

Router

Utilizaremos la opción Forward Rejected Rows para indicar si la transformación mantiene o elimina directamente del flujo de datos los registros marcados como rechazados en la misma:


Si seleccionamos esta opción PowerCenter incluirá los registros rechazados en el log

de sesión y en el fichero de registros rechazados generado para el destino ODS_CLIENTES.


Si no seleccionamos esta opción PowerCenter incluirá los registros rechazados

únicamente en el log de sesión. En nuestro caso deshabilitamos dicha opción para que los registros rechazados se incluyan únicamente en el log de la sesión.

La opción ‘Stop on errors’, utilizada para establecer un límite de errores no críticos permitidos a nivel de sesión antes de que PowerCenter marque la misma como fallida, incluirá o no los registros rechazados utilizando una transformación de tipo Update Strategy en el cómputo total de errores de sesión dependiendo del uso de la opción Forward Rejected Rows:


Si seleccionamos la opción Forward Rejected Rows para incluir los registros

rechazados en el log de sesión y en el fichero de registros rechazados generado para el destino, cada registro rechazado se trata como un error en destino y se incluye en el cómputo total de errores de sesión cuyo límite establecemos a través de la opción ‘Stop on Errors’.


Si no seleccionamos la opción Forward Rejected Rows para incluir los registros

rechazados únicamente en el log de sesión, los registros rechazados simplemente se eliminan del flujo de datos sin incluirse en el cómputo total de errores de sesión.

Sección 3.3.4.2 describe en detalle el uso de la opción ‘Stop on errors’. Si comparamos ambas versiones de nuestro proceso encontramos las siguientes diferencias:


En la versión original del proceso aquellos registros para los cuales no es necesario

realizar ninguna operación en destino se dirigen al grupo de salida Default en la transformación Router. Dicho grupo de salida no se conecta a ninguna otra transformación, por lo que estos registros simplemente se filtran del flujo de datos sin que quede registro de los mismos ni en el log de ejecución de la sesión ni en el fichero de registros rechazados generado para cada destino.


En la versión modificada hemos marcado estos registros como rechazados utilizando

una transformación de tipo Update Strategy. Dependiendo del uso de la opción Forward Rejected Rows estos registros se eliminan del flujo de datos registrándose en el log de ejecución de la sesión y opcionalmente en el fichero de registros rechazados generado para el destino.

Dependiendo del volumen de datos a tratar, incluir los registros rechazados en el log de ejecución puede afectar negativamente al rendimiento de la sesión. En la nueva versión de nuestro ejemplo es probable que el número de registros sin cambios que no requieran de ninguna operación en destino supere el número de registros a insertar o modificar.Se recomienda que el uso de esta opción se reserve para la captura de excepciones puntuales, utilizando transformaciones de tipo Filter o Router en caso de requerir un simple filtrado de registros que cumplan una determinada condición.

3.2.8.7. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Considerar estrategias alternativas al uso de la opción DD_REJECT para capturar

errores de validación de datos si es posible que se detecte un número elevado de los mismos. Estos registros rechazados se incluyen en el log de ejecución de la sesión y

81/201

PowerCenter 8.x – Normativa de Desarrollo

opcionalmente en el fichero de registros rechazados generado para el destino correspondiente, con el consiguiente impacto en el rendimiento del proceso.


Separar las operaciones de inserción, actualización y borrado sobre un mismo destino para facilitar su monitorización. Utilizar una instancia separada del mismo destino dentro del mapping para cada tipo de operación. La siguiente figura muestra la ventana Properties, accesible desde la herramienta cliente Workflow Monitor, para una ejecución de la versión incial de nuestro ejemplo de carga incremental. Dado que utilizamos una instancia de ODS_CLIENTES para cada tipo de operación es sencillo visualizar cuántos registros se insertaron y cuántos se actualizaron en la ejecución del proceso.

Figura 56: Ejecución de Carga Incremental – Instancias Separadas de ODS_CLIENTES por Operación


Evitar expresiones complejas en la expresión condicional. Si es necesario, calcular el

resultado de evaluar la condición como paso previo en una transformación de tipo Expression, utilizando un campo de salida de tipo integer o boolean con dicha expresión condicional. Enlazar dicho campo con la transformación Update Strategy y evaluar el mismo en la expresión condicional. De forma alternativa podemos utilizar una transformación de tipo Router con un grupo separado por cada tipo de operación a realizar en destino.


Utilizar la estrategia de carga incremental descrita en el ejemplo en lugar de la opción Update else Insert a nivel de sesión para asegurar el óptimo rendimiento de la misma.

3.2.9. Router 3.2.9.1. Ficha Técnica

Router Propósito

Filtrado condicional de datos utilizando múltiples condiciones

Nomenclatura

rtr_[rl,rg]

82/201

PowerCenter 8.x – Normativa de Desarrollo

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.9.2. Propósito La transformación Router se utiliza para aplicar múltiples condiciones de filtrado sobre un flujo de datos, permitiéndonos dividir el mismo en varios subflujos en base a que los registros cumplan una condición u otra. Este tipo de transformación nos permite definir una serie de grupos y asociar a cada grupo una expresión condicional que será evaluada para cada registro a procesar. La transformación dirigirá cada registro a uno u otro grupo dependiendo de si cumple o no la condición de filtrado asociada al mismo. La transformación Router funciona de una manera equivalente a un conjunto de transformaciones de tipo Filter. En el ejemplo siguiente utilizamos una transformación de tipo Source Qualifier para extraer de una tabla de clientes (CUSTOMER) aquellos registros que pertenezcan a clientes de tres estado de sur de E.E.U.U. (Florida, Georgia o Carolina del Sur). Para este proceso de extracción necesitamos generar un fichero de salida por estado. Utilizaremos una transformación Router para dividir el flujo de datos en tres grupos de registros en base al estado de residencia de cada cliente. Cada uno de los grupos de clientes se conectará a un destino distinto.

Figura 57: Ejemplo de Uso de Transformación Router

83/201

PowerCenter 8.x – Normativa de Desarrollo

En nuestro ejemplo hemos utilizado la transformación de tipo Router rtr_CUSTOMER_STATE para definir tres grupos distintos, cada uno asociado a una condición de filtrado:


CUSTOMER_FL, para aquellos clientes que residan en Florida (CUSTOMER_STATE = ‘FL’).


CUSTOMER_GA,

para aquellos (CUSTOMER_STATE = ‘GA’).

clientes

que

residan

en

Georgia


CUSTOMER_FL, para aquellos clientes que residan en Carolina del Sur (CUSTOMER_STATE = ‘SC’).

Una vez definidos dichos grupos comprobaremos que en la trasformación se crean de forma automática dos grupos adicionales:


Input: Grupo de entrada utilizado para proporcionar registros a la transformación.
Default: Grupo de salida al cual pertenecerán todos los registros que no cumplan la condición de filtrado de ningún otro grupo.

3.2.9.3. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Groups: Grupos de salida en los cuales deseamos dividir nuestro flujo de datos. Cada

grupo se asocia a una condición de filtrado que será evaluada para todos los registros del flujo.


Tracing Level: Nivel de detalle relativo a la transformación Router que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.

3.2.9.4. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Si es necesario dividir nuestro flujo de datos aplicando múltiples condiciones de filtrado al mismo utilizar siempre que sea posible una transformación de tipo Router en lugar de varias transformaciones de tipo Filter. Cada transformación Filter ha de procesar el flujo de datos completo, mientras que la transformación Router procesará el flujo de datos una única vez para todas las condiciones de filtrado.


Evitar expresiones complejas en la condición de filtrado asociada a cada grupo. Si es

necesario, calcular el resultado de evaluar la condición de filtrado de cada grupo como paso previo en una transformación de tipo Expression, asignando el valor de dicha evaluación a un campo de salida de tipo integer o boolean. Enlazar dichos campos con la transformación Router y evaluar el campo correspondiente en la condición de filtrado de cada grupo.


Utilizar un nombre descriptivo para cada grupo definido en la transformación Router.

Si como en nuestro ejemplo cada grupo se asocia a una instancia de un mismo destino, renombrar el destino asociado a cada grupo para que sea sencillo determinar a simple vista la relación entre los mismos.


Los grupos no son excluyentes entre sí a menos que las condiciones asociadas a los mismos lo sean. Un mismo registro puede pertenecer a más de un grupo.


Los registros que no cumplan ninguna de las condiciones de filtrado asociadas a cada grupo pertenecen al grupo Default.

84/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.10. Sequence Generator 3.2.10.1. Ficha Técnica

Sequence Generator Propósito Nomenclatura

seq_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Pasiva

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.10.2. Propósito … 3.2.10.3. Parametrización … 3.2.10.4. Best Practices …

3.2.11. Union 3.2.11.1. Ficha Técnica

Union Propósito

Unión de flujos de datos heterogéneos

Nomenclatura

un_[rl,rg]

Reutilización

Reutilizable/No Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

No

85/201

PowerCenter 8.x – Normativa de Desarrollo

3.2.11.2. Propósito La transformación Union se utiliza para unir registros de orígenes distintos en un único flujo de datos. La transformación Union funciona de una manera equivalente a la cláusula UNION ALL en lenguaje SQL, con la excepción de que los datos a unir pueden tener su origen en fuentes de distinto tipo. Al igual que la cláusula UNION ALL, la transformación Union no elimina aquellos registros duplicados que puedan resultar una vez unidos los distintos orígenes de datos. La transformación Union funciona de manera opuesta a la transformación de tipo Router. En el ejemplo siguiente unimos los registros que pertenezcan a clientes de tres estados del sur de E.E.U.U (Florida, Georgia o Carolina del Sur) en un único fichero de destino. Para este proceso de carga disponemos de un fichero de origen separado para cada estado. Utilizaremos una transformación Union para unir los tres grupos de registros en un mismo flujo de datos.

Figura 58: Ejemplo de Uso de Transformación Union En nuestro ejemplo hemos utilizado la transformación de tipo Union un_CUSTOMER_SOUTH para definir tres grupos de entrada distintos, cada uno asociado a un fichero de origen:

86/201

PowerCenter 8.x – Normativa de Desarrollo


CUSTOMER_FL, para aquellos clientes que residan en Florida (fichero f_CUSTOMER_FL).


CUSTOMER_GA, para aquellos clientes que residan en Georgia (fichero f_CUSTOMER_GA).


CUSTOMER_SC, para aquellos clientes que residan en Carolina del Sur (fichero f_CUSTOMER_SC).

Una vez definidos dichos grupos de entrada comprobaremos que en la trasformación se crea de forma automática un único grupo de salida:


Output: Grupo de salida que representa el flujo de datos resultante de unir todos los grupos de entrada definidos en la transformación.

Este grupo de salida representa el resultado de combinar todos los grupos de entrada definidos en la transformación en un único flujo de datos.

3.2.11.3. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Groups: Grupos de entrada que representan los distintos orígenes a combinar en un único flujo de datos.


Group Ports: Puertos disponibles para cada grupo. Todos los grupos, ya sean de entrada o salida, incluyen los mismos puertos.


Tracing Level: Nivel de detalle relativo a la transformación Union que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.

3.2.11.4. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Utilizar un nombre descriptivo para cada grupo de entrada definido en la transformación Union. Renombrar el grupo asociado a cada origen de datos para que sea sencillo determinar a simple vista la relación entre los mismos.


La transformación Union no elimina aquellos registros duplicados que puedan resultar

una vez combinados los grupos de entrada en un mismo flujo de datos. Utilice una transformación de tipo Aggregator (ver sección 3.2.5.8) o Sorter (ver sección 3.2.4.6) con este fin.


La transformación Union puede utilizarse en cualquier punto de nuestro flujo de datos,

siempre que no se hayan empleado con anterioridad transformaciones de tipo Sequence Generator o Update Strategy.

3.2.12. Transaction Control 3.2.12.1. Ficha Técnica

87/201

PowerCenter 8.x – Normativa de Desarrollo

Transaction Control Propósito

Generación de Puntos de Control

Nomenclatura

tc_[rl,rg]

Reutilización

Reutilizable

Activa/Pasiva

Activa

Conectada/Desconectada

Conectada

Utiliza Caches

No

3.2.12.2. Propósito La transformación Transaction Control se utiliza para generar puntos de control para su consumo por parte del Integration Service en tiempo de ejecución. Los puntos de control permiten hacer un COMMIT (confirmación) o un ROLLBACK (marcha atrás) de las operaciones realizadas en la transacción actual. La transformación Transaction Control nos permite definir una condición en función de la cual se generarán dichos puntos de control. Al ejecutar la sesión, se evaluará la condición para cada fila procesada, y el Integration Service capturará los puntos de control para actuar en consecuencia. El control de transacciones se suele emplear con destinos relacionales, en los que cada punto de control se traduce directamente en una operación de COMMIT o ROLLBACK en destino, gestionado por la propia base de datos. Un ejemplo puede ser la gestión de las transacciones (y por tanto la emisión de los COMMIT y ROLLBACK) en destino de tal manera que se confirme cada transacción en bloques determinados por algún campo de la estructura fuente (provincia, etc):

Figura 59: Ejemplo de Uso de Transformación Transaction Control con destinos relacionales Sin embargo, también se puede emplear la transformación Transaction Control con destinos no relacionales del tipo Flat File, cuando se combina con el uso de la columna especial FileName en la estructura destino:

88/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 60: Inclusión de la columna especial FileName es una estructura destino de tipo Flat File Esta funcionalidad permite controlar el número y el nombre de los ficheros de salida dentro del propio mapping, en función de los datos de entrada, enviando a la columna FileName el nombre de fichero deseado y emitiendo un punto de control COMMIT cuando se desee que el Integration Service cierre el fichero actual y cambie al nuevo fichero indicado en FileName:

Figura 61: Ejemplo de Uso de Transformación Transaction Control con destinos Flat File y la columna especial FileName

3.2.12.3. Parametrización Se indican a continuación los parámetros que pueden ser definidos en esta transformación:


Transaction Control Condition: Condición que determina el tipo de punto de control

emitido para el registro que se está tratando en ese momento. Se construye empleando el mismo editor que en la transformación Expression, y suele consistir en una sentencia IIF definida sobre alguno de los valores de entrada.

Para representar los posibles puntos de control existen las siguientes cinco variables especiales: •

TC_CONTINUE_TRANSACTION: El Integration Service no lleva a cabo ningún cambio para la transacción actual. Este es el valor por defecto de la expresión.

•

TC_COMMIT_BEFORE: El Integration Service hace el COMMIT de la transacción actual, comienza una nueva transacción, y escribe el registro actual en destino. Los datos que se están tratando en ese momento forman parte de la nueva transacción.

89/201

PowerCenter 8.x – Normativa de Desarrollo

•

TC_COMMIT_AFTER: El Integration Service escribe el registro actual en destino, hace el COMMIT de la transacción, y comienza una nueva transacción. Los datos que se están tratando en ese momento forman parte de la transacción sobre la que se hace el COMMIT.

•

TC_ROLLBACK_BEFORE: El Integration Service hace un ROLLBACK de la transacción actual, comienza una nueva transacción, y escribe el registro actual en destino. Los datos que se están tratando en ese momento forman parte de la nueva transacción.

•

TC_ROLLBACK_AFTER: El Integration Service escribe el registro actual en destino, hace el ROLLBACK de la transacción, y comienza una nueva transacción. Los datos que se están tratando en ese momento forman parte de la transacción sobre la que se hace el ROLLBACK.

Estas variables se encuentran en la carpeta Built-in:

Una posible condición sería la de la figura anterior: IIF(NEWPROV = '1', TC_COMMIT_BEFORE, TC_CONTINUE_TRANSACTION) En ese caso, se emitirá un COMMIT cuando el valor del campo NEWPROV valga ‘1’.


Tracing Level: Nivel de detalle relativo a la transformación Transaction Control que deseamos que aparezca en el log de sesión al ejecutar nuestro proceso de carga.

3.2.12.4. Best Practices Se indican a continuación varios puntos a tener en cuenta para garantizar el óptimo rendimiento de esta transformación:


Basar la Transaction Control Condition en un único puerto de entrada y emplear una

condición simple. Si la lógica detrás de la generación de los puntos de control es complicada, ésta deberá resolverse en una transformación Expression previa y condensar el resultado en un único valor con un código que se evaluará en la condición IIF de la transformación Transaction Control.


Tener muy presente la diferencia tanto entre los valores TC_COMMIT_BEFORE y

TC_COMMIT_AFTER como entre los valores TC_ROLLBACK_BEFORE y TC_ROLLBACK_AFTER. Las constantes BEFORE hacen que el registro actual pertenezcan a la nueva transacción, mientras que con los AFTER el registro que se esté tratando en ese momento será el último de la transacción a cerrar.

90/201

PowerCenter 8.x – Normativa de Desarrollo

3.3. Best Practices 3.3.1. Nomenclatura

3.3.1.1. General – Entidades

Entidad

Código

Banesto

01

Corporativo

02

Abbey

03

Santander

04

Totta

05

Openbank

06

3.3.1.2. General – Entornos

Entorno

Código

Desarrollo

DES

Pre-producción

PRE

91/201

PowerCenter 8.x – Normativa de Desarrollo

Producción

PRO

3.3.1.3. Dominios

Entorno

Desarrollo

Nomenclatura

Ejemplo(s)

DOM_DES[01,

DOM_DES01

02, … 0n]

Pre-producción

Producción

DOM_PRE[01,

DOM_PRE01

02,

DOM_PRE02

…

DOM_PRE03

0n]

….

DOM_PRO[01,

DOM_PRO01

02,

DOM_PRO02

…

DOM_PRO03

0n]

….

3.3.1.4. Nodos

Entorno

Desarrollo

Nomenclatura

Ejemplo(s)

NODE_DES[01,

NODE_DES01g

02,

NODE_DES01wa

…

NODE_DES01wb

0n]

…

[g,w] [a,b,c…] NODE_PRE[01,

Pre-producción

NODE_PRE01g

02,

NODE_PRE01wa

…

NODE_PRE01wb

0n]

…

[g,w]

92/201

PowerCenter 8.x – Normativa de Desarrollo

[a,b,c…] NODE_PRO[01,

Producción

NODE_PRO01g

02,

NODE_PRO01wa

…

NODE_PRO01wb

0n]

…

[g,w] [a,b,c…]

3.3.1.5. Repositorios

Objeto

Nomenclatura

Ejemplo(s)

PWCGL_

PWCGL_DES

Repositorio Global

[DES,

PWCGL_PRE

PRE,

PWCGL_PRO

PRO]

Repositorio Local

PWC[01,

PWC01_DES

02,

PWC01_PRE

…

PWC01_PRO

0n]_

PWC02_PRE

[DES,

PWC02_PRO

PRE, PRO]

3.3.1.6. Integration Services

Entorno

Desarrollo

Nomenclatura

Ejemplo(s)

IS_DES[01,

IS_DES01a

02,

IS_DES01b

…

IS_DES01c

0n][a,b,c…]

…

IS_PRE[01, Pre-producción

IS_PRE01a,

02,

IS_PRE01b,

…

….

93/201

PowerCenter 8.x – Normativa de Desarrollo

0n][a,b,c…]

IS_PRE02a, IS_PRE02b, … IS_PRO01a,

IS_PRO[01, Producción

IS_PRO01b,

02,

….

…

IS_PRO02a,

0n][a,b,c…]

IS_PRO02b, …

3.3.1.7. Carpetas PowerCenter requiere de la creación de una estructura de carpetas en cada repositorio donde se distribuirán todos los objetos definidos en la herramienta. La nomenclatura a utilizar en la definición de dichas carpetas se detalla en el apartado 5.1.3. 3.3.1.8. Variables y Parámetros

Objeto

Nomenclatura

Parámetro

Prefijo_NombreDescriptivo

Variable

Prefijo_NombreDescriptivo

Tipo

Prefijo

Date/Time

[V,P]_a_

Decimal

[V,P]_d_

Double

[V,P]_f_

Integer

[V,P]_i_

Nstring

[V,P]_S_

Real

[V,P]_r_

Ntext

[V,P]_T_

Small Int

[V,P]_o_

String

[V,P]_s_

Text

[V,P]_t_

Componente

Tipo

Longitud

Observaciones

94/201

PowerCenter 8.x – Normativa de Desarrollo

NombreDescriptivo

String

5-50

3.3.1.9. Transformaciones

Objeto

Nomenclatura

Transformación

Prefijo_ [rl,rg]_NombreDescriptivo

Transformación

Prefijo

Transformación

Prefijo

Source Qualifier

sq_

Rank

rnk_[rl,rg]

Expression

exp_[rl,rg]

Union

un_[rl,rg]

Filter

fil_[rl,rg]

Transaction Control

tc_[rl,rg]

Sorter

srt_[rl,rg]

Stored Procedure

sp_[rl,rg]

Aggregator

agg_[rl,rg]

External Procedure

ext_[rl,rg]

Joiner

jnr_[rl,rg]

Custom

ct_[rl,rg]

Lookup

lkp_[rl,rg]

XML Source Qualifier

xsq_

Update Strategy

upd_[rl,rg]

Midstream XML Parser

xp_[rl,rg]

Router

rtr_[rl,rg]

Midstream XML Generator

xg_[rl,rg]

Sequence Generator

seq_[rl,rg]

Mapplet Input

in_mplt_

Normalizer

nrm_

Mapplet Output

out_mptl

Componente [rl]

Tipo String

Longitud 2

Observaciones


Indicador reutilizable local
Objeto en Repositorio Local
Objeto en Carpeta c_Transformations

95/201

PowerCenter 8.x – Normativa de Desarrollo

[rg]

String

2


Indicador reutilizable global
Objeto en Repositorio Global
Objeto en Carpeta c_Transformations

NombreDescriptivo

String

10-50

3.3.1.10. Mapplets

Objeto

Nomenclatura

Mapplet

mplt_[rl,rg]_ [CódigoTécnico]_ [CódigoProyecto]_NombreDescriptivo

Componente

Tipo

Longitud

[CódigoTécnico]

String

2

[CódigoProyecto]

String

3-8

[NombreDescriptivo]

String

10-50

Componente [rl]

Tipo String

Longitud 2

Observaciones

Observaciones


Indicador reutilizable local
Objeto en Repositorio Local
Objeto en Carpeta c_Mapplets

[rg]

String

2


Indicador reutilizable global
Objeto en Repositorio Global
Objeto en Carpeta c_Mapplets

[CódigoTécnico]

String

2


Obligatorio sin [rl,rg]

[CódigoProyecto]

String

3-8


Obligatorio sin [rl,rg]

NombreDescriptivo

String

10-50

3.3.1.11. Mappings

Objeto

Nomenclatura

Mapping

m_[rl,rg]_[CódigoTécnico]_[CódigoProyecto]_NombreDescriptivo

96/201

PowerCenter 8.x – Normativa de Desarrollo

Componente [rl]

Tipo String

Longitud 2

Observaciones


Indicador reutilizable local
Objeto en Repositorio Local
Objeto en Carpeta c_Mappings

[rg]

String

2


Indicador reutilizable global
Objeto en Repositorio Global
Objeto en Carpeta c_Mappings

[CódigoTécnico]

String

2


Obligatorio sin [rl,rg]

[CódigoProyecto]

String

3-8


Obligatorio sin [rl,rg]

NombreDescriptivo

String

10-50

3.3.1.12. Sesiones y Otras Tareas

Objeto

Nomenclatura

Session

s_[r]_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Command

c_[r]_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Email

e_[r]_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Componente [r]

Tipo String

Longitud 1

Observaciones


Indicador reutilizable
Objeto en Carpeta de Proyecto

CódigoTécnico

String

2

CódigoProyecto

String

3-8

NombreDescriptivo

String

10-50

3.3.1.13. Worklets

Objeto

Nomenclatura

97/201

PowerCenter 8.x – Normativa de Desarrollo

wl_[r]_ [CódigoTécnico]_[CódigoProyecto]_NombreDescriptivo

Worklet

Componente [r]

Tipo

Longitud

String

1

Observaciones


Indicador reutilizable
Objeto en Carpeta de Proyecto

[CódigoTécnico]

String

2

[CódigoProyecto]

String

3-8

NombreDescriptivo

String

10-50

3.3.1.14. Workflows

Objeto

Nomenclatura

Workflow

wf_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Componente

Tipo

Longitud

CódigoTécnico

String

2

CódigoProyecto

String

3-8

NombreDescriptivo

String

10-50

Observaciones

3.3.1.15. Deployment Groups

Objeto

Nomenclatura

Deployment Group

dg_[CódigoTécnico]_[CódigoProyecto]_DDMMYYHHMM

Componente

Tipo

Longitud

CódigoTécnico

String

2

CódigoProyecto

String

3-8

NombreDescriptivo

String

10-50

DDMMYYHHMM

Date/Time

10

Observaciones


Indica fecha y hora de creación

98/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.1.16. Ficheros de Parámetros

Objeto

Nomenclatura

Fichero de Parámetros

NombreWorkflow[01..0n].[var|par]

Componente

Tipo

Longitud

Observaciones

NombreWorkflow

String

10-50


Ver Sección 3.3.1.14

[01..0n]

String

2


Si un workflow utiliza más de un fichero

de parámetros, incluir un número secuencial en el nombre de cada fichero.

Objeto

Ubicación Física

Fichero de Parámetros

$PMSourceFileDir\CódigoTécnico\CódigoProyecto\

3.3.1.17. Ficheros Log

Objeto

Nomenclatura

Fichero Log de Workflow

NombreWorkflow.log

Fichero Log de Sesión

NombreSesión.log

Componente

Tipo

Longitud

Observaciones

NombreWorkflow

String

10-50


Ver Sección 3.3.1.12

NombreSesión

String

10-50


Ver Sección 3.3.1.14

Objeto

Ubicación Física

Fichero Log de Workflow

$PMWorkflowLogDir

Fichero Log de Sesión

$PMSessionLogDir

99/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.1.18. Fuentes y Destinos

Objeto

Nomenclatura

Fichero Fuente

f_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Fichero Destino

f_CódigoTécnico_CódigoProyecto_NombreDescriptivo

Tabla Fuente

NombreFísicoTabla

Tabla Destino

NombreFísicoTabla

Componente

Tipo

Longitud

CódigoTécnico

String

2

CódigoProyecto

String

3-8

NombreDescriptivo

String

10-50

Observaciones

Objeto

Ubicación Lógica

Ubicación Física

Fichero Fuente


Repositorio Local o Global

$PMSourceFileDir\CódigoTécnico\ CódigoProyecto\

Fichero Destino


Repositorio Local o Global

Tabla Fuente


Repositorio Local o Global

Tabla Destino


Repositorio Local o Global


Carpeta c_Estructuras_Fuente (*)
Carpeta c_Estructuras_Destino (*)
Carpeta c_Estructuras_Fuente (*)
Carpeta c_Estructuras_Destino (*)

$PMTargetFileDir\CódigoTécnico\ CódigoProyecto\

Base de Datos

Base de Datos

(*) A menos que sea aprobado por QA.

100/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.1.19. Conexiones

Objeto

Nomenclatura

Conexión Relacional

cnx_0n_CódigoTécnico_CódigoProyecto

Conexión FTP

ftp_0n_CódigoTécnico_CódigoProyecto

Conexión External Loader

ldr_0n_CódigoTécnico_CódigoProyecto

Componente 0n

Tipo String

Longitud 2

Observaciones


Incluir un número secuencial [01..0n] en el nombre de cada conexión, incluso si se trata de la única conexión definida para un proyecto.

CódigoTécnico

String

2

CódigoProyecto

String

3-8

3.3.1.20. Shortcuts

Objeto

Nomenclatura

Shortcut

Shortcut_to_NombreObjeto

Componente

Tipo

Longitud

Observaciones


PowerCenter asigna este nombre por Shortcut_to_Nombre Objeto

String

n

defecto cuando se crea un nuevo Shortcut, que se deberá mantener siempre. Modificar este nombre por defecto puede provocar complicaciones en los procedimientos de traspaso.

101/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.2. Descripciones PowerCenter permite introducir descripciones para todos los objetos definidos en la plataforma. Dichas descripciones se almacenan en el repositorio de metadatos utilizado por la herramienta, permitiendo de esta manera su posterior utilización. Estas descripciones son directamente accesibles a través de Metadata Reporter, ofreciendo un catálogo de componentes sin necesidad de ningún tipo de desarrollo a medida. Es importante destacar que las descripciones de fuentes, destinos y cualquier componente reutilizable definido en PowerCenter han de corresponderse con las definiciones incluidas en el DDS de los procesos de carga.

3.3.2.1. Normativa de Descripciones Se indica a continuación la normativa de descripciones a asignar para cada tipo de objeto definido en PowerCenter:

Objeto Fichero Fuente

Fichero Destino

Tabla Fuente

Tabla Destino

Ubicación Lógica

Observaciones


Carpeta c_Estructuras_Fuente

Descripción obligatoria a nivel de objeto y campo.

(*)


Carpeta c_Estructuras_Destino Descripción obligatoria a nivel de (*)


Carpeta c_Estructuras_Fuente (*)

objeto y campo.

Descripción obligatoria a nivel de objeto y campo.


Carpeta c_Estructuras_Destino Descripción obligatoria a nivel de (*)

objeto y campo.


Carpeta c_Transformations (*) Transformaciones Reutilizables

ó

Descripción obligatoria a nivel de objeto.


Carpeta de Proyecto Transformaciones No Reutilizables


Carpeta de Proyecto

Descripción opcional.


Carpeta c_Mapplets Mapplets

ó

Descripción obligatoria.


Carpeta de Proyecto Mappings Sesiones y Otras Tareas Worklets


Carpeta de Proyecto

Descripción obligatoria.


Carpeta de Proyecto

Descripción obligatoria.


Carpeta de Proyecto

Descripción obligatoria.

102/201

PowerCenter 8.x – Normativa de Desarrollo

Workflows Deployment Groups


Carpeta de Proyecto

Descripción obligatoria.

N/A

Descripción opcional.

(*) A menos que sea aprobado por QA.

3.3.2.2. Descripciones a Nivel de Fuente o Destino Para introducir una descripción a nivel de fuente o destino editaremos dicho objeto en la herramienta cliente PowerCenter Designer y utilizaremos el campo Description.

Figura 62: Descripción a Nivel de Fuente Para introducir una descripción a nivel de campo de una fuente o destino editaremos el apartado Columns de dicho objeto en la herramienta cliente PowerCenter Designer y utilizaremos el campo Description disponible para cada campo.

103/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 63: Descripción a Nivel de Campo

3.3.2.3. Descripciones a Nivel de Mapplet Para introducir una descripción a nivel de mapplet editaremos dicho objeto en la herramienta cliente PowerCenter Designer mediante la opción Mapplets -> Edit… y utilizaremos el campo Comments.

Figura 64: Descripción a Nivel de Mapplet

3.3.2.4. Descripciones a Nivel de Mapping Para introducir una descripción a nivel de mapping editaremos dicho objeto en la herramienta cliente PowerCenter Designer mediante la opción Mappings -> Edit… y utilizaremos el campo Comments.

104/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 65: Descripción a Nivel de Mapping

3.3.2.5. Descripciones a Nivel de Sesión o Tarea Para introducir una descripción a nivel de sesión o tarea editaremos dicho objeto en la herramienta cliente PowerCenter Workflow Manager y utilizaremos el campo Description.

Figura 66: Descripción a Nivel de Sesión

3.3.2.6. Descripciones a Nivel de Workflow Para introducir una descripción a nivel de workflow editaremos dicho objeto en la herramienta cliente PowerCenter Workflow Manager mediante la opción Workflows -> Edit… y utilizaremos el campo Comments.

105/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 67: Descripción a Nivel de Workflow

3.3.3. Diseño de Mappings Un mapping se define como la representación visual de un proceso de carga. Un mapping se compone de una serie de fuentes (Sources), destinos (Targets) y transformaciones que indican al servidor de Informatica cómo realizar la lectura, transformación y carga de los datos.

Figura 68: Ejemplo de mapping

106/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.3.1. Conectar sólo los puertos necesarios Durante la inserción de transformaciones en el flujo de un mapping, debemos solamente dibujar las flechas necesarias entre transformaciones. Es decir, si un campo de una tabla origen no es necesario para nada en el destino, no tiene ningún sentido ir arrastrándolo hasta el final, ya que esto consume recursos de memoria, CPU, ... En la siguientes figuras vemos ejemplos de lo que no se debería hacer (Figura 69) y del uso correcto (Figura 70). Claro está, suponiendo que por ejemplo, no necesitamos ningún puerto aparte del a1 y a2 para el filtro o la expresión.

Figura 69: Uso erróneo de conexión de puertos

Figura 70: Uso correcto de conexión de puertos Como vemos en las figuras, lo importante es filtrar a partir del Source Qualifier, ya que es ésta la transformación donde se genera la SELECT o la lectura del fichero de entrada. Desde los Sources al Source Qualifier siempre tendremos todas las flechas.

3.3.3.2. No cruzar flechas Otra de las cosas que se debe evitar mientras se está desarrollando un mapping es cruzar las flechas sin necesidad. A veces es inevitable, desde luego, pero no debe hacerse si no es necesario. Y no es solamente por razones de visibilidad de los mappings, sino que cruzar flechas también afecta al rendimiento, ya que si no se cruzan los bloques de memoria que se pasan las transformaciones pueden ser más grandes y por lo tanto se ahorran accesos a memoria.

107/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.3.3. Funciones y operadores Cuando estamos editando una expresión en el editor de expresiones, debemos intentar optimizarlas para que el rendimiento sea el mejor posible. Seguidamente se mostrará una lista con los puntos más importantes a tener en cuenta en este aspecto:


Usar operadores en lugar de funciones siempre que sea posible. Por ejemplo es mejor el uso del operador de concatenación “||” que usar la operación CONCAT(char1, char2).


Las operaciones sobre numéricos son más rápidas que sobre strings. Intentar que las comparaciones, ... se hagan sobre puertos con tipo de datos numérico.


Optimizar los IIF. Recordar que devuelve un valor. Ver el siguiente ejemplo: IIF(FLG_A=’Y’ and FLG_B=’Y’ and FLG_C=’Y’, VAL_A+VAL_B+VAL_C, IIF(FLG_A=’Y’ and FLG_B=’Y’ and FLG_C=’N’, VAL_A+VAL_B, IIF(FLG_A=’Y’ and FLG_B=’N’ and FLG_C=’Y’, VAL_A+VAL_C, IIF(FLG_A=’Y’ and FLG_B=’N’ and FLG_C=’N’, VAL_A, IIF(FLG_A=’N’ and FLG_B=’Y’ and FLG_C=’Y’, VAL_B+VAL_C, IIF(FLG_A=’N’ and FLG_B=’Y’ and FLG_C=’N’, VAL_B, IIF(FLG_A=’N’ and FLG_B=’N’ and FLG_C=’Y’, VAL_C, IIF(FLG_A=’N’ and FLG_B=’N’ and FLG_C=’N’, 0.0)))))))) Se puede optimizar fácilmente así:

IIF(FLG_A=’Y’, VAL_A, 0.0) + IIF(FLG_B=’Y’, VAL_B, 0.0) + IIF(FLG_C=’Y’, VAL_C, 0.0) Y hemos pasado de 8 IIF, 16 AND ... a sólo 3 IIF y 3 comparaciones


En las funciones de agregación por ejemplo, es mejor SUM(a + b) que SUM(a) + SUM(b) 3.3.3.4. Evitar conversiones de tipo innecesarias El motor de ejecución automáticamente hace conversiones de tipo cuando estos son compatibles. Siempre que sea posible se deben evitar y para ello hay que configurar correctamente los tipos de datos en el origen y destino y entonces siempre haremos bien los pasos intermedios. La siguiente figura (Figura 71) muestra un ejemplo de algo que no se debe hacer. Podemos ver como en el Source Qualifier el puerto a1 es de tipo string, mientras que en la Expression es de tipo decimal. Esto obliga a transformaciones automáticas que se deben evitar.

Figura 71: Transformaciones automáticas de tipo de datos

108/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.3.5. Reducir el número de transformaciones en los mapping La cantidad de transformaciones que tiene un mapping afecta al rendimiento. Cuantas más transformaciones, más pasos hacen los datos y más recursos se usan. Lo importante es no tener más de las necesarias. Por ejemplo, usar Router en lugar de muchos Filter cuando se pueda, juntar muchos cálculos en una única Expression en lugar de tener varias expresiones separadas.

109/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.4. Diseño de sesiones y worflows Un workflow se define como una serie de instrucciones que indican al servidor de Informatica cómo ha de ejecutarse un proceso de carga. Un workflow se compone de un punto de inicio y una o más tareas de tipo Sesión (Session), Comando (Command) o Mensaje (E-mail). La forma en la que se enlazan las tareas de un workflow determina el orden en el que se ejecutan. Fig. 58 muestra un ejemplo de workflow con tareas secuenciales en el que la ejecución de una sesión no comienza hasta que se haya ejecutado la anterior.

Figura 72: Ejemplo de Workflow con Tareas Secuenciales Fig. 59 muestra un ejemplo de workflow con cuatro tareas concurrentes, marcadas en rojo, que se ejecutarán de forma simultánea.

Figura 73: Ejemplo de Workflow con Tareas Concurrentes Fig. 60 muestra cómo especificar si la última sesión del workflow en Fig. 59 no se ejecutará hasta que se hayan completado las cuatro sesiones anteriores (Treat the input links as AND) o si en cambio puede ejecutarse tan pronto como una de las sesiones concurrentes finalice (Treat the input links as OR).

110/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 74: Uso de la opción ‘Treat the input links as AND/OR’

3.3.4.1. Utilizar Opción ‘Fail parent if this task fails’ Definimos como completado con éxito aquel workflow o tarea cuyo estado aparece como Succeeded en la herramienta cliente Workflow Monitor y/o cuyo código de retorno es igual a cero si se ejecuta desde línea de comando a través de la utilidad pmcmd. Definimos como fallido aquel workflow o tarea cuyo estado aparece como Failed en la herramienta cliente Worklflow Monitor y/o cuyo código de retorno es distinto de cero si se ejecuta desde línea de comando a través de la utilidad pmcmd. Por defecto, si una de las tareas incluidas en un workflow falla el workflow se considera como completado con éxito. Dado que en la mayoría de los casos necesitamos que el fallo a nivel de tarea se propague al workflow hemos de habilitar para cada tarea la opción ‘Fail parent if this task fails’ para que el servidor de Informatica marque el workflow como fallido en caso de que una de sus tareas falle. Opcionalmente podemos utilizar la opción ‘Fail parent if this task does not run’ para considerar como fallidas ejecuciones parciales de un workflow.

111/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 75: Opción ‘Fail parent if this task fails’ habilitada a nivel de sesión

3.3.4.2. Establecer Límite en Número de Errores por Sesión Definimos como errores críticos a nivel de sesión aquellos que causan el fallo inmediato de ésta, como por ejemplo la falta de permisos de inserción sobre una tabla de destino. Definimos como errores no críticos aquellos que indican errores de lectura, transformación o escritura a nivel de registro, pero no el fallo de la sesión, como por ejemplo los errores de violación de clave primaria generados al intentar insertar registros duplicados en una tabla de destino sobre la cual hemos definido una clave primaria. Por defecto, una sesión aparecerá como completada con éxito a pesar de haber generado errores no críticos, por lo que es posible que una sesión aparezca con un estado de Succeeded en la herramienta cliente Worklflow Monitor o que devuelva un código de retorno igual a cero desde línea de comando a pesar de haber generado tantos errores de violación de clave primaria como registros se haya intentado insertar en una tabla de destino. Para evitar este tipo de situaciones se recomienda utilizar la opción ‘Stop on errors’ para establecer un límite de errores no críticos permitidos antes de que el servidor de Informatica marque la sesión como fallida. Puede asignarse un valor numérico cualquiera a dicha opción, o bien es posible utilizar la variable de servidor $PMSessionErrorThreshold para establecer un número límite de errores no críticos permitidos por sesión a nivel de entorno.

112/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 76: Opción ‘Stop on errors’

3.3.4.3. Utilizar Enlaces Condicionales El orden de ejecución de las tareas incluidas en un workflow depende de la forma en la que hayan sido conectadas entre sí. En el ejemplo de workflow secuencial adjunto las tablas dimensionales se cargarán secuencialmente antes de cargar la tabla de hechos. Por defecto, la ejecución del workflow continuará incluso si una de sus tareas falla. La sección 3.3.3.2 detallaba cómo utilizar la opción ‘Fail parent if this task fails’ para propagar el fallo de una tarea a nivel de workflow. Es de destacar que incluso utilizando esta opción la ejecución del workflow no se detiene una vez producido el error. En el ejemplo adjunto el fallo de la sesión s_DIM_TIME no impide que el servidor de Informatica continúe con la ejecución del workflow, pasando a ejecutar la sesión s_DIM_REP:

Figura 77: Workflow sin enlaces condicionales, se ejecutan todas las sesiones Para evitar que el wokflow siga ejecutándose aunque una de sus tareas haya fallado definiremos los enlaces entre tareas como enlaces condicionales. Por ejemplo, utilizaremos la expresión $s_DIM_TIME.Status = SUCCEEDED en el enlace entre las sesiones s_DIM_TIME y s_DIM_REP para que esta última sesión se ejecute solamente si la primera se ha completado con éxito.

Figura 78: Workflow con enlaces condicionales, se evalúa la expresión del enlace antes de ejecutar la siguiente sesión

113/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 79: Ejemplo de expresión condicional definida en un enlace entre tareas

3.3.4.4. Eliminar Ficheros Intermedios La tarea de tipo Comando (Command) permite ejecutar comandos sobre el sistema operativo en cualquier punto del workflow. Se recomienda el uso de una o varias tareas de este tipo para eliminar cualquier fichero intermedio generado por el proceso de carga. Fig. 66 muestra un ejemplo de workflow en el que se emplea una tarea de tipo Comando como último paso del proceso de carga para eliminar los ficheros intermedios generados por las tareas de tipo Sesión. La tarea incluye una serie de comandos MS-DOS para eliminar dichos ficheros. Se indica a continuación la sintaxis utilizada en dichos comandos: del $PMTargetFileDir///.dat

Figura 80: Workflow con tarea de tipo Command para eliminación de ficheros intermedios Sección 3.3.5 muestra la estructura de directorios para ficheros fuente y destino a utilizar en cada proyecto. Sección 3.3.4.6 detalla el uso de variables de entorno en tareas de tipo Comando. Sección 3.3.4.5 indica el uso de la opción ‘Fail task if any command fails’ para realizar el control de errores en la ejecución de dichos comandos.

114/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.4.5. Utilizar Opción ‘Fail task if any command fails’ en Tareas de tipo Comando

PowerCenter ejecuta los comandos incluidos en una tarea de tipo Comando en el orden especificado en la misma. Por defecto, si uno de los comandos falla la tarea se considera como completada con éxito, incluso si la tarea contiene un único comando. Dado que en la mayoría de los casos necesitamos que el fallo a nivel de comando se propague a la tarea hemos de habilitar la opción ‘Fail task if any command fails’ para que el servidor de Informatica marque la tarea como fallida en caso de que alguno de sus comandos falle. Fig. 67 muestra un ejemplo de tarea de tipo Comando en el que se utiliza la opción ‘Fail task if any command fails para propagar a la tarea el fallo de cualquiera de los comandos incluidos en el mismo.

Figura 81: Opción ‘Fail task if any command fails’

3.3.4.6. Utilizar Variables de Entorno en Tareas de Tipo Comando La tarea de tipo Comando (Command) permite ejecutar comandos sobre el sistema operativo en cualquier punto del workflow. Para garantizar su correcto funcionamiento independientemente del entorno en el que se despliegue el proceso de carga se recomienda el uso de variables de entorno en dichas tareas siempre que sea posible. Se indican a a continuación las variables de entorno definidas a nivel de sistema operativo en los servidores de los distintos entornos donde se haya instalado el componente Informatica Server:

Variable

Propósito

115/201

PowerCenter 8.x – Normativa de Desarrollo

PMRootDir

Indica la ubicación del directorio raíz de instalación de Informatica Server.

PMSourceFileDir

Indica la ubicación del directorio para ficheros fuente. Estos ficheros se organizarán por proyecto utilizando la siguiente estructura de directorios: %PMSourceFileDir%\\\

PMTargetFileDir

Indica la ubicación del directorio para ficheros de destino. Estos ficheros se organizarán por proyecto utilizando la siguiente estructura de directorios: %PMTargetFileDir%\\\

Utilizando estas variables de entorno es posible por ejemplo ejecutar un comando para eliminar un fichero intermedio generado por nuestro proceso de carga que funcionará en cualquier entorno, independientemente del directorio de instalación del producto. Sección 3.3.4.4 incluye un ejemplo de dicho comando.

3.3.4.7. Mantener el Log de Todas las Ejecuciones a Nivel de Workflow y Sesión PowerCenter genera un fichero log por cada ejecución de un workflow o sesión. Por defecto dichos ficheros log se sobreescriben cada vez que se ejecuta de nuevo el workflow o sesión correspondiente. La plataforma ofrece las siguientes opciones de archivo de dichos ficheros log:


Mantener el log de la última ejecución: Opción por defecto. Se mantiene únicamente el log correspondiente a la última ejecución. Cada nueva ejecución sobreescribe el log ya existente.


Mantener el log de las últimas n ejecuciones: Opción Save Session\Workflow log by Session

runs. Además del log de la última ejecución el servidor de PowerCenter mantiene los logs de ejecución de las n últimas ejecuciones de acuerdo al valor asignado al parámetro Save Workflow\Session Log for These Runs. Por ejemplo, si especificamos un valor de 5 para este parámetro el servidor mantiene el log de la última ejecución además de los logs históricos 0 a 4, para un total de 6 logs. Un valor de 0 indica que se mantiene únicamente el log de la última ejecución y es por tanto equivalente a la opción por defecto. Es posible asignar a este parámetro la variable de servidor $PMSessionLogCount. El log de la última ejecución se nombra .log, mientras que los logs de las ejecuciones históricas se nombran consecutivamente como .log.0, .log.1, .log.2, …, .log.n-1


Mantener el log de todas las ejecuciones: Opción Save Session\Workflow log by

Timestamp. El servidor mantiene los logs de todas las ejecuciones añadiendo la fecha y hora del fin de la ejecución al nombre del log, Los ficheros log se nombran como .log.yyyymmddhhmi, donde: yyyy = año

116/201

PowerCenter 8.x – Normativa de Desarrollo

mm = mes, de 1 a 12 dd = día, de 1 a 31 hh = hora, de 0 a 23 mi = minuto, de 0 a 59 Es importante seleccionar la estrategia de generación de logs adecuada para no perder información sobre las ejecuciones realizadas. Por ejemplo, si se utiliza la opción por defecto y un proceso de carga falla perderemos el log de workflow y sesión correspondiente al relanzar el mismo, ya que la nueva ejecución sobreescribe dichos ficheros. Se recomienda mantener el log de todas las ejecuciones, realizando una limpieza periódica de logs a nivel de servidor. Fig. 69 muestra un ejemplo de workflow en el que se utiliza la opción ‘Save Workflow log By Timestamp’ para mantener el log de todas las ejecuciones del mismo.

Figura 82: Opción ‘Save Workflow log By Timestamp’ Fig. 70 muestra un ejemplo de sesión configurada para mantener el log de todas las ejecuciones de la misma mediante la opción ‘Save session log by Session timestamp’.

117/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 83: Opción ‘Save session log by Session timestamp’

3.3.4.8. Parametrizar Nombres de Ficheros de Origen y Destino Para aquellos procesos de carga que utilizan ficheros locales al servidor de ejecución como origen o destino PowerCenter permite especificar los nombres de dichos ficheros directamente a nivel de sesión o bien mediante un fichero de parámetros. Se recomienda la parametrización de los nombres de dichos ficheros en todos los procesos de carga. Esta estrategia es particularmente importante en aquellos procesos donde los nombres de los ficheros de origen o destino puedan variar de ejecución en ejecución, como sería el caso en el tratamiento de ficheros datados. Fig. 71 muestra un ejemplo de sesión donde los nombres de los ficheros de origen y destino se han parametrizado. Se indica a continuación la sintaxis utilizada para dichos parámetros de sesión:

Parámetro

Sintaxis

Propósito

Source filename

$InputFile

Nombre fichero de origen.

Output filename

$OutputFile

Nombre fichero de destino.

118/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 84: Parametrización de Nombres de Ficheros de Entrada y Salida a Nivel de Sesión Se indica a continuación el contenido del fichero de parámetros definido a nivel de workflow donde se asignan valores a dichos parámetros de sesión:

[p_HZ_AGR.WF:wf_HZ_AGR_RECURSOS_INVERSION_01.ST:s_HZ_AGR_RECURSOS_INVERSIO N_01] $InputFileProductos=EXP9.I9.LR.I9JNVPRO.PRODUC.F0606.DAT $InputFileFamilia=EXP9.I9.LR.I9JDVPRE.I9CDV00.SALIDA.DAT $InputFileRelaciones=CIF.HZ.LR.BDK.HZCV014J.RELAC.F0606.DAT $OutputFileRecursosInversion=f_HZ_AGR_RECURSOS_INVERSION.0606.dat

Figura 85: Fichero de parámetros a nivel de workflow $PMSourceFileDir\HZ\AGR\wf_HZ_AGR_RECURSOS_INVERSION_01.par Sección 4.1.3 detalla el uso de ficheros de parámetros en procesos PowerCenter.

3.3.4.9. Parametrizar Nombres de Ficheros FTP y Directorio Remoto En la versión 8.x de PowerCenter se permite parametrizar el Directorio Remoto por defecto de una conexión FTP así como los nombres de los ficheros empleados en conexiones FTP. De nuevo esta estrategia es importante en aquellos procesos donde los nombres de los ficheros de origen o destino puedan variar de ejecución en ejecución, como en el tratamiento de ficheros datados. El método es similar al empleado para los Ficheros de Entrada y Salida, creando en esta ocasión parámetros con la siguiente sintaxis:

119/201

PowerCenter 8.x – Normativa de Desarrollo

Parámetro

Sintaxis

Propósito

Source filename

FTP

$ParamFTPInFile

Nombre fichero de origen FTP.

Output filename

FTP

$ParamFTPOutFile

Nombre fichero de destino FTP.

$ParamFTPDir

Directorio remoto por defecto.

Default Remote Directory

Para acceder a estos valores en PowerCenter, se escribirá el nombre del parámetro correspondiente en los siguientes campos: •

Para parámetros Source FTP filename y Output FTP filename: en la pantalla de edición de una tarea, en la pestaña Mapping, editando el valor de la conexión FTP correspondiente, como muestra la siguiente figura:

Figura 86: Parametrización de Nombres de Ficheros FTP de Entrada y Salida a Nivel de Sesión

•

Para el parámetro Default Remote Directory: en la ventana de edición de conexiones FTP (no se puede modificar directamente editando las conexiones FTP de una tarea, como con los dos parámetros anteriores), tal como se indica a continuación:

120/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 87: Parametrización de Directorio Remoto por defecto a Nivel de Conexión FTP Un fichero de parámetros de ejemplo quedaría como sigue: [p_HZ_AGR.WF:wf_HZ_AGR_RECURSOS_INVERSION_01.ST:s_HZ_AGR_RECURSOS_INVERSION_01] $ParamFTPInFileEjemplo=EXP9.I9.LR.I9JNVPRO.PRODUC.F0606.DAT $ParamFTPOutFileEjemplo=f_HZ_AGR_RECURSOS_INVERSION.0606.dat $ParamFTPDirEjemplo=/ficheros/HZ/3357

Figura 88: Fichero de parámetros a nivel de workflow $PMSourceFileDir\HZ\AGR\wf_HZ_AGR_RECURSOS_INVERSION_01.par

3.3.4.10. Escritura de Logs Compatibles Las propiedades de workflow y sesiones en la versión 8.x nuevas opciones para generar logs compatibles con anteriores versiones de PowerCenter: •

Write Backward Compatible Workflow Log File: para objetos de tipo workflow. Esta opción se encuentra en el siguiente diálogo:

121/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 89: Parámetro Write Backward Compatible Workflow Log File

•

Write Backward Compatible Session Log File: para objetos de tipo sesión. Esta opción se encuentra en el siguiente diálogo:

Figura 90: Parámetro Write Backward Compatible Session Log File Dichas opciones se activarán si no se desea usar el Log Service, ya que si están desactivadas el formato del log será en binario y por tanto tan sólo podrán visualizarse con la herramienta Workflow Monitor. Para que los logs sean accesibles desde Metadata Reporter estas opciones deberán activarse. Importante: Estas opciones aparecen deshabilitadas por defecto al crear un nuevo workflow o sesión, y por tanto su revisión será obligatoria.

122/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.4.11. Asistente para el Cálculo de Tamaños de Cachés A nivel de sesión existe una opción en la versión 8.x de PowerCenter para realizar el cálculo del tamaño de las cachés en aquellas transformaciones que la necesiten (Aggregator, Joiner, Lookup y Sorter). Se accede a esta opción desde el editor de tareas en la pestaña Mapping, bien en el elemento Memory Properties, o en la transformación correspondiente en el desplegable Transformations, tal como se muestra en la siguiente figura:

Figura 91: Nuevo Asistente para el Cálculo de Tamaños de Cachés Para que PowerCenter realice el cálculo necesita que aportemos un dato significativo, que varía para cada transformación: •

Aggregator: Número de agrupaciones previstas.

•

Joiner: Número de filas del master.

•

Lookup: Número de filas con claves únicas en la Lookup.

•

Sorter: Número de filas.

3.3.4.12. Opciones de Auto Memory Attributes En la versión 8.x se pueden encontrar a nivel de sesión nuevas opciones para la gestión automática de la memoria que se describirán en este apartado, aunque tan sólo se recomienda su uso junto con el cálculo de tamaños de cachés. Estas opciones se encuentran en el siguiente diálogo:

123/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 92: Nuevas opciones de Auto Memory Attributes a nivel de sesión Para activar el uso de Auto Memory Attributes se deben configurar ambos parámetros; si en alguno de ellos se introduce el valor 0, el Integration Server deshabilita este mecanismo y utiliza los valores por defecto para la asignación de memoria. Durante la ejecución de una sesión con Auto Memory Attributes el Integration Service determina cuál de las dos propiedades tiene un valor menor: o bien el máximo de memoria introducido manualmente, o el porcentaje de memoria disponible. A partir de este momento, se reparte esa memoria entre todas las transformaciones que utilizan caché. Con cada tipo de transformación se emplea un número determinado de unidades para dividir la memoria compartida. A continuación se muestran los ratios utilizados por PowerCenter: •

Caché de índices para Lookup, Aggregator, Ranking y Joiner: 1 Unidad.

•

Caché de datos para Lookup, Aggregator, Ranking y Joiner: 2 Unidades.

•

Sorter: 8 Unidades.

•

Destinos XML: 10 Unidades.

Como ejemplo: Si tenemos un mapping con un Sorter, un Aggregator y dos Lookups, se dividirá la memoria por 17 (8+1+2+1+2+1+2), para después asignar 8 unidades de esa memoria para la caché de la transformación Sorter, y 3 unidades para cada transformación Aggregator y Lookup. Esta forma de realizar los cálculos hace que si la transformación de Sorter es muy pequeña, o bien una transformación de Lookup respecto a la otra es más grande, hace que no se aproveche toda la memoria de forma correcta, y por ello no se recomienda su uso sin realizar también el cálculo de los tamaños de caché. En la versión 8.x de PowerCenter también es posible la asignación automática de memoria a las propiedades DTM Buffer Size y Default Buffer Block Size, tal y como se muestra en las siguientes figuras:

124/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 93: Nueva opción Auto en DTM buffer size a nivel de sesión

Figura 94: Nueva opción Auto en Default buffer block size Estos parámetros funcionarán de forma automática tan sólo si se han configurado las propiedades a nivel de sesión Maximum Memory Allowed For Auto Memory Attributes y Maximum Percentage of Total Memory Allowed For Auto Memory Attributes. Si alguna de esas opciones está a 0, tanto el DTM Buffer Size como el Default Buffer Block Size se tendrán que configurar manualmente. De ahí la recomendación de emplear el Auto Memory Attributes únicamente con el cálculo de tamaño de cachés, ya que de esa manera se pueden emplear las opciones Auto en DTM Buffer

125/201

PowerCenter 8.x – Normativa de Desarrollo

Size y Default Buffer Block Size mientras se sigue optimizando al máximo y de forma manual el uso de memoria por parte de las transformaciones.

3.3.5. Estructura de Directorios para Ficheros Fuente y Destino PowerCenter utiliza por defecto la siguiente estructura de directorios para organizar los ficheros fuente y destino de los procesos de carga:

Figura 95: Estructura de directorios para ficheros fuente y destino por defecto Directorio

Propósito

PMRootDir

Directorio raíz de instalación de Informatica Server.

PMSourceFileDir

Directorio para ficheros fuente.

PMTargetFileDir

Directorio para ficheros de destino.

Para organizar los ficheros fuente y destino por proyecto extenderemos esta estructura de directorios creando un subdirectorio por Código Técnico, ej. HZ, y dentro de éste un directorio por Código de Proyecto, ej. CRP, tanto en el directorio de ficheros fuente como en el de ficheros de destino.

126/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 96: Estructura de directorios para ficheros fuente y destino por proyecto PowerCenter ofrece las siguientes variables de servidor para indicar la ubicación de dichos directorios independientemente del entorno en el que se despliegue el proceso de carga. Estas variables se utilizan en la parametrización de tareas de tipo Sesión.

Variable

Propósito

$PMRootDir

Indica la ubicación del directorio raíz de instalación de Informatica Server.

$PMSourceFileDir

Indica la ubicación del directorio para ficheros fuente. Estos ficheros se organizarán por proyecto utilizando la siguiente estructura de directorios: $PMSourceFileDir\\\

$PMTargetFileDir

Indica la ubicación del directorio para ficheros de destino. Estos ficheros se organizarán por proyecto utilizando la siguiente estructura de directorios: $PMTargetFileDir\\\

La parametrización de nuestos procesos de carga ha de realizarse considerando la estructura de directorios creada para el proyecto. Si es necesario asignar ficheros de parámetros a nuestro workflow dichos ficheros han de almacenarse en el directorio $PMSourceFileDir\\\ correspondiente. El siguiente ejemplo muestra cómo especificar la ubicación de un fichero de parámetros para un workflow mediante la opción Edit Workflow -> Properties -> Parameter Filename disponible en PowerCenter Workflow Manager.

127/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 97: Opción ‘Parameter Filename’ Si nuestro workflow utiliza ficheros fuente dichos ficheros han de almacenarse en el directorio $PMSourceFileDir\\\ correspondiente. El siguiente ejemplo muestra cómo especificar la ubicación del un fichero fuente para una sesión mediante la opción Edit Tasks -> Mapping -> Sources -> Source File Directory disponible en PowerCenter Workflow Manager. Esta modificación ha de realizarse para cada fuente asociada a un fichero en todas las sesiones del workflow.

Figura 98: Opción ‘Source File Directory’

128/201

PowerCenter 8.x – Normativa de Desarrollo

Si nuestro workflow genera ficheros de salida dichos ficheros han de almacenarse en el directorio $PMTargetFileDir\\\ correspondiente. El siguiente ejemplo muestra cómo especificar la ubicación del un fichero de salida de una sesión mediante la opción Edit Tasks -> Mapping -> Targets -> Output File Directory disponible en PowerCenter Workflow Manager. Esta modificación ha de realizarse para cada destino asociado a un fichero en todas las sesiones del workflow.

Figura 99: Opción ‘Output File Directory’ Las variables de servidor descritas se utilizan en la parametrización de tareas de tipo Sesión, pero no es posible su uso en tareas de tipo Comando. Con este fin se han creado variables de entorno equivalentes en cada instalación de PowerCenter. Sección 3.3.4.6 detalla el uso de dichas variables de entorno en tareas de tipo Comando.

129/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.6. Estructura de Directorios para Scripts de Proyecto Entendemos como scripts de proyecto aquellos utilizados en combinación con procesos PowerCenter e invocados o bien directamente desde un workflow o sesión o bien desde Control-M. El uso de dichos scripts ha de ser aprobado por Arquitectura Técnica, siendo responsabilidad del equipo de Quality Assurance la validación de los mismos. Para aquellos proyectos donde sea necesario utilizar scripts, y siempre que Arquitectura Tecnica y QA den su visto bueno al uso de los mismos, se extenderá la estructura de directorios existente para organizar dichos scripts por proyecto, creando un subdirectorio con el nombre SCRIPTS en el directorio de ficheros fuente definido para el proyecto.

Figura 100: Estructura de directorios para scripts de proyecto

130/201

PowerCenter 8.x – Normativa de Desarrollo

Utilizaremos la siguiente sintaxis para referirnos a un script desde un comando: Sintaxis: %PMSourceFileDir%\\\SCRIPTS\ Ejemplo: c:\cygwin\bin\bash.exe –login %PMSOURCEFILEDIR%/AJ/SEG/SCRIPTS/COMPRESS.sh %PMSOURCEFILEDIR%/AJ/SEG/ F2_ITI_BASE_DIC05.dat

La variable de entorno PM_SCRIPTS indica la ubicación del directorio para scripts de mantenimiento o utilidades propias de la plataforma. En ningún caso se utilizará dicho directorio para almacenar scripts de proyecto.

131/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.7. Tratamiento de Ficheros Host Se espera que un número importante de procesos de carga desarrollados en PowerCenter utilicen ficheros host como origen de datos. Dichos ficheros, generados en sistemas mainframe utilizando rutinas Cobol, presentan un formato de ancho fijo y pueden contener tanto campos alfanuméricos como campos numéricos binarios codificados en hexadecimal. PowerCenter puede utilizar estos ficheros como fuente de datos sin necesidad de implementar ningún tipo de proceso de conversión previa. Los procesos de carga que utilicen dichos ficheros como origen realizarán la conversión de los campos numéricos de forma directa. Es importante tener en cuenta que estos procesos de conversión son automáticos en la plataforma PowerCenter, por lo que un fichero host puede añadirse como fuente de datos directamente a un proceso de carga para su tratamiento, siempre y cuando su estructura se haya importado de la manera descrita a continuación. PowerCenter permite procesar directamente como fuente ficheros de tipo VSAM de ancho fijo. Se requiere el uso de PowerExchange para procesar como fuente ficheros de tipo VSAM de ancho variable y como destino ficheros VSAM de cualquier tipo. Se indican a continuación los pasos a seguir cuando se requiera la utilización de un fichero host como fuente de datos en un proceso PowerCenter: 1. Realice la transferencia del fichero de datos via FTP desde el sistema host de origen en modo binario. Esta transferencia puede realizarse o bien de forma directa desde host o bien utilizando una conexión de tipo FTP desde el propio proceso PowerCenter tal y como se indica en la sección 3.3.8. 2. Obtenga un fichero de texto con extensión .cbl conforme al formato especificado a continuación en el que se describa la estructura del fichero de origen. Este fichero ha de ser accesible desde el equipo a utilizar para importar la definición de dicha estructura fuente desde la herramienta cliente PowerCenter Designer. No es necesario almacenar dichos ficheros en el servidor de PowerCenter. Se indica a continuación el formato a utilizar para dicho fichero: environment division. select assign to "fname". data division. file section. fd . 01

. 10 . 10 . 10 . ....

working-storage section. procedure division.

132/201

PowerCenter 8.x – Normativa de Desarrollo

stop run.

Se incluye a continuación el fichero f_RESULCTA.cbl que utilizaremos en nuestro ejemplo:

environment division. select RESULCTA assign to "fname". data division. file section. fd RESULCTA. 01

RESULCTA. 10 10 10 10 10 10 10 10 10 10 10 10

F-FECHA-PROCESO PIC X(10). F-LINEA-GESTION PIC X(12). F-EMPRESA-CAT PIC X(04). F-CENTRO-CAT PIC X(04). F-PRODUCTO-CAT PIC X(03). F-CONTRATO-CAT PIC X(07). F-SUBTIPO-CAT PIC X(03). F-MONEDA PIC X(03). F-SALMED-MES PIC S9(15)V99 COMP-3. F-AJUSTE-MES PIC S9(15)V99 COMP-3. F-FINMES-INTERESES PIC S9(15)V99 COMP-3. F-FINMES-COMISION PIC S9(15)V99 COMP-3.

working-storage section. procedure division. stop run.

3. Tras conectarse al repositorio de desarrollo desde la herramienta cliente PowerCenter Designer pulse sobre la carpeta donde se almacenará la definición de esta estructura fuente y abra la herramienta Source Analyzer. 4. Importar el fichero .cbl utilizando la opción Sources -> Import from Cobol file.

133/201

PowerCenter 8.x – Normativa de Desarrollo

5. Seleccione el fichero .cbl a importar y pulse OK.

6. La definición del fichero fuente aparece en el área de trabajo de la herramienta Source Analyzer. Seleccione la definición del fichero y pulse botón derecho -> Edit para modificar las propiedades del mismo.

134/201

PowerCenter 8.x – Normativa de Desarrollo

7. Pulse Rename.

8. Modifique si es necesario el parámetro Table Name para asignar al fichero un nombre conforme a la nomenclatura definida. Cambie el parámetro Database Name a VSAM para agrupar todas las definiciones de este tipo de ficheros bajo un mismo nombre de conexión. Pulse OK.

135/201

PowerCenter 8.x – Normativa de Desarrollo

9. Compruebe que las opciones IBM COMP y Fixed width se encuentran seleccionadas. Pulse Advanced.

10. Configure los parámetros Code Page = IBM EBCDDIC US English y Number of bytes to skip between records = 0, sustituyendo los valores por defecto por los valores indicados. Pulse OK.

136/201

PowerCenter 8.x – Normativa de Desarrollo

137/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.8. Uso de Conexiones FTP a Sistemas Host En aquellos procesos de carga que utilicen ficheros host como origen de datos será necesario transferir dicho fichero via FTP desde el sistema host de origen al servidor de PowerCenter en modo binario. Esta transferencia puede realizarse o bien de forma directa desde host o bien utilizando una conexión de tipo FTP desde el propio proceso PowerCenter. Este tipo de conexión puede utilizarse para transferir ficheros de origen via FTP desde otros sistemas remotos. Es posible también transferir ficheros de destino de la misma forma. PowerCenter transfiere ficheros en modo binario (BIN) a través de una conexión de tipo FTP. Utilice un script en lugar de una conexión de tipo FTP si es necesario realizar la transferencia en modo ASCII.

PowerCenter permite procesar directamente como fuente ficheros de tipo VSAM de ancho fijo. Se requiere el uso de PowerExchange para procesar como fuente ficheros de tipo VSAM de ancho variable y como destino ficheros VSAM de cualquier tipo.

Se indican a continuación los pasos a seguir para configurar y utilizar una conexión de tipo FTP a un sistema host en un proceso PowerCenter: 1. Tras conectarse al repositorio correspondiente desde la herramienta cliente PowerCenter Workflow Manager pulse Connections -> FTP...

2. La ventana FTP Connection Browser aparece. Esta ventana nos permite seleccionar o crear un objeto de tipo conexión FTP con la información necesaria para que nuestro proceso de carga pueda acceder vía FTP al host donde se encuentra el fichero a tratar. Pulse New.

138/201

PowerCenter 8.x – Normativa de Desarrollo

1. Configure la nueva conexión con los siguientes parámetros:

Opción

Valor

Requerida/

Descripción

Opcional Name

FTP

Requerida

Nombre de conexión PowerCenter.

utilizado

por

User Name

ftpuser

Requerida

Nombre de usuario con acceso al host vía FTP.

Password

********

Requerida

Clave del usuario host.

Hostname

CPUD

Requerida

Nombre o dirección IP del host. PowerCenter utiliza por defecto el puerto 21 para acceder al host vía FTP. Utilice la sintaxis : si es

139/201

PowerCenter 8.x – Normativa de Desarrollo

necesario utilizar un puerto distinto. Default Remote Directory

n/a

Opcional

Directorio FTP en el host. Utilice esta opción si no es posible utilizar el directorio por defecto asignado al usuario. Cuando sea necesario modificar esta opción utilice la sintaxis '' si éste es fijo, o una variable como se describe en el apartado 3.3.4.9.

3. Pulse OK. 4. Pulse Close.

5. Si se trata de un entorno de desarrollo y es necesario que cada desarrollador pueda modificar las propiedades descritas en el paso 11, pulse Permissions y seleccione las opciones Read, Write y Execute para el grupo Developers.

6. Tras crear nuestra conexión FTP ya podemos emplearla en cualquier sesión que utilice como origen o destino ficheros host. Procedemos ahora a modificar un proceso de carga ya

140/201

PowerCenter 8.x – Normativa de Desarrollo

existente donde utilizaremos esta conexión para obtener un fichero de origen directamente del host. 7. Seleccione la sesión y pulse botón derecho -> Edit. Seleccione el apartado Mapping. Pulse sobre Sources -> nrm_f_RESULCTA para revisar las propiedades del fichero fuente utilizado por el proceso de carga.

Opción

Valor

Requerida/

Descripción

Opcional Source file directory

$PMSourceFileDir

Requerida

Ubicación del fichero fuente en el servidor donde se encuentre instalado el servidor de ejecución.

Source filename

CIF.HZ.LR.BDK.HZCRP12J.

Requerida

Nombre utilizar.

SORTC60.LECTURA.PWC.dat

del

fichero

fuente

8. Note que tal y como se encuentra definido nuestro proceso de carga el fichero de origen ha de encontrarse en el servidor de ejecución. Modificaremos ahora las propiedades de nuestra fuente para que el propio proceso obtenga el fichero a procesar directamente del host vía FTP. Seleccione el apartado Connections y asigne al parámetro Type el valor FTP.

141/201

a

PowerCenter 8.x – Normativa de Desarrollo

9. Pulse sobre el icono

para seleccionar la conexión de tipo FTP a utilizar para este origen.

10. Seleccione la conexión FTP a utilizar. Pulse Override…

142/201

PowerCenter 8.x – Normativa de Desarrollo

11. Configure los siguientes parámetros de conexión:

Opción

Valor

Requerida/

Descripción

Opcional Remote Filename

'CIF.HZ.LR.BDK.HZCRP12J.

Is Staged

No Seleccionado

Requerida

Nombre del fichero de origen a obtener del host, delimitado por apóstrofes, o un nombre de parámetro tal como se describe en el apartado 3.3.4.9.

Opcional

Especifica si ha de crearse una copia local del fichero obtenido del host.

SORTC60.LECTURA.PWC'

143/201

PowerCenter 8.x – Normativa de Desarrollo

La opción ‘Is Staged’ nos permite especificar si ha de crearse una copia en local del fichero de origen a transferir en el host antes de que dicho fichero comience a procesarse.

•

Si no se selecciona esta opción el proceso de carga procesa el fichero de origen a medida que se realiza la transferencia, sin crear una copia local del mismo, obteniendo de esta manera un mejor rendimiento.

•

Si se selecciona esta opción el fichero de origen se transfiere en su totalidad al servidor de ejecución, creándose una copia local del mismo con el nombre y ubicación especificados por los parámetros Source file directory y Source file name. La copia local se mantiene en el servidor de ejecución una vez completado el proceso a menos que sea eliminada de forma explícita. Utilice esta opción si ha de transferirse un fichero a utilizar en varios procesos de carga, o en caso de que se detecten problemas de conexión en la transferencia de ficheros con un volumen elevado de datos que causaran el fallo del proceso.

144/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.9. Uso de Tabla de Conversión EBCDIC - ASCII Alternativa PowerCenter utiliza la siguiente tabla de conversión de caracteres EBCDIC a ASCII: { 0x00,0x01,0x02,0x03,0xEC,0x09,0xCA,0x7F,0xE2,0xD2,0xD3,0x0B,0x0C,0x0D,0x0E,0xA9, 0x10,0x11,0x12,0x13,0xEF,0xC5,0x08,0xCB,0x18,0x19,0xDC,0xD8,0x1C,0x1D,0x1E,0x1F, 0xB7,0xB8,0xB9,0xBB,0xC4,0x0A,0x17,0x1B,0xCC,0xCD,0xCF,0xD0,0xD1,0x05,0x06,0x07, 0xD9,0xDA,0x16,0xDD,0xDE,0xDF,0xE0,0x04,0xE3,0xE5,0xE9,0xEB,0xB0,0xB1,0x9E,0x1A, 0x20,0xC9,0x83,0x84,0x85,0xA0,0xF2,0x86,0x87,0xA4,0xD5,0x2E,0x3C,0x28,0x2B,0x7C, 0x26,0x82,0x88,0x89,0x8A,0xA1,0x8C,0x8B,0x8D,0xE1,0x21,0x24,0x2A,0x29,0x3B,0x5E, 0x2D,0x2F,0xB2,0x8E,0xB4,0xB5,0xB6,0x8F,0x80,0xA5,0x7C,0x2C,0x25,0x5F,0x3E,0x3F, 0xBA,0x90,0xBC,0xBD,0xBE,0xF3,0xC0,0xC1,0xC2,0x60,0x3A,0x23,0x40,0x27,0x3D,0x22, 0xC3,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x68,0x69,0xAE,0xAF,0xC6,0xC7,0xC8,0xF1, 0xF8,0x6A,0x6B,0x6C,0x6D,0x6E,0x6F,0x70,0x71,0x72,0xA6,0xA7,0x91,0xCE,0x92,0x0F, 0xE6,0x7E,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7A,0xAD,0xA8,0xD4,0x5B,0xD6,0xD7, 0x9B,0x9C,0x9D,0xFA,0x9F,0x15,0x14,0xAC,0xAB,0xFC,0xAA,0xFE,0xE4,0x5D,0xBF,0xE7, 0x7B,0x41,0x42,0x43,0x44,0x45,0x46,0x47,0x48,0x49,0xE8,0x93,0x94,0x95,0xA2,0xED, 0x7D,0x4A,0x4B,0x4C,0x4D,0x4E,0x4F,0x50,0x51,0x52,0xEE,0x96,0x81,0x97,0xA3,0x98, 0x5C,0xF0,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5A,0xFD,0xF5,0x99,0xF7,0xF6,0xF9, 0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0xDB,0xFB,0x9A,0xF4,0xEA,0xFF }

Esta tabla de conversión es equivalente a una matriz de 256 posiciones, donde cada posición indica el carácter ASCII equivalente al carácter EBCDIC. Para utilizar una tabla de conversión de EBCDIC a ASCII diferente de la que utiliza PowerCenter por defecto seguiremos los pasos descritos a continuación: 1.

Crear un archivo con un editor hexadecimal con la representación de la tabla de conversión a utilizar, ej. us_ebcdic_IBM284.map. Dicho archivo contiene 256 posiciones, donde cada posición indica el carácter ASCII equivalente al carácter EBCDIC. Si este archivo no cumple las especificaciones, es inválido o corrupto, el Integration Service devolverá un error.

2.

Copiar el archivo con la representación de la tabla de conversión a utilizar en el directorio $INFA_HOME/server/bin/locale del servidor de ejecución de PowerCenter.

3.

Modificar la configuración del Integration Service para que utilice la tabla de conversión alternativa, definiendo los siguientes parámetros como Custom Properties para dicho servicio desde la consola de administración, tal y como muestra la siguiente figura:

Figura 101: Configuración de Custom Properties para Integration Service

145/201

PowerCenter 8.x – Normativa de Desarrollo

Custom Property Name

4.

Format

Value (ejemplo)

AlternateEBCDIC

N/A

1

AlternateEBCDICFilename

\

/pwcenter8/Informatica/Powe rCenter8.1.1/server/bin/local e /us_ebcdic_IBM284.map

Reiniciar el Integration Service.

Sección 6.2 incluye el fichero us_ebcdic_IBM284.map utilizado para la conversión de ficheros host con código de página IBM-284.

146/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.10. Reemplazo de REPLACECHR

Caracteres

Especiales

Utilizando

PowerCenter ofrece la función REPLACECHR para reemplazar caracteres especiales cuya presencia pudiera resultar problemática. Esta función puede emplearse por ejemplo para eliminar valores nulos (0x00) que aparezcan en campos alfanuméricos extraídos de ficheros host. Si PowerCenter trata un fichero plano que incluya tal carácter éste se toma como indicador de fin de registro, con lo que se perderán los datos que aparezcan tras el mismo. Para reemplazar caracteres especiales que puedan aparecer en ficheros host utilizando las funciones disponibles en PowerCenter seguiremos los pasos descritos a continuación: 1.

Determinar el valor ASCII del carácter a reeplazar.

2.

Utilizar las funciones CHR(ASCII_VALUE) y REPLACECHR dentro del mapping de PowerCenter que tiene como origen el fichero host.

Por ejemplo, para reemplazar valores nulos dentro de un campo alfanumérico, emplearíamos la siguiente expresión: Sintaxis: REPLACECHR(0,,CHR(0),'') Ejemplo: REPLACECHR(0,INFORREF_TEXT,CHR(0),'') La función REPLACECHR puede invocarse de forma anidada para reemplazar múltiples carecteres dentro de una misma expresión: REPLACECHR(0,REPLACECHR(0,REPLACECHR(0,INFORREF_TEXT,CHR(13),''),CHR(1 0),''),CHR(0),''). Se recomienda que aquellos procesos que requieran del uso de esta estrategia definan un mapplet de limpieza de campos alfanuméricos para su posterior utilización en todos los procesos donde sea necesario dicho tratamiento.

3.3.11. Uso de Shortcuts Los shortcuts o accesos directos de PowerCenter ofrecen una funcionalidad parecida a la de los accesos directos en Windows, permitiendo referenciar un objeto y emplear todas sus propiedades sin tener que hacer una nueva copia del mismo. Los cambios realizados sobre el objeto original serán visibles inmediatamente desde todos los shortcuts al mismo, facilitando la reutilización de objetos y simplificando enormemente las tareas de mantenimiento y análisis de impacto. PowerCenter permite crear shorcuts desde cualquier carpeta a cualquier objeto incluido en una carpeta compartida. Si se intenta crear un shortcut a un objeto incluido en una carpeta no compartida se creará una copia del objeto en su lugar.

147/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 102: Ejemplo de shorcut desde una carpeta de proyecto a una estructura destino compartida. En un repositorio con el versionado habilitado los shortcuts siempre hacen referencia a la última versión del objeto. Se pueden crear shortcuts a los siguientes objetos, siempre que dichos objetos se encuentren en una carpeta compartida: Estructuras Fuente. Estructuras Destino. Mappings. Mapplets. Transformaciones. Por otro lado, se pueden crear los siguientes tipos de shortcuts: Shortcuts locales: Los creados en el mismo repositorio en el que residen los objetos originales. Shortcuts globales: Aquellos creados en un repositorio local y que hacen referencia a objetos que residen en repositorios globales.

148/201

PowerCenter 8.x – Normativa de Desarrollo

En la pantalla de edición de un shortcut se puede comprobar el repositorio, la carpeta y el nombre del objeto al que hace referencia, como se muestra a continuación:

Figura 103: Información acerca del objeto referenciado por un shortcut. La pantalla de edición de un shorcut incluye una opción de renombrado (Rename) a utilizar en caso de haberse modificado accidentalmente el nombre asignado por defecto al mismo (Shortcut_to_NombreObjeto). La edición de un shortcut debe hacerse siempre en el editor asociado; es decir, una modificación a un shortcut que referencie a una estructura fuente compartida deberá hacerse a través del Source Analyzer, si hace referencia a una estructura destino, en el Target Designer, etc.

149/201

PowerCenter 8.x – Normativa de Desarrollo

PowerCenter permite crear un único shortcut por carpeta a un determinado objeto compartido. Se establece por normativa el uso de la nomenclatura Shortcut_to_NombreObjeto para los mismos, de forma que todos los shortcuts a un mismo objeto compartido reciban el mismo nombre independientemente de la carpeta en la que se encuentren, evitando de esta forma errores al copiar objetos entre carpetas.

Figura 104: Shortcuts al mismo destino compartido desde distintas carpetas. Se mantiene el nombre por defecto para evitar errores al copiar objetos entre carpetas. Si el proceso de copia de objetos encuentra que en la carpeta de destino ya existe un shortcut al mismo objeto compartido con un nombre distinto al del shortcut a copiar el proceso de copia fallará con el siguiente error:

Figura 105: Error al copiar objetos entre carpetas generado si ya existen shortcuts en la carpeta de destino con un nombre distinto al del shorcut en la carpeta de origen.

150/201

PowerCenter 8.x – Normativa de Desarrollo

La nomenclatura establecida para shortcuts no aplica a las instancias de los mismos dentro de un mapping o mapplets. Asignaremos un nombre descriptivo a cada instancia de acuerdo a nuestras necesidades, manteniendo siempre el prefijo Shortcut_to_ en cada instancia, como muestra el siguiente ejemplo.

Figura 106: Instancias de un shortcut a un destino compartido incluidas en un mismo mapping. Asignaremos un nombre descriptivo a cada instancia, manteniendo siempre el prefijo Shortcut_to.

3.3.12. Generación dinámica de ficheros de salida con FileName En una estructura destino de tipo Flat File se puede incluir una columna especial, de nombre FileName, mediante un icono adicional en la pestaña de columnas, tal como se muestra en la siguiente figura:

151/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 107: Inclusión de la columna especial FileName en una estructura destino de tipo Flat File. Dicha columna FileName se emplea junto con la gestión de puntos de control que proporciona la transformación Transaction Control para controlar el nombre de los ficheros de salida que se generarán durante la ejecución de la sesión. En la columna FileName se dejará el nombre del fichero de salida deseado, y desde la transformación Transaction Control se emitirá un punto de control COMMIT para que el Integration Service que esté ejecutando la sesión cierre el fichero actual y pase a abrir un nuevo fichero con el nombre indicado en FileName. Por ejemplo, si deseamos generar un fichero distinto por cada código de provincia presente en el fichero origen de clientes, el mapping que debemos construir será el siguiente:

Figura 108: Ejemplo de mapping que genera ficheros de salida dinámicamente mediante el uso de la transformación Transaction Control y la columna especial FileName. En primer lugar, mediante una transformación Sorter se ordena el conjunto de datos de entrada por el campo que determinará el contenido de cada fichero de salida, en este caso la provincia. A continuación, se evalúa en una transformación de tipo Expression si el registro que se está tratando es el primero de un nuevo bloque de datos con una nueva provincia, empleando por ejemplo los siguientes nuevos puertos: Port Name CHKPROV OLDPROV NEWPROV FILENAME

Datatype string string string string

Prec 1 15 15 40

I

O

x x

V x x

Descripción IIF(PROVINCIA = OLDPROV, '0', '1') PROVINCIA CHKPROV CONCAT('f_CLIENTES_',CONCAT(PROVINCIA, '.dat'))

Donde: •

La variable CHKPROV evalúa si el nuevo registro leído conserva la misma provincia que el anterior.

•

Para poder emplear el resultado de CHKPROV en las siguientes transformaciones, hace falta crear el puerto de salida NEWPROV.

•

La variable OLDPROV, al estar situada después de CHKPROV, siempre conservará el valor de PROVINCIA del registro anterior.

•

En el campo FILENAME almacenamos el nombre de fichero de salida que se desea obtener, en este caso: f_CLIENTES_.dat, donde es el valor de PROVINCIA tal cual se ha obtenido del fichero de entrada.

Finalmente, en una transformación del tipo Transaction Control generamos los puntos de control necesarios para que el Integration Service gestione correctamente los ficheros de salida, a partir del valor del puerto NEWPROV, mediante la siguiente condición en la propiedad Transaction Control Condition: IIF(NEWPROV = '1', TC_COMMIT_BEFORE, TC_CONTINUE_TRANSACTION)

152/201

PowerCenter 8.x – Normativa de Desarrollo

Para incluir los valores TC_COMMIT_BEFORE y TC_CONTINUE_TRANSACTION podemos emplear los elementos presentes en Variables  Built-in:

Figura 109: Construcción de la condición Transaction Control Condition mediante el editor de expresiones. Esta expresión le indica a la transformación que emita un COMMIT antes (BEFORE) de terminar de procesar el registro en el que se ha detectado un cambio de provincia, o en caso contrario continuar con la transacción actual (es decir, el bloque de clientes que pertenecen a la misma provincia). Una vez conectado el puerto FILENAME generado en la transformación Expression con la columna especial FileName en la estructura destino, tras la ejecución del mapping comprobaremos que se ha generado un fichero de salida por cada valor de provincia presente en el conjunto de datos de entrada. Nota importante: Pese a que el mapping emplea la columna FileName para definir el nombre de los ficheros de salida, aún así hay que modificar el valor del atributo “Output Filename” dentro de las propiedades de la sesión para la estructura destino, y darle un nombre que permita diferenciarlo fácilmente de los auténticos ficheros de salida (por ejemplo, añadiendo en primer lugar una guión bajo como prefijo: _f_CLIENTES.dat):

Figura 110: Edición del atributo “Output Filename” en las propiedades de la sesión para poder distinguir fácilmente el fichero de salida por defecto. La razón consiste en que al ejecutar el workflow siempre se generará en primer lugar un fichero con ese nombre y cero registros. Por tanto, dicho fichero habrá que eliminarlo mediante un comando de sistema operativo a ejecutar como una Post-session Task.

153/201

PowerCenter 8.x – Normativa de Desarrollo

3.3.13. Uso de opción Update Override La opción Update Override es una propiedad de los destinos relacionales que permite cambiar la sentencia SQL que se ejecuta en un destino relacional. Esta opción puede utilizarse con sentencias de tipo INSERT, UPDATE o DELETE. Esta funcionalidad se puede implementar de dos maneras diferentes: mediante el uso de transformaciones Update Strategy o sin el uso de las mismas. En las siguientes secciones se detallan ambas operativas.

3.3.13.1. Con Transformaciones Update Strategy Es necesario introducir en el mapping una transformación de tipo Update Strategy por cada tipo de operación que se va a realizar (INSERT, UPDATE y/o DELETE). En estas transformaciones se establece siempre como valor de la propiedad Update Strategy Expression la variable especial DD_UPDATE.

Figura 111: Establecimiento del valor en la propiedad Update Strategy Expression.

A continuación se insertan en el mapping los destinos relacionales sobre los que se tienen que ejecutar las sentencias SQL. Una vez introducidos se debe cumplimentar en cada uno de ellos la propiedad Update Override. En ella se establece la sentencia SQL que se va a ejecutar en cada caso. Para ello se abre el Editor SQL, pulsando el botón recuadrado en la siguiente figura:

154/201

PowerCenter 8.x – Normativa de Desarrollo

Figura 112: Apertura del Editor SQL.

A continuación se pulsa el botón Generate SQL, generándose de manera automática una sentencia UPDATE con la sintaxis adecuada:

Figura 113: Generación automática de la sentencia SQL.

Como se aprecia en la figura anterior, se genera una sentencia UPDATE standard en función de los puertos de entrada al destino relacional. Los puertos de entrada se referencian con la sintaxis :TU.