¿Con qué frecuencia te preguntas a ti mismo: ¿por qué no hay nada similar al universo de auditoría que viene como una característica predeterminada en la plataforma de inteligencia empresarial de SAP 4.0 para auditar ETL? ¿Qué tan útil sería tener una tabla de auditoría con el fin de guardar información útil sobre los servicios de datos corrió puestos de trabajo? Todos sabemos que puede auditar algunas cosas a través de DSCM (Data Services Management Console), pero ¿puede hacerlo en el nivel de fila? Con el fin de resolver todas estas preguntas, este artículo explica una solución para la auditoría de la ETL en el nivel de fila y hacer su vida más fácil cuando se producen errores, cuando se necesita un análisis o si sólo están de seguimiento de datos.
La idea es bastante simple y la parte principal de ella consiste en una tabla (Load_Audit_Table). Esta tabla contiene varias columnas que incluyen un identificador único denominado "Load_Key" y algunas otras columnas que contienen:
- el nombre del usuario que ejecutó el trabajo
- el nombre del trabajo corrió
- la fecha y la hora de inicio
- la fecha y la hora de finalización
- Un campo booleano para identificar si el trabajo terminó por error o no
- el mensaje de error
- la descripción de la ubicación del archivo de registro.
Por supuesto usted puede agregar más columnas dependiendo de sus necesidades.
La otra parte importante de la solución es una columna llamada "Load_Key" y esa columna debe aparecer en todas las tablas que usamos en ETL (tablas ODS, tablas FACT, etc.).
El propósito de esta solución es darnos la posibilidad no sólo de identificar fácilmente un error sino también de auditar en el nivel de fila. Esto significa que también podemos analizar o rastrear los datos que se han cargado en una cierta fecha durante todo el proceso porque todas las filas de todas las tablas que habían cargado en esta fecha tendrán la misma "Load_key". Echa un vistazo al siguiente ejemplo.
Cada vez que se ejecuta el ETL, se genera una nueva clave de carga generada automáticamente y se carga en el Load_Audit_Table y en todas las demás tablas del sistema si no hay errores.
Ahora que entendemos cómo funciona y el valor de esta implementación, necesitamos explicar cómo desarrollar esta solución en términos de objetos, códigos, etc.
En la imagen de abajo se encuentra la estructura de trabajo desarrollada para implementar el método de auditoría:
Como se puede ver en la imagen, el trabajo es SIEMPRE Compuesto por dos flujos de trabajo, uno al principio llamado " Audit_start" Y una segunda al final del trabajo denominado " Audit_End ".
El trabajo que queremos auditar se encuentra en el medio, en nuestro ejemplo estamos auditando el flujo de trabajo que carga las tablas de dimensiones. Además, el flujo de trabajo principal debe estar rodeado por los bloques "Try" y "Catch" para obtener la información de error al final del trabajo en caso de fallo.
Ahora veamos lo que hay dentro de cada uno de estos bloques para entender cómo funciona el sistema de auditoría.
En la imagen de abajo mostramos lo que hay dentro del primer bloque, "Audit_Start".
En este paso generamos el identificador único para la tabla de auditoría. Es muy simple: en el bloque de código llano añadimos una función SQL que extrae la última clave de la tabla de auditoría más 1.
Sql ('Datawharehouse', 'select max (load_key) + 1 de audit_table)
Luego, dentro del flujo de datos, generamos una nueva fila para agregar la nueva clave en la tabla de auditoría.
El siguiente bloque es Try, pero este bloque no se puede modificar porque es sólo un bloque que da una bandera para registrar la información de error. Lo único que tenemos que hacer es añadirlo al trabajo y crear los enlaces.
Después del trabajo principal, el bloqueo Catch es el siguiente. En este caso, Catch es editable: al abrir el bloque con un doble clic podemos agregar objetos.
En la imagen de abajo puedes ver lo que hay dentro del bloque Catch.
En primer lugar, tenemos el flujo de trabajo Audit_End, y usted puede preguntar por qué? El motivo es que cuando se produce un error, el trabajo finaliza en el bloque Catch. Esto significa que si no hubiéramos recibido el bloque Audit_end dentro del bloque Catch, cada vez que hubiera un error, habríamos faltado información importante.
Entonces un bloque de código llano viene; Dentro de él hay un código que nos proporciona toda la información de error y el código que nos permite actualizar la nueva fila creada para la nueva load_key.
Sql ('DataWarehouse', 'update load_audit set is_error =' 1 ', error_num =' || error_number () || ', error_desc =' '
|| Error_message () || '' Donde load_Key = '|| $ G_Job_Load_key);
Por último, el último paso es añadir el bloque "Audit_End" que nos proporciona la fecha y la hora cuando el trabajo está terminado. Para ello escribimos un código SQL que añade esta información a la tabla Audit_table.
Sql ('DataWarehouse', 'update load_audit set job_end_date = sysdate donde load_Key =' || $ G_Job_Load_key);
¡Ahora ha implementado el método de auditoría desarrollado por los consultores de Clariba! Además, puede utilizar esta tabla de auditoría para grabar un mensaje de correo electrónico cuando se produce un error. Puede configurarlo leyendo la columna "Is_Error" y si el registro es "1" envíe un correo electrónico al administrador de BO con la información de error guardada en la misma tabla.
Esperamos que esto sea útil para usted. Si tiene alguna pregunta o observación, por favor deje un comentario a continuación.
Para que esto funcione, el primer paso es tener las tecnologías adecuadas para automatizar los procesos de negocio repetitivos, reducir el error humano, apoyar la comunicación y la colaboración y monitorear el desempeño.
