Diseño para Resiliencia

Diseño para Reinicio

Algunos procesos de integración pueden ser muy complejos y tener dependencias con otros procesos. Pueden pasar a una cantidad de etapas antes de que los datos se carguen definitivamente en el sistema de destino final. Para ayudar con la capacidad de reinicio a agregar una columna adicional a las tablas de asignación de etapas para realizar un seguimiento y el identificador de la carga actual (load_id o load_date, o cualquier elemento que identifique esta carga de forma única). Esto permitirá un mejor rastreo y facilitará el diseño de los procedimientos de limpieza.

¿Qué significa Oracle Data Integrator?

Utilice variables para realizar un seguimiento del identificador del proceso que se está cargando y, si es posible, agréguelos a las etapas de datos intermedias (columnas adicionales en las tablas temporales).
Utilice estas variables para definir un nombre de sesión diferente (SESS_NAME) para cada ejecución de caso. Esto permitirá a los operadores identificar de forma inmediata los procesos que no reconocen exactamente dónde debe aparecer. Consulte Uso de Nombres Únicos o Dinámicos para Sesiones de Caso.
Tomar el ejemplo anterior en el que se utiliza el mismo proceso para cargar cientos de archivos, es más práctico tener un trabajo con el mismo nombre que el archivo que se está procesando que tiene el mismo nombre de trabajo genérico para todos los archivos.

Diseñar para limitar impactos de Interrupción

La ejecución de extracciones masivas en momentos predefinidos tiene un gran impacto en toda la infraestructura.

Por ejemplo:

El sistema de origen se ve afectado debido a que debe atender la solicitud.
La red se ve afectada porque el ancho de banda es inundado con el servicio de la solicitud.
Los trabajos de integración general tardan más tiempo en ejecutarse debido al volumen más alto de datos que se tiene que procesar.
Una pequeña incidencia o interrupción de su red en el momento de la integración tiene un impacto importante en la tarea de integración.

No es necesario que los trabajos de integración sean por lotes o en tiempo real. A menudo, pueden ser ambas. Si la carga final debe ser una operación por lotes (porque los datos se consolidan o se agregan por ejemplo), la extracción y algunos procesos de integración previa se pueden realizar de forma más en tiempo real. Esto reduce la carga en la infraestructura general y limita el impacto al intentar acceder al sistema de origen en el momento de la integración. Si los datos se han extraído y preparado de forma fluida, no necesita acceder al sistema de origen cuando sea hora para la integración final.

Oracle Data Integrator proporciona una serie de herramientas que se pueden utilizar en la construcción de paquetes para detectar que hay disponibles nuevos datos. Consulte Usar herramientas basadas en eventos para una lista.

Para la integración con una replicación en tiempo real, Oracle Data Integrator puede crear una infraestructura que permita el consumo de cambios, aprovechando las API mencionadas anteriormente.

Elegir entre inserción y fusión de datos

Hay cotizaciones entre un enfoque INSERT y MERGE para la carga de datos. Más allá de la estrategia de integración, puede que desee considerar lo que sucede cuando una carga falla parcialmente.

Dependiendo de cómo esté cargando los datos en el sistema de destino, diferenciando lo que se ha cargado correctamente frente a lo que ha fallado o que la identificación de los elementos de una carga parcial puede ser bastante compleja. Aunque desde una perspectiva de diseño, todo lo que va a realizar es agregar datos al sistema de destino, puede ser útil desde una perspectiva de capacidad de recuperación para considerar las ventajas de fusionar los datos entrantes con los datos que ya están en el sistema de destino.

Si elige este enfoque, deseará comprobar dos veces el impacto que esta estrategia tiene sobre el rendimiento de las cargas. Sin embargo, recuerde que una carga INSERT totalmente optimizada que no es más rápida que una fusión menos eficaz que se realice correctamente.

Desde una perspectiva de Oracle Data Integrator, el cambio de una estrategia INSERT a una estrategia MERGE es una operación muy simple: Sólo tiene que cambiar la estrategia de integración y seleccionar el módulo de conocimiento adecuado. De esta forma, el cambio de los módulos de conocimiento para un gran número de asignaciones puede ser una tarea de publicación. Puede automatizar tareas de este tipo mediante el SDK de Oracle Data Integrator.

Diseño para limitar las interrupciones planificadas

Normalmente, se necesitan interrupciones planificadas para la aplicación de parches y actualizaciones.

En un entorno de nube en el que las actualizaciones y los parches son más perfectas y desde la perspectiva del usuario final, lo último que deseamos está forzado a una interrupción porque aplicamos parches al código de los procesos de integración. Esto significa que la aplicación de parches debe formar parte de la estrategia de desarrollo hacia adelante para garantizar que las interrupciones se mantienen como mínimo.

La unidad de ejecución para Oracle Data Integrator es un caso. Cuando se genera un caso, se asocia a un número de versión (a partir de 001). Se pueden volver a generar los casos (para sobrescribir la versión actual) o se puede generar una nueva versión (002, 003, etc.).

Al llamar a un caso, Oracle recomienda que siempre especifique el número de versión-1. Esto tendrá dos ventajas:

Oracle Data Integrator utilizará siempre la última versión del caso. No tendrá que cambiar la forma en que llama a estos casos cuando genere nuevas versiones;
Una vez creada una nueva versión del escenario, ésta es la versión que ejecuta Oracle Data Integrator. Configurar Timeout de Caché de Diseño de Agente describe cómo controlar los posibles retrasos. No es necesario que pare y reinicie Oracle Data Integrator, o cualquier herramienta de orquestación externa que esté utilizando, para que Oracle Data Integrator utilice la última versión de los casos de integración.

Nota: Este enfoque sólo es posible si no tiene bucles infinitos en Oracle Data Integrator. Los bucles infinitos nunca se recomiendan en Oracle Data Integrator (en realidad califican como un antipatrón):

Clon los logs de Oracle Data Integrator: Las depuraciones de logs no afectarán a los trabajos en ejecución. Siempre se está ejecutando un bucle infinito, ya que los logs correspondientes no se pueden depurar.
Evita la aplicación de parches en directo de casos: para que ODI seleccione la nueva versión de un escenario, debe tener la oportunidad de iniciar dicho escenario. Un bucle infinito nunca finaliza… y, como tal, nunca tiene una posibilidad de reinicio.
En lugar de tener un bucle infinito, puede finalizar el caso llamando a ese mismo escenario de forma asíncrona: el último paso del caso antes de terminar es iniciar una nueva copia de sí mismo en una nueva sesión.