Módulo 5 — Connect CDC

Qué es

Precisely Connect es la solución de integración de datos de Precisely, con capacidad de Change Data Capture (CDC) para capturar cambios de fuentes complejas en tiempo real y entregarlos a destinos heterogéneos. La propuesta de valor central es "diseñar una vez, desplegar en cualquier lugar": los flujos se diseñan visualmente una sola vez y pueden ejecutarse tanto on-premises como en cloud sin reescribir los jobs.

El producto apalanca más de 50 años de experiencia de Precisely (y sus compañías predecesoras) en mainframe, IBM i y datos estructurados de alto volumen. Su motor incluye un algoritmo de autotuning que selecciona dinámicamente la estrategia más eficiente según la estructura de los datos y los atributos del sistema en tiempo de ejecución, lo que lo diferencia de soluciones de CDC más genéricas.

La línea Connect permite mapear y enviar datos de mainframe e IBM i a Apache Kafka, Snowflake, Cloudera, Databricks, Amazon AWS, Microsoft Azure y Google Cloud Platform, entre otros.

Cómo funciona en IBM i

Connect CDC para IBM i usa los journals nativos de DB2 for i para capturar cambios. El journal de IBM i es un mecanismo propio del sistema operativo que registra de forma cronológica cada operación sobre los objetos que le están asignados (tablas, archivos físicos). A diferencia de los redo logs de Oracle o el transaction log de SQL Server, el journal de IBM i es un objeto del sistema (*JRN) que debe activarse explícitamente sobre cada tabla.

Cuando Connect CDC está operativo, su agente en IBM i lee continuamente las entradas del journal sin intervenir en la aplicación fuente. Los cambios capturados se transmiten vía IBM i Data Queues hacia el motor de Connect (que puede correr en un host Linux, AIX o Windows externo), donde se aplican las transformaciones y se entrega al destino.

Requisito clave: todas las tablas IBM i en scope deben estar journaled con imágenes AFTER o BOTH. La imagen de journal define qué versión del registro se guarda ante un cambio:

• •AFTER — guarda el estado del registro tras el cambio. Suficiente para replicación hacia destinos.
• •BOTH — guarda el estado antes y después del cambio. Necesario para ciertos escenarios de auditoría o reconciliación.
• •BEFORE solamente — Connect CDC no puede operar correctamente con solo imagen BEFORE, ya que no tiene el estado resultante del cambio.

Para activar el journaling sobre una tabla que no lo tiene, se usa la secuencia de comandos CL: crear el receiver (CRTJRNRCV), crear el journal (CRTJRN), y asignar la tabla al journal (STRJRNPF para archivos físicos o STRJRNOBJ para tablas SQL). El sistema requiere también configurar el timezone correcto en QUTCOFFSET para que los timestamps de los eventos sean consistentes entre el host IBM i y el motor de Connect.

Fuentes y destinos soportados

Fuentes soportadas: VSAM, IMS, COBOL copybooks, archivos mainframe fixed y sequential, Oracle, SQL Server, Db2 for z/OS, Db2 for i, Db2 for LUW, MySQL, Sybase, PostgreSQL, Teradata, IBM Netezza, Vertica, Greenplum, formatos semiestructurados (JSON, XML), Hadoop/Hive/Impala, Apache Avro, Parquet, Spark.

Destinos soportados: Db2, Oracle, SQL Server, MySQL, PostgreSQL, Teradata, Informix, Sybase, Apache Kafka / Confluent, Snowflake, Amazon AWS (S3, Redshift), Microsoft Azure (Synapse Analytics, ADLS), Google Cloud Platform, Cloudera, Databricks.

La amplitud de la matriz de fuentes y destinos es uno de los principales diferenciadores de Connect frente a competidores como Debezium (limitado en cobertura mainframe/IBM i) o tcVISION (especializado en z/OS pero más acotado en destinos modernos).

Características arquitectónicas

