Gu A B Sica De PWC
Páginas: 16 (3965 palabras)
Publicado: 10 de abril de 2015
La organización de componentes para en un entorno de PowerCenter v.9.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 ala 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.9.x configurado de acuerdo a la arquitectura descrita:
La figura siguiente muestra la conectividad entre componentes en un entorno dePowerCenter v.9.x configurado de acuerdo a la arquitectura descrita:
Existen 3 aplicaciones cliente que vamos a usar para detectar incidencias:
Designer : lo usaremos para ver las transformaciones que forman el proceso ETL, es decir, los mapping.
Workflow Manager: lo utilizaremos para revisar las sesiones que componen los workflows. Un workflow es un proceso ETL. Está formado por una o variassesiones y cada sesión tiene asociada un mapping. Esto significa que cada sesión tiene sus entradas, sus salidas, sus transformaciones, sus salidas y sus ficheros de parámetros. Las entradas de la primera sesión son las entradas del proceso (que suelen ser los ficheros de entrada) y las salidas de la última sesión son las salidas del proceso.
Monitor: sirve para monitorizar las ejecuciones de losprocesos y para localizar y evidenciar incidencias.
MONITOR
A) Visualización:
Vamos a empezar por esta aplicación porque es la herramienta principal para detectar problemas. La pantalla se divide en 3 zonas:
La zona 1 sirve para escoger qué procesos (workflows) se quieren revisar. Vamos a abrir las carpetas 4998 y 4993. En un principio tenemos esto:
Damos doble click o botón derecho->abrir:Aparecen los procesos ejecutados o ejecutándose de esa carpeta en la zona 2. Debemos expandir cada proceso para llegar a ver las sesiones. Por ejemplo voy a expandir el wf Tipo_Cambio_AP haciendo doble click sobre él:
Nos muestra que ese wf ha sido lanzado 15 veces con éxito y con las fechas de inicio/fin. Si hacemos doble clik sobre un wf con bandera amarilla:
Nos aparecen las sesiones quecomponen ese wf y su estado. Un wf será Success si todas sus sesiones acaban en Sucess.
De esta forma “anclamos” una carpeta a la zona 2.
Una función útil es escoger cuántas ejecuciones se quieren visualizar por cada workflow. En la opción Filter-> Most Recent Runs->número de ejecuciones que se quieran ver. Esto es útil porque de lo contrario se llena la zona 2 de wf y cuesta ver lo se lanza nuevo.B) Ficheros de Log:
PWC proporciona dos ficheros de log con las ejecuciones de los procesos. El log de sesión y el log de wf. Usaremos el log de sesión cuando una sesión falle para comprobar el por qué. Para ver el fichero de log pulsamos botón derecho sobre la sesión fallada y escogemos Get Session Log:
Y nos aparece esto:
Para ver los errores podemos buscarlos en el documento. Lacolumna Severity pondrá ERROR. Si pulsamos el botón aparece directamente los errores en la parte de arriba:
Es bueno adjuntar este fichero cuando se abren incidencias. Para ello le damos al botón Save As.
Hay ocasiones en las que no está disponible el log de una sesión que ha fallado o que ni siquiera se ha lanzado. Esto se produce cuando se ejecuta el wf pero no se lanza ninguna sesión(por problemasen los .var o en la conexión) o por ciertos problemas con el repositorio de PWC. En estos casos para saber lo que ha fallado usamos el log del workflow pulsando botón derecho sobre el wf->Get Workflow Log:
Se usa la misma casuística en este log que en el anterior.
C) Entradas y salidas de sesiones:
Si es necesario revisar un mapping para saber si hay incidencia o para hacer bien los juegos de...
La organización de componentes para en un entorno de PowerCenter v.9.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 ala 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.9.x configurado de acuerdo a la arquitectura descrita:
La figura siguiente muestra la conectividad entre componentes en un entorno dePowerCenter v.9.x configurado de acuerdo a la arquitectura descrita:
Existen 3 aplicaciones cliente que vamos a usar para detectar incidencias:
Designer : lo usaremos para ver las transformaciones que forman el proceso ETL, es decir, los mapping.
Workflow Manager: lo utilizaremos para revisar las sesiones que componen los workflows. Un workflow es un proceso ETL. Está formado por una o variassesiones y cada sesión tiene asociada un mapping. Esto significa que cada sesión tiene sus entradas, sus salidas, sus transformaciones, sus salidas y sus ficheros de parámetros. Las entradas de la primera sesión son las entradas del proceso (que suelen ser los ficheros de entrada) y las salidas de la última sesión son las salidas del proceso.
Monitor: sirve para monitorizar las ejecuciones de losprocesos y para localizar y evidenciar incidencias.
MONITOR
A) Visualización:
Vamos a empezar por esta aplicación porque es la herramienta principal para detectar problemas. La pantalla se divide en 3 zonas:
La zona 1 sirve para escoger qué procesos (workflows) se quieren revisar. Vamos a abrir las carpetas 4998 y 4993. En un principio tenemos esto:
Damos doble click o botón derecho->abrir:Aparecen los procesos ejecutados o ejecutándose de esa carpeta en la zona 2. Debemos expandir cada proceso para llegar a ver las sesiones. Por ejemplo voy a expandir el wf Tipo_Cambio_AP haciendo doble click sobre él:
Nos muestra que ese wf ha sido lanzado 15 veces con éxito y con las fechas de inicio/fin. Si hacemos doble clik sobre un wf con bandera amarilla:
Nos aparecen las sesiones quecomponen ese wf y su estado. Un wf será Success si todas sus sesiones acaban en Sucess.
De esta forma “anclamos” una carpeta a la zona 2.
Una función útil es escoger cuántas ejecuciones se quieren visualizar por cada workflow. En la opción Filter-> Most Recent Runs->número de ejecuciones que se quieran ver. Esto es útil porque de lo contrario se llena la zona 2 de wf y cuesta ver lo se lanza nuevo.B) Ficheros de Log:
PWC proporciona dos ficheros de log con las ejecuciones de los procesos. El log de sesión y el log de wf. Usaremos el log de sesión cuando una sesión falle para comprobar el por qué. Para ver el fichero de log pulsamos botón derecho sobre la sesión fallada y escogemos Get Session Log:
Y nos aparece esto:
Para ver los errores podemos buscarlos en el documento. Lacolumna Severity pondrá ERROR. Si pulsamos el botón aparece directamente los errores en la parte de arriba:
Es bueno adjuntar este fichero cuando se abren incidencias. Para ello le damos al botón Save As.
Hay ocasiones en las que no está disponible el log de una sesión que ha fallado o que ni siquiera se ha lanzado. Esto se produce cuando se ejecuta el wf pero no se lanza ninguna sesión(por problemasen los .var o en la conexión) o por ciertos problemas con el repositorio de PWC. En estos casos para saber lo que ha fallado usamos el log del workflow pulsando botón derecho sobre el wf->Get Workflow Log:
Se usa la misma casuística en este log que en el anterior.
C) Entradas y salidas de sesiones:
Si es necesario revisar un mapping para saber si hay incidencia o para hacer bien los juegos de...
Leer documento completo
Regístrate para leer el documento completo.