La replicación incremental de datos, el enmascaramiento, la integración (ETL) y otras operaciones de actualización de datos son comunes en los entornos de bases de datos que se actualizan con frecuencia. Estos trabajos requieren la detección de adiciones y actualizaciones en las tablas. Estas operaciones dinámicas son fáciles de automatizar en los flujos de trabajo de IRI Voracity diseñados y ejecutados en IRI Workbench (WB).
Este artículo contiene un ejemplo de flujo de trabajo que los usuarios de las ediciones DBMS de Voracity, FieldShield, CoSort o NextForm pueden implementar para verificar regularmente los cambios en una tabla de origen (Oracle en este caso) para decidir cuándo mover los datos a un nuevo destino (MySQL). También muestra cómo los datos se pueden enmascarar condicionalmente como parte de este proceso. Tenga en cuenta que IRI también está trabajando en un enfoque basado en registros para incrementar los datos en tiempo real sin necesidad de valores de columna delta.
Los cambios se pueden cargar en diferentes bases de datos o archivos utilizando un archivo por lotes programado para tareas o un script de shell. Esto se puede hacer usando una marca de tiempo y campos específicos en la tabla de origen. La verificación de errores también está incluida y también se puede actuar en consecuencia.
Este ejemplo fue creado y ejecutado en una máquina con Windows. Se puede modificar fácilmente para que funcione en una plataforma Linux o Unix.
Crear el archivo por lotes es fácil usando un diagrama de Flujo de Voracidad en WB. En este ejemplo, la tabla de origen contiene columnas denominadas CREATED_DATE y FECHA_ACTUALIZADA que son importantes en este trabajo.
La siguiente imagen muestra los pasos que están contenidos en el archivo por lotes. Para resumir:
- el trabajo se ejecuta en un directorio específico
- una variable de entorno se establece utilizando la marca de tiempo de la última ejecución del trabajo
- se registra la marca de tiempo actual
- se capturan los cambios actuales
- el nivel de error se verifica y se actúa si tiene éxito o no
- la marca de tiempo actual sobrescribe la marca de tiempo de la última ejecución
- Se utiliza una regla para redactar correos electrónicos que terminan en "edu" en el destino
- se usa una regla para redactar parcialmente el campo SSN en el objetivo
- los datos modificados se cargan en MySQL
- se verifica el nivel de error, se cambia el nombre del archivo de marca de tiempo temporal
Cada bloque de tareas en el flujo de trabajo se explica a continuación. Los dos bloques de color malva son bloques de mapeo de transformación y representan secuencias de comandos de trabajo CoSort SortCL. Los diagramas de asignación y los guiones de trabajo representados por cada uno de los bloques se muestran a continuación para mayor claridad. Para obtener información sobre cómo crear flujos de trabajo de Voracity desde la paleta, consulte este artículo.
Cambiar directorio
Este bloque cambia el directorio de trabajo actual al especificado.
Establecer ÚLTIMA HORA
Este bloque de línea de comando establece una variable de entorno llamada LASTTIME . El valor establecido en la variable es el contenido del archivo LastTime.txt . La marca de tiempo en este archivo es la marca de tiempo que se registró durante la última ejecución de este trabajo. Si esta es la primera ejecución, este archivo deberá crearse manualmente con una marca de tiempo arbitraria con fecha anterior a la ejecución de este trabajo.
Este archivo contiene una línea:"2008-09-10 09:39:23.5"
Marca de tiempo.scl
Esta tarea utiliza el programa SortCL para consultar la base de datos de origen para la hora actual. Esa marca de tiempo se guarda en un archivo llamado LastTimeTemp.txt . La razón por la que se almacena en un archivo temporal es para que tanto la marca de tiempo actual como la última se puedan conservar hasta que se produzca la comprobación de errores.
Es importante que la marca de tiempo provenga de la base de datos y no de la máquina local. Esto evita problemas donde la base de datos y el entorno de ejecución no están sincronizados.
El diagrama de mapeo y el script serializado para este trabajo son los siguientes:
Cambios.scl
Este trabajo realiza la extracción principal, la transformación y la carga. La entrada es la tabla de origen en Oracle y la salida es una tabla con formato similar en MySQL:
En la sección de entrada, se envía una consulta a la tabla de origen para todos los registros que tienen un CREATED_DATE o FECHA_ACTUALIZADA mayor que la variable de entorno LASTTIME . La consulta es “SELECCIONE * DE SCOTT.CLIENTE DONDE SE CREÓ> TO_TIMESTAMP(\'$LASTIME\', \'YYYY-MM-DD HH24:MI:SS.FF1\') O (ACTUALIZADO> TO_TIMESTAMP(\'$LASTIME\ ', \'AAAA-MM-DD HH24:MI:SS.FF1\'))”.
Además, se agrega una condición para verificar el EMAIL columna para datos que terminan en "edu". Esto se usará en una función de enmascaramiento de datos condicional en la salida. En la salida, un If-Then-Else declaración se agrega al EMAIL columna. Utiliza la condición creada previamente para probar los datos. Si los datos terminan en "edu", la dirección de correo electrónico se redacta. De lo contrario, la dirección de correo electrónico se copia de la entrada.
Se utiliza una segunda función de redacción en el SSN columna. Elimina los tres primeros caracteres, deja el guión, elimina los dos caracteres siguientes, deja el guión y deja los últimos cuatro caracteres. Por ejemplo ***-**-6789.
A continuación se muestra el script de trabajo SortCL serializado descrito anteriormente para que pueda examinar la consulta y la sintaxis condicional involucrada en los deltas incrementales:
Coordenación de errores
El bloque de decisión comprueba la variable ERRORLEVEL para asegurarse de que devolvió 0 (para el éxito) después de ejecutar el trabajo SortCL anterior. Si no lo hizo, el trabajo continúa hasta el FIN bloque donde finaliza el trabajo. Si devuelve verdadero, el trabajo continúa con el siguiente bloque.
Renombrar LastTimeTemp
Este bloque de comando copia el contenido de LastTimeTemp.txt a ÚltimaHora.txt . Esto registra la marca de tiempo actual capturada previamente en el archivo que se usará para la próxima ejecución del trabajo.
Archivo por lotes
El archivo por lotes y los scripts de transformación se crean cuando se exporta el diagrama de flujo (que se muestra arriba). A continuación se muestra una copia del archivo por lotes. Cada bloque agrega líneas ejecutables al archivo por lotes.
Programador de tareas
Con el Programador de tareas de Windows, este archivo por lotes se puede ejecutar repetidamente para capturar los cambios en la base de datos de origen.
Conclusión
Con un poco de planificación y el uso de bloques de comandos, los cambios en una tabla de base de datos pueden detectarse automáticamente mediante un archivo por lotes y luego programarse para ejecutarse a intervalos seleccionados para que pueda mover, mapear, enmascarar y manipular los datos modificados en un base incremental.
Comuníquese con [email protected] o con su representante de IRI para obtener más información o ayuda con su caso de uso.
