La detección de adiciones y actualizaciones a las tablas de la base de datos para la replicación de datos, ETL, enmascaramiento de PII y otras actividades incrementales de movimiento y manipulación de datos se pueden automatizar en los flujos de trabajo de IRI Voracity diseñados y ejecutados en IRI Workbench (WB). Este artículo explica cómo verificar regularmente los cambios en las tablas de origen de Oracle para decidir cuándo mover los datos a un destino de MongoDB.
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 está incluida y también se puede reaccionar.
Este ejemplo se creará y ejecutará en una máquina con Windows; sin embargo, se puede modificar fácilmente para que funcione en una plataforma similar a 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 CREATION_DATE y ACTUALIZAR_FECHA 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
- los datos modificados se convierten a CSV
- Se produce un bloqueo para esperar a que exista el último archivo
- el archivo CSV se importa a MongoDB
- el nivel de error está comprobado, el archivo actual está truncado
- el archivo de cambios se elimina
Cada bloque de tareas en el flujo de trabajo se explica a continuación. 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.
Marca de tiempo.scl
Este bloque de transformación utiliza el programa CoSort SortCL en Voracity 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 las marcas de tiempo actual y ú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.
Cambios.scl
Este bloque de transformación hace algunas cosas. A continuación se muestra el diagrama de mapeo de transformación para este bloque. La entrada es la tabla de origen y la salida es el archivo current.txt .
En la entrada Opciones de sección, se envía una consulta a la tabla de origen para todos los registros que tienen una CREATION_DATE o ACTUALIZAR_FECHA mayor que la variable de entorno LASTTIME .
Si bien la salida parece tener dos objetivos, los datos en realidad se agregan al mismo archivo utilizando dos condiciones diferentes. En la primera sección de salida, hay un Incluir declaración que encuentra todos los registros que tienen un CREATION_DATE mayor que LASTIME . También hay un campo de salida adicional llamado CDC_TYPE . La cadena “CREATE” se registra en ese nuevo campo.
En la segunda sección de salida, un Incluir declaración encuentra todos los registros que tienen un UPDATE_DATE mayor que LASTIME y donde FECHA_DE_CREACIÓN no es igual a UPDATE_DATE. Esto garantiza que los archivos recién creados no se incluyan en este pase. La cadena "ACTUALIZAR" se registra en CDC_TYPE.
Coordenación de errores
Este bloque de decisión comprueba la variable ERRORLEVEL para asegurarse de que devolvió 0 (o éxito) después de ejecutar el trabajo CoSort anterior. Si no lo hizo, el trabajo continúa hasta SALIR bloque donde finaliza el trabajo. Si devuelve verdadero, el trabajo continúa con el siguiente bloque.
Renombrar LastTimeTemp
Este bloque de comandos copia el contenido de LastTimeTemp.txt a LastTime.txt. Esto registra la marca de tiempo actual capturada previamente en el archivo que se usará para la próxima ejecución del trabajo.
Convertir.scl
Este bloque de transformación toma current.txt y lo convierte a changes.csv . La conversión es del tipo de archivo delimitado predeterminado a CSV. El uso del tipo de proceso CSV en CoSort antepone una fila de encabezado al archivo de salida usando los nombres de campo. Este es el bloque de tareas donde podría aplicar otras manipulaciones (como enmascaramiento de datos) a los datos si así lo decido.
Archivos de espera
Este bloque de espera detiene el archivo por lotes durante 3 segundos y luego verifica la existencia de changes.csv archivo antes de continuar.
Importación de Mongo
Este bloque de comando ejecuta el comando mongoimport usando los parámetros especificados en la vista de propiedades como se muestra a continuación.
Los parámetros indican que la base de datos MongoDB llamada fnx debe cargarse con el contenido del archivo changes.csv que es del tipo csv y contiene un encabezado que define los campos.
Tenga en cuenta que Voracity admite otros métodos para mover y manipular datos de MongoDB. Vea este ejemplo de uso de los controladores ODBC de Progress para el enmascaramiento de datos mediante las funciones integradas de "FieldShield". Voracity también puede procesar datos BSON directamente a través de API a través de /PROCESS=MongoDB support en CoSort v10, ahora también.
Error al cargar
Este bloque de decisión comprueba la variable ERRORLEVEL para asegurarse de que devolvió 0 (o éxito) después de importar a MongoDB. Si no lo hizo, el trabajo continúa con Delete-Changes y SALIR bloques donde finaliza el trabajo. Si devuelve verdadero, el trabajo continúa con el siguiente bloque.
Truncar actual
Este bloque de comando trunca el archivo current.txt . Esto es para borrar los registros que se cargaron en MongoDB. Si la importación falló y el bloque anterior salió del trabajo, estos registros modificados se agregarán en el siguiente paso. Luego, a medida que se repetía el trabajo, se cargaban en MongoDB con el siguiente grupo de registros modificados.
Eliminar cambios
Este bloque de comando elimina changes.csv para que el siguiente pase se inicie con un archivo recién creado para el pase.
Archivo por lotes
El archivo por lotes y los scripts de transformación se crean cuando se exporta el diagrama de flujo. 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 en intervalos seleccionados.
Comuníquese con [email protected] o con su representante de IRI para obtener más información o ayuda con su caso de uso
- Este enfoque difiere de las soluciones de captura de datos de cambio basadas en registros, que suelen tener cuellos de botella en el rendimiento y están limitadas a bases de datos específicas, y no permiten la transformación de datos simultánea, el enmascaramiento de datos de PII, la limpieza e informes.
