| UI Expand |
|---|
| title | OutBox Pattern | Transactional Oubox Pattern |
|---|
| Este patrón implica escribir los eventos en una tabla de "outbox" dentro de la misma transacción que la operación de negocio. El negocio (aplicación, servicio, microservicio) El negocio (aplicación, servicio, microservicio), "SYSTEM A" que hace la persistencia ( nueva inserción u , actualización o borrado) y después de confirmar la persistencia se notifica un evento de sincronización a un bus externo, dicho evento se consume por un sistema tercero "System B" y se en la misma transacción persiste el cambio en el sistema destino. Dándo como resultado final que ambos sistemas quedan sincronizados en base a la gestión del evento. |  Image RemovedDiseño para un sistema legacy
|  Image RemovedDiseño para un sistema nuevo
| la BBDD. Otro servicio del mismo negocio debe leer esa tabla de eventos (técnica polling cada n ms) e ir generando eventos de sincronización a un bus y este se consume y se persiste el cambio en el sistema destino.
 Image AddedTransactional OutBox Pattern
Evaluación de pros/contras | No tiene impacto en la BBDD del sistema Origen | Contras - La emisión de eventos y su persistencia indicada en el paso 2, conlleva la implementación de mecanismos de resiliencia adicionales de cara a garantizar la entrega.
| (General) El sistema A, Requiere cambios en el código para poder emitir los eventos de negocio a remitir al bus de eventos externo: - Si la tecnología es muy obsoleta (delphi, jdk antiguos, .net antiguos) puede que no exista cliente de conexíon con el event buffer.
| En los legacy puede no haber canal para implementar los cambios | (Configura ) Al tener que convivir con la api del legacy (y hacer los cambios desde dos orígenes de datos ) se pueden generar conflictos en la persistencia debido a la concurrencia | | (Configura ) Al tener que convivir con al api del legacy, Si la tecnología es muy obsoleta (delphi, jdk antiguos, .net antiguos) puede que no exista cliente de conexíon con el event buffer | | para cualquier tipo de proyecto 👍 |
|---|
| Asegura la creación del evento de sincronización. Esto es debido a la transacción local que se realiza al persistir el cambio en la tabla y su posterior persistencia en la tabla de eventos a publicar. | No hay una comunicación directa desde el sistema origen con el event buffer. Esto aporta varias ventajas: - Se puede contar con un microservicio reutilizable e independiente del sistema origen.
|
|
| Columna |
|---|
| | Pros para proyectos ya existentes 👍 |
|---|
En relación a la comunicación del sistema origen con el event buffer, se aportan varias ventajas adicionales a los proyectos existentes: - No es necesario modificar el código del proyecto existente para tener esta funcionalidad,
|
|
| Columna |
|---|
| | Contras para cualquier tipo de proyecto 👎 |
|---|
Implica cambios en la base de datos, se debe crear una tabla para persistencia de los eventos a generar. | Hay riesgo de impacto en la performance de la bbdd del sistema, al realizar consultas cada intervalo de tiempo x. |
|
| Columna |
|---|
| | Contras para proyectos ya existentes 👎 |
|---|
Implica cambios en el código para persistir en la tabla de eventos |
|
|
Evaluación de requisitos /NABlue| Nuevo ADR | Aplicación - de mecanismos de fault-tolerance en cada uno
|
de los puntos de comunicación (4)Dificultad para mantener la resiliencia en el paso 2 ya que al no persistirse en ningún sitio la necesidad de sincronización cualquier caída del servidor (apagado, bloqueo, degradación, perdida del POD) podría implicar que la sincronización no se lleve a cabo y cuando se reestablezca el sistema perdida de la trazabilidad de los cambios a sincronizar- cada paso
- ✔️ Al hacer uso de una tabla auxiliar y un event buffer puedes tener la garantía de entrega ante caídas.
- ✔️ Si el Sistema Origen se cae, al estar persistida la necesidad de sincronización, se puede volver a retomar desde la última sincronización correcta.
- ✔️ El event buffer al tener persistencia de mensajes y posibilidad de ack de entrega puedes garantizar simplemente la recepción o la lectura del mismo por algún consumidor según se defina la necesidad de confirmación de entrega.
| | Transaccional | |
RedNOK | En ningún caso se garantiza la transaccionalidad de la sincronización completa. | ✔️ Se establecen los siguientes tramos transaccionales: |
NO - SI - Entrega en el Event Buffer(Producer paso 3). Dependiente del tipo de ACK que se establezca en el Producer SI - Consumo y persistencia del cambio (Paso 5 y 6)No invasivo - Código | | Estado |
|---|
colour | y persistencia del evento de sincronización (Pasos 1 y 2). Si falla la entrega en el buffer habría que realizar una nueva operación de modificación en la bbdd (paso 1) ya que este paso ya ha sido comiteado, por lo que podría aplicarse y tener efectos en la aplicación .- : La persistencia tanto en la tabla origen como en la tabla de evento, se puede realizar como transacción local.
- Generación de Eventos: El event buffer tiene diferente estrategias en la garantía de entrega.
| | Idemponente | | - ✔️ Hay que asegurarse de que los eventos en la outbox se marquen como procesados.
- ⚠️ Necesita lógica adicional para asegurar idempotencia
| | No invasivo - Código | | ❌ Hay que hacer desarrollos para la implementación de la emisión de los eventos. | | No invasivo - BBDD | |
que hacer desarrollos para la implementación de la emisión de los eventos| No invasivo - BBDD | | La bbdd del Sistema A no tendría que sufrir ninguna alteración | - que crear una nueva tabla que persista los eventos que después un servicio leerá para publicar.
- ⚠️ Definir estrategia de lectura, en batch o individual.
- ⚠️ Definir el tiempo de polling (ms).
| | Compatible con las tecnologías actuales |
(general)RedNOK | Nada que reseñar en cuanto a la BBDD, compatible con la tecnología que estén usando actualmente en el proyecto | ✔️ Al no añadir ninguna tecnología extra al (la conexión con el event buffer es a través de un nuevo microservicio) no se aprecian incompatibilidades. |
Al requerir cambios en el código y que el Sistema A conecte directamente con el event buffer en proyectos legacy con tecnologías muy antiguas puede que no exista cliente de conexíon con el event buffer
| UI Expand |
|---|
| title | Transactional Oubox Pattern |
|---|
| El negocio (aplicación, servicio, microservicio) que hace la persistencia ( nueva inserción u actualización) y después en la misma transacción persiste el cambio en la BBDD. Otro servicio del mismo negocio debe leer esa tabla de eventos (técnica polling cada n ms) e ir generando eventos de sincronización a un bus y este se consume y se persiste el cambio en el sistema destino. Algunos Ejemplos  Image Removed
Evaluación de pros/contras Pros | Garantiza la creación del evento de sincronización gracias a su transacción con la bbdd desde el sistema origen | | Al no comunicarse el código del caso de uso directamente con él event buffer, en caso de aplicaciones legacy, siempre se puede tener un microservicio (el cual podría generalizarse para ser reutilizable) actualizado con una tecnología que disponga de un cliente soportado para conectarse con el event buffer. | Contras Requiere de un Servicio (Microservicio) para realizar la sincronización. Se puede mitigar con generalidades que hagan que esta contra se pueda reducir o desaparecer. | Implica cambios de código como en la BBDD | Implica cambios en la BBDD | En los legacy puede no haber canal para realizar los cambios. | Puede tener un impacto en la performance de la bbdd del sistema. No debería ser mucho el impacto, pero es más que no tener nada nuevo en la BBDD. | El uso de triggers para la generación directa de eventos, dependiendo del escenario, puede implicara que la cantidad de triggers aumenten linealmente con la cantidad de tablas bajo consideración. | Si el tamaño ha aumentado puede suponer un aumento en la complejidad si se necesita hacer un cambio en el modelo de datos base, en el de eventos de sincronización o ante una posible refactorización. | El tamaño puede tener un impacto en el rendimiento cada vez que se produce la modificación (insert, update, delete) en cada registro. | (Configura ) Al tener que convivir con la api del legacy (y hacer los cambios desde dos orígenes de datos ) se pueden generar conflictos en la persistencia en la tabla de configuración debido a la concurrencia | (Configura ) Al tener que convivir con la api del legacy (y hacer los cambios desde dos orígenes de datos ) se pueden generar conflictos en la persistencia en la tabla de eventos de sincronización debido a la concurrencia | Evaluación de requisitos | Requisito | OK/NOK | Detalle |
|---|
| Resiliente | | Aplicación de mecanismos de fault-tolerance en los 6 puntos. Al hacer uso de una tabla auxiliar y un event buffer puedes tener la garantía de entrega ante caídas. Si el Sistema A se cae, al estar persistida la necesidad de sincronización, se puede volver a retomar desde la última sincronización correcta. El event buffer (Kafka) al tener persistencia de mensajes y posibilidad de ack de entrega puedes garantizar simplemente la recepción o la lectura del mismo por algún consumidor según se defina la necesidad de confirmación de entrega. | | Transaccional | | Se establecen los siguientes tramos transaccionales: - Persistencia del cambio y persistencia del evento de sincronización (Pasos 1 y 2)
| | No invasivo - Código | | Hay que hacer desarrollos para la implementación de la emisión de los eventos. | | No invasivo - BBDD | | Hay que crear una nueva tabla que persista los eventos que después un servicio leerá para publicar. Definir estrategia de lectura, en batch o individual. Definir el tiempo de polling (ms). | | Compatible con las tecnologías actuales | | Nada que reseñar en cuanto a la BBDD, compatible con la tecnología que estén usando actualmente en el proyecto. | | UI Expand |
|---|
|  Image Removed
Evaluación de pros/contras Pros | Garantiza la creación del evento de sincronización gracias a al trigger que realiza la bbdd que garantiza su ejecución. | | Al no comunicarse el código del caso de uso directamente con él event buffer, en caso de aplicaciones legacy, siempre se puede tener un microservicio (el cual podría generalizarse para ser reutilizable) actualizado con una tecnología que disponga de un cliente soportado para conectarse con el event buffer. | | No se tiene que realizara ningún cambio en el código del legacy. | Contras Requiere de un Servicio (Microservicio) para realizar la sincronización. Se puede mitigar con generalidades que hagan que esta contra se pueda reducir o desaparecer. | Implica cambios de código como en la BBDD. | Puede tener un impacto en la performance de la bbdd del sistema. No debería ser mucho el impacto, pero es más que no tener nada nuevo en la BBDD. | La generación de los eventos de sincronización a partir de relaciones complejas, puede ser costoso a nivel de performance y de construcción. | (Configura ) Al tener que convivir con la api del legacy (y hacer los cambios desde dos orígenes de datos ) se pueden generar conflictos en la persistencia en la tabla de configuración debido a la concurrencia. | Evaluación de requisitos | Requisito | OK/NOK | Detalle |
|---|
| Resiliente | | Aplicación de mecanismos de fault-tolerance en los 6 puntos Al hacer uso de una tabla auxiliar y un event buffer puedes tener la garantía de entrega ante caídas. Si el Sistema A se cae, al estar persistida la necesidad de sincronización, se puede volver a retomar desde la última sincronización correcta. El event buffer (Kafka) al tener persistencia de mensajes y posibilidad de ack de entrega puedes garantizar simplemente la recepción o la lectura del mismo por algún consumidor según se defina la necesidad de confirmación de entrega | | Transaccional | | Se establecen los siguientes tramos transaccionales: - Paso 1 y Paso 2 no necesitan transacción ya que es la propia BBDD la que garantiza con el trigger la creación del evento de sincronización en la tabla de eventos
| | No invasivo - Código | | No requiere cambio de código | | No invasivo - BBDD | | Requiere la creación de una tabla para persistir los eventos de sincronización Requiere la creación de un trigger | | Compatible con las tecnologías actuales | | Nada que reseñar en cuanto a la BBDD, compatible con la tecnología que estén usando actualmente en el proyecto. | | Los triggers son bloques de código que se ejecutan automáticamente en respuesta a ciertos eventos en la base de datos, como inserciones, actualizaciones o eliminaciones de registros. En términos de resiliencia y recuperación, Oracle ofrece varios mecanismos para manejar errores y garantizar la integridad de las transacciones en las que participan los triggers. A continuación, se detallan algunos aspectos clave: 1. Atomicidad y Consistencia - Atomicidad: Los triggers en Oracle se ejecutan como parte de la transacción que los activa. Esto significa que si un trigger falla, la transacción completa se revierte, garantizando que los cambios no se apliquen parcialmente.
- Consistencia: Los triggers deben mantener la consistencia de los datos. Si una operación del trigger genera un error, la transacción completa se revierte para mantener la integridad de la base de datos.
2. Mecanismos de Manejo de Errores - Excepciones en PL/SQL: Dentro de un trigger, se pueden manejar errores utilizando bloques
EXCEPTION. Esto permite capturar errores específicos y tomar acciones adecuadas, como registrar el error en una tabla de auditoría, enviar notificaciones, o realizar limpiezas necesarias. - RAISE_APPLICATION_ERROR: Permite generar errores personalizados dentro de un trigger, lo que puede ser útil para manejar situaciones específicas y proporcionar mensajes de error más claros.
3. Logs y Auditorías - Registros y Auditorías: Los triggers pueden incluir lógica para registrar eventos y errores en tablas de auditoría. Esto proporciona un historial de eventos y errores que puede ser analizado posteriormente.
4. Garantías de Ejecución - Control de Estados: Oracle garantiza que un trigger se ejecuta en el estado adecuado de la transacción. Por ejemplo, los triggers
BEFORE se ejecutan antes de que se realice la operación DML, y los triggers AFTER se ejecutan después de la operación DML pero antes de que se confirme la transacción.
5. Control de Fallos - Reversión Automática: Si ocurre un error no manejado dentro de un trigger, la transacción entera que activó el trigger se revierte automáticamente. Esto incluye todas las operaciones DML que hayan ocurrido dentro de la transacción.
6. Eventos de Recuperación - Eventos de Reintento: En algunos escenarios, es posible implementar lógica para reintentar operaciones fallidas. Aunque no es un mecanismo nativo de los triggers, se puede implementar mediante programación adicional, como paquetes PL/SQL que manejen la lógica de reintento.
 Image AddedTransactional Outbox Pattern by Database trigger