• •Captura basada en log (journal en IBM i, redo log en Oracle, transaction log en SQL Server) — impacto mínimo sobre la fuente: el motor lee el log, no hace queries sobre las tablas productivas.
• •Cola de streaming para gestionar cambios individuales en orden, desacoplando la velocidad de captura de la velocidad del destino.
• •Pseudo-two-phase commit: garantiza que ningún cambio se pierde, incluso si la conexión entre el agente y el motor se cae durante la transmisión. Cuando la conexión se restablece, el proceso retoma desde el último punto confirmado, sin duplicar ni perder eventos.
• •Topologías múltiples: punto a punto unidireccional, distribución broadcast (1→N), consolidación (N→1), activo-activo bidireccional, y encadenamientos en cascada. Esto permite escenarios de replicación desde IBM i hacia múltiples destinos simultáneamente.
• •Entrega en streaming o en batch según el destino: para Kafka se usa streaming evento a evento; para Snowflake o S3 se usan micro-batches configurable en ventanas de tiempo.
• •Self-tuning engine: selecciona automáticamente los algoritmos más eficientes en función de la estructura de los datos y las características del sistema en tiempo de ejecución, sin intervención manual.
• •Integración con Schema Registry de Kafka: Connect CDC trabaja con el directorio de esquemas de Apache Kafka para mantener la integridad de los metadatos a lo largo del pipeline de streaming, habilitando el uso de Avro y validación de esquemas.
• •Soporte de transformaciones y mapping a la estructura del destino (renombres, conversión de tipos, derivaciones simples).

Documentación oficial

El portal de documentación vivo está en help.precisely.com, con guías específicas por versión (6.x al momento de redactar este material) e instalación por plataforma.

Objetivo del rol en este módulo: diseñar pipelines, dimensionar y entregar POC.

Arquitectura de referencia para IBM i

[IBM i source]
   |
   journal DB2 for i (AFTER / BOTH)
   |
   Captura Connect CDC (agente IBM i)
   |
   IBM i Data Queues
   |
   Motor Connect (transformaciones, mapping)
   |
[Destino: Kafka / Snowflake / SQL Server / Oracle / etc.]

El agente CDC corre como un job en IBM i y lee continuamente el journal asignado a las tablas en scope. Los cambios se encolan en IBM i Data Queues — mecanismo nativo del OS para intercambio de mensajes entre jobs — y desde ahí el motor Connect los procesa en el host externo. Este diseño desacopla la captura (en IBM i) del procesamiento y entrega (en el motor externo), permitiendo que el IBM i quede con impacto mínimo.

La preparación del entorno IBM i incluye: confirmar que TCP/IP está activo, tener al menos 50 MB de espacio en el IFS para la instalación, contar con Java SE en la versión requerida por el release de Connect, y configurar QUTCOFFSET para que el desfase horario sea consistente con el motor externo.

Prerequisitos a relevar

1. •Versión y TR de IBM i.
2. •Listado de tablas en scope y volumen de cambios estimado (filas/seg).
3. •Estado de journaling con AFTER o BOTH images en cada tabla en scope.
4. •Destino y su versión (Snowflake account, Kafka cluster + topic strategy, SQL Server version, etc.).
5. •Latencia tolerable (segundos vs minutos vs horas).
6. •Esquema de transformaciones requerido (renombres, type mapping, agregaciones simples).
7. •Esquema de seguridad (auth contra el destino, certificados, network).

Diseño de pipelines

• •Mapping de columnas IBM i → destino (incluyendo nombres reservados, conversión EBCDIC, decimales empaquetados).
• •Manejo de inserts/updates/deletes y de operaciones masivas.
• •Particionado del destino (Kafka topic partitions; Snowflake clustering keys).
• •Replay y catch-up — política tras una caída del destino.
• •Schema evolution — qué pasa cuando se agrega una columna en el source.

POC end-to-end

1. •Setup mínimo: source IBM i con tablas de prueba journaled.
2. •Configurar agente Connect CDC en IBM i.
3. •Configurar destino (ej. tópico Kafka o tabla en Snowflake).
4. •Ejecutar carga inicial.
5. •Provocar cambios en source (insert/update/delete) y verificar en destino.
6. •Probar catch-up: detener destino, generar cambios, reanudar.
7. •Probar transformaciones simples.

Dimensionamiento

• •CPU/memoria del agente en IBM i (impacto sobre LPAR fuente).
• •Network entre IBM i y motor Connect.
• •Resources del motor Connect (puede ir en VM Linux/AIX/Windows según versión).
• •Throughput sostenido y picos.
• •Storage del destino (Snowflake credits, Kafka retention).