Auditorías de Altas, Bajas, Consultas y Modificaciones
Ramiro Pérez Acebo - Octubre 2013
Si necesitamos registrar las Altas, Bajas, Consultas (desde Formularios) y/o Modific. de registros, podemos hacerlo de forma genérica con solo 3 Tablas...
La Tabla de Conexiones conserva el Usuario, IP y Aplicación. Cada conexión se graba en On-Show del Autoexec y su ID pasa a una Var. global en memoria.
La Tabla de Estructuras registra el Módulo y la Tabla así como el número de Campos y los Nombres e Identificadores de los mismos.
La Tabla de Registros contiene punteros a las Tabla de Conexiones y de Estructuras y otros campos para identificar la Tabla, Módulo, Registro y Tipo de Auditoría así como la Fecha, Hora y Contenido (sin incluir campos objeto) del registro auditado. Esta sería su estructura...
Con estos elementos, podemos realizar la Auditoría de la siguiente forma:
1. Auditoría de Consultas: En el manejador de evento On-Show del Formulario se usa una Función (AUD_ACT) para comprobar la configuración de Auditoría de la Tabla (la Función devuelve una cadena con 4 valores de tipo 0/1, que representan, por orden, auditoría de Altas, Bajas, Consultas y Modificaciones). Si la Auditoría de Consultas está activa, el registro se pasa a un proceso (lo veremos posteriormente) que es quien realiza el trabajo.
En este caso el parámetro (#MT+“#) pasado a la Función contiene el ID del Módulo y el Nombre de la Tabla + un separador. Esto es poco relevante, pudiendo sustituirse por cualquier otro método que permita obtener la configuración de auditorías de la Tabla.
2. Auditorías de Altas, Bajas ó Modificaciones: Son tareas que se realizan en los respectivos procesos Post de la Tabla (excepto en las Bajas, que se registra en el Pre porque la rutina JavaScript que lee el contenido del registro ya no puede acceder a esa información en el Post).
En estos Procesos de Tabla se usará la misma Función AUD_ACT para comprobar si la respectiva auditoría está activa. La diferencia respecto a la Auditoría de Consulta es que ahora estamos en 3P y necesitamos una Función que recupere el Número de Conexión en el que nos encontramos. Además la variable PAR_07_A_TIP tendrá el valor A-B-M, Alta, Baja ó Modif., según convenga en cada caso.
La Función AUD_CNX_GET_ULT permite obtener la Conexión del Usuario que ha lanzado la tarea que se está completando en el Proceso de Tabla. A esa Función le pasamos el ID del Usuario y su IP actual (ambos datos se resuelven bien incluso estando en 3P) y con tales valores la Función carga las conexiones del Usuario desde esa IP, seleccionando la de Dia-Hora de modificación más reciente (valor que se ha actualizado, en el registro de la Conexión Activa, desde los Manejadores de Evento de Aceptar y Eliminar del Formulario, justo inmediatamente antes de que la tarea de auditoría se complete en 3P)
Como se ha visto, casi todo se reduce a las tareas que realice el proceso Principal (de ficha de la Tabla a auditar) que en nuestro ejemplo se llama PEL_ESC_1___AUD. Desde ese proceso se ejecutan otros dos procesos: el que llamaré Secundario invoca una rutina JavaScript que lee los datos del registro y devuelve sus valores, mientras que el Grabador usa esos valores y algunos otros (los dos primeros, que identifican la Tabla y el Registro a auditar) para realizar la grabación de los datos.
Resumiendo: Para cada Tabla a auditar necesitaremos:
2 procesos de ficha de la Tabla
Un Proceso Principal con contenido casi idéntico a la siguiente imagen (de hecho es idéntico en todo salvo en su origen y en que el nombre del proceso JS secundario llamado al inicio no puede ser el mismo) y un Proceso Secundario, de Tipo JavaScript, que apunte al fichero Js que luego veremos
1 Proceso Grabador de los datos, sin origen y común para todas las Tablas
Proceso Principal
Proceso Secundario, de tipo JS (mejorable, agradeceré vuestras sugerencias):
Proceso Grabador
Primero se comprueba si los datos de estructura recibidos coinciden con los últimos datos de estructura existentes para esa misma Tabla (si no coinciden se graba un nuevo registro que consolide la información de la nueva estructura)
Después se graban los datos del Registro a Auditar.
Finalizadas estas tareas se habrá grabado el registro de Auditoría, que contiene los datos Auditados y también campos punteros a la Tabla de Conexiones (con los datos del Usuario, IP, Aplicación...) y a la Tabla de Estructura (con los Nombres e Identificadores de los Campos de la Tabla a la que corresponde el registro auditado).
Una particularidad a tener en cuenta es que en caso de auditar la CONSULTA de registros, no siempre será necesario grabar la información de los campos del registro consultado. En estos casos lo razonable es comprobar si el contenido del registro a auditar coincide con la que esté grabada en la última auditoría que tenga registrados datos. Si la información coincidiera bastaría con que el nuevo registro de Auditoría apuntase a aquel registro con datos (sin necesidad de grabarlos de nuevo).
Podríamos preguntarnos ¿Porqué registrar la Estructura de la Tabla?
Esta información es imprescindible para permitir la presentación (con un único formulario) de los datos auditados correspondientes a cualquier tabla. Pero eso es otra historia que se contará en el siguiente Artículo...
Se agradecerá cualquier sugerencia en orden a mejorar el sistema...