Evaluación de pros/contras
| Sección |
|---|
| | Columna |
|---|
| | Pros para cualquier tipo de proyecto 👍 |
|---|
| Asegura la creación del evento gracias a su atomicidad y consistencia | No hay una comunicación directa desde el sistema origen con el event buffer. Esto aporta varias ventajas: - Se puede contar con un microservicio reutilizable e independiente del sistema origen.
|
|
| Columna |
|---|
| | Pros para proyectos ya existentes 👍 |
|---|
| No requiere cambio en el código del proyecto para la generación de los eventos. | En relación a la comunicación del sistema origen con el event buffer, se aportan varias ventajas adicionales a los proyectos existentes: - No es necesario modificar el código del proyecto existente para tener esta funcionalidad.
|
|
| Columna |
|---|
| | Contras para cualquier tipo de proyecto 👎 |
|---|
Implica cambios en la base de datos, se debe crear una tabla para persistencia de los eventos a generar. | Hay riesgo de impacto en la performance de la bbdd del sistema, al realizar consultas cada intervalo de tiempo x. |
|
|
Evaluación de requisitos | Requisito | OK/NOK | Detalle |
|---|
| Resiliente | | - ⚠️ Hay que implementar de mecanismos de fault-tolerance en cada uno cada paso
- ✔️ Al hacer uso de una tabla auxiliar y un event buffer puedes tener la garantía de entrega ante caídas.
- ✔️ Si el Sistema Origen se cae, al estar persistida la necesidad de sincronización, se puede volver a retomar desde la última sincronización correcta.
- ✔️ El event buffer al tener persistencia de mensajes y posibilidad de ack de entrega puedes garantizar simplemente la recepción o la lectura del mismo por algún consumidor según se defina la necesidad de confirmación de entrega.
| | Transaccional | | ✔️Se establecen los siguientes tramos transaccionales: - Persistencia del cambio: La persistencia tanto en la tabla de origen como en la tabla de evento, se puede realizar como transacción local.
- Generación de Eventos: El event buffer tiene diferente estrategias en la garantía de entrega.
| | Idemponente | | - ✔️ Hay que asegurarse de que los eventos en la outbox se marquen como procesados.
- ⚠️ Necesita lógica adicional para asegurar idempotencia
| | No invasivo - Código | | ✔️ No requiere cambio de código | | No invasivo - BBDD | | - ⚠️ Requiere la creación de una tabla para persistir los eventos de sincronización
- ⚠️ Requiere la creación de un trigger
| | Compatible con las tecnologías actuales | | ✔️ Al no añadir ninguna tecnología extra al (la conexión con el event buffer es a través de un nuevo microservicio) no se aprecian incompatibilidades. |
|
| UI Expand |
|---|
| La captura de datos de cambios (CDC) es un patrón de datos que permite producir eventos a partir de los cambios en un almacén de datos. CDC proporciona un camino para obtener las ventajas de las arquitecturas basadas en eventos reduciendo el esfuerzo de extraer bases de datos de aplicaciones. La implementación de CDC dependerá de su base de datos, sus casos de uso y el conector que seleccione.: - JDBC: sondean continuamente la base de datos en busca de cambios en las tablas de origen especificadas.
- Sondear una tabla mutable: puede no ser óptimo, ya que inevitablemente perderá actualizaciones que se completen entre los intervalos de sondeo.
- Sondear una tabla inmutable.
- La primera es simplemente hacer que la tabla sea inmutable y cambiar el código de la aplicación para manejar esta vista de los datos.
- La segunda opción es adjuntar un disparador a la tabla mutable primaria. Este activador añade una segunda entrada a una tabla de auditoría inmutable. Luego, el conector puede sondear esta tabla de auditoría para detectar cambios sin que falten registros. En este caso, para ORACLE la opción es el GOLDEN-GATE que no está dentro de la licencia disponible para el SAS
 Image AddedTransactional Outbox Pattern by Database CDC
Evaluación de pros/contras | Sección |
|---|
| | Columna |
|---|
| | Pros para cualquier tipo de proyecto 👍 |
|---|
Garantiza la creación del evento de sincronización a través de los mecanismos de Change Data Capture | No hay una comunicación directa desde el sistema origen con el event buffer, si no que se realiza a través del CDC | No tienes que desarrollar ningún microservicio para la publicación de eventos. La propia herramienta de CDC lo hace. | Minimizas el impacto en BBDD | Permite extracciones de información mas complejas, abarcando varias tablas por ejemplo. | Se externaliza la gestión de algunos aspectos de funcionamiento, a destacar: |
|
| Columna |
|---|
| | Pros para proyectos ya existentes 👍 |
|---|
| No requiere cambio en el código del proyecto para la generación de los eventos. |
|
| Columna |
|---|
| | Contras para cualquier tipo de proyecto 👎 |
|---|
En caso de que la base de datos de sincronización sea Oracle implica: |
|
|
| | UI Expand |
|---|
| La captura de datos de cambios (CDC) es un patrón de datos que permite producir eventos a partir de los cambios en un almacén de datos. CDC proporciona un camino para obtener las ventajas de las arquitecturas basadas en eventos reduciendo el esfuerzo de extraer bases de datos de aplicaciones. La implementación de CDC dependerá de su base de datos, sus casos de uso y el conector que seleccione.: - JDBC: sondean continuamente la base de datos en busca de cambios en las tablas de origen especificadas.
- Sondear una tabla mutable: puede no ser óptimo, ya que inevitablemente perderá actualizaciones que se completen entre los intervalos de sondeo.
- Sondear una tabla inmutable.
- La primera es simplemente hacer que la tabla sea inmutable y cambiar el código de la aplicación para manejar esta vista de los datos.
- La segunda opción es adjuntar un disparador a la tabla mutable primaria. Este activador añade una segunda entrada a una tabla de auditoría inmutable. Luego, el conector puede sondear esta tabla de auditoría para detectar cambios sin que falten registros. En este caso, para ORACLE la opción es el GOLDEN-GATE que no está dentro de la licencia disponible para el SAS
 Image Removed
Evaluación de pros/contras Pros | | Garantiza la creación del evento de sincronización a través de los mecanismos de Change Data Capture | | Permite extracciones de información mas complejas, abarcando varias tablas por ejemplo. | | Se externaliza la gestión de la sincronización por lo que no hace falta implementar un nuevo microservicio | Se externaliza la gestión de algunos aspectos de funcionamiento, a destacar: | Contras Requiere realizar configuraciones en la BBDD para activar la captura de los dato. | La activación del CDC de forma nativa en la BBDD (ORACLE GOLDEN GATE y CDC ORACLE CONFIG) está fuera de soporte por lo que se tiene que hacer uso de otro sistema externo (Debizum) | La solución al no - ser nativa, y sobre una tecnología que no es opensource (ORACLE), aumenta el riesgo de incompatibilidades
|
|
|
Posible impacto en la performance de la bbdd | | Requisito | OK/NOK | Detalle |
|---|
| Resiliente | | Aplicación - ⚠️ Hay que implementar de mecanismos de fault-tolerance en
los 6 puntos- cada uno cada paso
- ⚠️ Depende de la robustez de la herramienta de CDC
- ✔️ Altamente resiliente, ya que captura los cambios directamente del log de transacciones
- ✔️ Si el Sistema Origen se cae, al estar persistida la necesidad de sincronización,
Al hacer uso de una tabla auxiliar y un event buffer puedes tener la garantía de entrega ante caídas. Si el Sistema A se cae, al estar persistida la necesidad de sincronización, - se puede volver a retomar desde la última sincronización correcta.
- ✔️ El event buffer
(Kafka) - al tener persistencia de mensajes y posibilidad de ack de entrega puedes garantizar simplemente la recepción o la lectura del mismo por algún consumidor según se defina la necesidad de confirmación de entrega.
| | Transaccional | | ✔️ Se establecen los siguientes tramos transaccionales: - Paso 1 y Paso 2 no necesitan transacción ya que es la propia BBDD la que garantiza con el trigger la creación del evento de sincronización en la tabla de eventos
- Persistencia del cambio:
- ✔️ Captura cambios de manera transaccional porque lee directamente del log de transacciones.
- ⚠️ Puede tener un ligero retraso en la captura de eventos
- Generación de Eventos: El event buffer tiene diferente estrategias en la garantía de entrega.
| | Idemponente | Idempotente | | Estado |
|---|
| | colour | Blue |
|---|
title | Nuevo ADR| Estado |
|---|
| colour | YellowGreen |
|---|
| title | No APLICAOK |
|---|
|
| Dependiente Partiendo de la implementación. Se deberán transmitir claves del evento y estas ser registradas en algún elemento de la transmisión para descartar aquellos mensajes duplicados. Dependiente de la implementación | | Desacoplamiento entre sistemas | | Para mantener el desacoplamiento es necesario que los eventos de sincronización sean agnósticos al sistema destino (Sistema B). Como la comunicación con los sistemas es a través de un event buffer, el sistema origen no conoce a los sistemas destino por lo que queda desacoplado. | | No invasivo - Código | | No requiere cambios en el código | | No invasivo - BBDD | | Hay que aplicar los cambios en la BBDD que se indican en el manual de instalación. | base del uso de DeBizum, este garantiza la idempotencia a través de los siguientes mecanismos: - ✔️ Uso de identificadores únicos de mensajes (UUID).
- ✔️ Registro de mensajes procesados para evitar duplicados.
- ✔️ Confirmaciones de recepción (ACKs) para asegurar la entrega y procesamiento.
- ✔️ Persistencia de mensajes para asegurar la recuperación en caso de fallos.
| | No invasivo - Código | | - ✔️ No requiere cambios en el código de la aplicación
- ⚠️ Necesita configurar y mantener la herramienta de CDC.
| | No invasivo - BBDD | | Estado |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | A medias |
|---|
|
| - ✔️ No requiere cambios en la estructura de la base de datos.
- ⚠️ Requiere la creación de un trigger
| | Compatible con las tecnologías actuales | | Estado |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | A medias |
|---|
|
| ⚠️ Al ser Oracle el motor de BBDD mayoritaria en el SAS se encuentran los siguientes problemas: - ✔️ Se necesita el uso de debizum
- ✔️ Es compatible con single instance y rac
- Limitaciones de compatibilidad con OracleDecisión tomada, a falta de confirmación y aclaraciones al equipo, así como a falta de la redacción de las HU's adicionales en base a las necesidades indicadas en la sección de Consecuencias.
- ❌ Logminer: Deprecated
- ❌ XStreams: unsoported
- ⚠️
| Compatible con las tecnologías actuales | | https://debezium.io/documentation/reference/stable/connectors/oracle.htmlDebizum Oracle Installation comatibility → compatible con single instance y racOracle 19 Deprecated o Desupporter → Logminer: DeprecatedXStreams: unsoported- OpenLogReplicator: Según Debezium : "The OpenLogReplicator ingestion adapter is currently in incubating state, i.e. exact semantics, configuration options etc. may change in future revisions, based on the feedback we receive."
- Ficha técnica Debezium-OpenLogReplicator:
- Database: 12c, 19c, 21c
- Driver: 12.2.x, 19.x, 21.x
- OpenLogReplicator: 1.3.0
- Supported versions: 11.2, 12.1, 12.2, 18c, 19c, 21c.
- Supported editions: XE, SE, SE2, PE, EE
- Database must be in single instance mode (non RAC)
- The database must be working in ARCHIVELOG mode and having enabled MINIMAL SUPPLEMENTAL LOGGING.
- Supported platforms: Linux64, Solaris x64, Solaris Sparc
- Supported storage: file system (ext4, btrfs, zfs, xfs, sshfs)
- Supported database character set, es probable que que esté soportada (estándar UTF está incluido)
|
El impacto sobre los siguientes requisitos es el mismo para todas las alternativas Resumen Comparativo de aporte de valor| Criterio | Transactional Outbox | Outbox by Trigger | Outbox by CDC |
|---|
| Resiliente | Alto | Alto | Alto | | Transaccional | Alto | Alto | Alto | | Idempotente | Medio | Medio | Alto | | Minimizar cambio en el código | Medio | Alto | Alto | | Minimizar cambio en la estructura | Medio | Medio | Alto | | Obsolescencia de la sincronía | Alto | Alto | Alto | | Desacoplamiento entre sistemas | Alto | Alto | Alto | | Consistencia Eventual | Alto | Alto | Alto | | Compatible con tecnologías actuales | Alto | Medio | Alto |
Conclusión- Transactional Outbox Pattern es robusto y flexible, pero puede requerir cambios moderados en el código y la estructura de la base de datos.
- Transactional Outbox Pattern by Database Trigger minimiza cambios en el código pero puede complicar la administración y depuración debido a la lógica de los triggers.
- Transactional Outbox Pattern by CDC ofrece alta resiliencia y minimiza cambios tanto en el código como en la base de datos, pero requiere la gestión de una herramienta de CDC.
El impacto sobre los siguientes requisitos es el mismo para todas las alternativas | Requisito | OK/NOK | Detalle |
|---|
| Requisito | OK/NOK | Detalle |
|---|
| Resiliente | | Definir un ADR con los mecanismo de resiliencia para los puntos críticos: - Persistencia del cambio
- Generación del evento de sincronización
- Propagación del evento de sincronización
- Persistencia del evento de sincronización
| Transaccional | En ninguna de las alternativas se puede garantizar la transaccionalidad de la sincronización completa. Se establecen los siguientes tramos transaccionales para cualquiera de las alternativas, dentro de la fase de sincronización - Entrega en el Event Buffer(Producer). Dependiente del tipo de ACK que se establezca en el Producer
- Consumo y persistencia del cambio
| | Idempotente | | Estado |
|---|
| colour | Yellow |
|---|
| title | No APLICA |
|---|
|
| Se necesita un ADR para determinar la estrategia de idempotencia (duplicación de mensajes) En todas las alternativas analizadas la estrategia de idempotencia es dependiente de la implementación de la fase de sincronización Se deberán transmitir claves del evento y estas ser registradas en algún elemento de la transmisión para descartar aquellos mensajes duplicados. | | Desacoplamiento entre sistemas | | En todas las alternativas se contempla que la fase de sincronización sea a través de un event buffer por lo que el desacoplamiento con el sistema destino está garantizado siempre y cuando la definición de los eventos de sincronización sean agnósticos al sistema destino (Sistema B)Destino. | | Obsolescencia del Dato | | Estado |
|---|
| |
|---|
| colour | Yellow |
|---|
| title | No APLICA |
|---|
|
| No hay ninguna solución que garantice la correcta gestión de la obsolescencia del dato. Posibles mitigaciones: - Uso y transmisión del timestamp
- En caso de ser inferior a la última sincronización confirmada se descartaría el evento.
- Garantía del orden
- Esto puede añadir una complejidad no necesaria
| | Compatible con las tecnologías actuales | | Necesita de un ADR. En todas las alternativas se contempla que la fase de sincronización sea a través de un event buffer por lo que la estrategia que se determine es compatible con cualquiera de las alternativas. Posible estrategia, generar un timestamp de la operación por el Sistema A y transmitir dicho timestamp hasta la pieza encargada de valorar la fecha del dato a sincronizar. En caso de ser inferior a la última sincronización confirmada se descartaría el evento. | | Compatible con la consistencia eventual | | Estado |
|---|
| colour | Yellow |
|---|
| title | No APLICA |
|---|
|
| Necesita de un ADR que haga el análisis de impacto y en caso de determinar que hay impacto determinar la estrategia a seguir por el Sistema A (el origen que en este caso es Configura) para que su reacción sea previsible Esto es algo que no depende de la estrategia de sincronización si no que es inherente al hecho de necesitar sincronización. Eso provocará que el Sistema A (Origen) y el Sistema b (Destino) durante un periodo de tiempo x no tengan la misma información. Esto implica que dependerá del análisis que haga el Sistema A ( en este caso CONFIGURA) de como le impacta dicha consistencia eventual y que contramedidas implementará para que esto no ocurra. | Compatible con las tecnologías actuales | En todas las alternativas so contempla que la fase de sincronización sea a través de un event buffer por lo que la compatibilidad de esta pieza aplica a todas por igual: | compatibilidad de esta pieza aplica a todas por igual: |
|