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: RCA, performance tuning y manejo de escenarios complejos.

Root cause analysis típicos

• •Lag persistente — separar si el cuello está en captura (IBM i agent), red, motor Connect o destino.
• •Pérdida o duplicado de filas — verificar pseudo-2PC, journaling, idempotencia del destino.
• •Tipos de datos mal traducidos — packed decimal, fechas IBM i (*JOB/*ISO), CCSID/EBCDIC.
• •Catch-up imposible o muy lento tras caída larga — política de retención de receivers.

Performance tuning

• •Lado IBM i: tamaño y rotación de receivers, agentes paralelos, prioridad del subsistema, separación de scopes por journal.
• •Lado motor Connect: workers, batch size, commit interval, self-tuning engine (verificar que no esté forzado manualmente a un algoritmo subóptimo).
• •Lado destino:
  • •Kafka: particiones, batch.size, linger.ms.
  • •Snowflake: micro-batches vs streams; warehouse size.
  • •Bases relacionales: bulk insert, índices, locks, modo de aplicación (merge vs upsert).
• •Red: ancho de banda, latencia, MTU, compresión.

Manejo de escenarios complejos

• •Schema evolution con compatibilidad hacia atrás.
• •Re-sincronización con verificación end-to-end (snapshot inicial + CDC desde cierto LSN/sequence).
• •Cambios de receivers durante operación.
• •Coordinación con upgrades de IBM i (parches que afectan journaling).
• •Migraciones del motor Connect (versión nueva, host nuevo, alta disponibilidad del motor).

Diagnóstico de lag por capas

El lag en un pipeline Connect CDC puede originarse en cualquier punto de la cadena. La secuencia de diagnóstico separa las capas de adentro hacia afuera:

Capa 1 — Journal source (IBM i):

DSPJRN JRN(ORDLIB/ORDJRN) RCVRNG(*CURCHAIN) NBRRCV(1) OUTPUT(*PRINT)

Verificar: ¿el receiver activo está creciendo normalmente? ¿El agente CDC está leyendo entradas recientes o está leyendo un receiver viejo? Si el agente lee un receiver que no es el actual, hay backlog en la captura.

Capa 2 — Agente de captura (job en IBM i):

WRKACTJOB SBS(EDHSBS)

Verificar el job del agente CDC: ¿está en estado RUN o está en MSGW/DEQW? Si está en DEQW (dequeue wait), está esperando por nuevas entradas del journal — eso es normal si no hay actividad en source. Si está en RUN constante, está procesando backlog.

Verificar el CPU y I/O del job: si el job consume mucho CPU, puede necesitar más prioridad o el receiver es muy grande.

Capa 3 — Transporte (red IBM i → motor Connect): Verificar throughput de la data queue. Si la data queue en IBM i tiene muchas entradas pendientes, el motor Connect no está consumiendo lo suficientemente rápido. Posible cuello de red o motor Connect sobrecargado.

Capa 4 — Motor Connect (host externo): Revisar los logs del motor en el host donde corre (Linux/AIX/Windows). Buscar:

• •Mensajes de slow apply o batch timeout.
• •Errores de conexión al destino.
• •Transformaciones que están consumiendo demasiado CPU.

Capa 5 — Destino (Kafka / Snowflake / RDBMS):

• •Kafka: verificar que los brokers están healthy con kafka-consumer-groups.sh --describe. Si hay consumer lag, el problema puede ser del consumidor downstream, no de Connect.
• •Snowflake: verificar que el warehouse esté activo y no suspendido. Un warehouse auto-suspendido causa timeout de escritura.
• •RDBMS: verificar locks en tablas destino con las herramientas propias del motor (pg_stat_activity en PostgreSQL, sp_who2 en SQL Server).

Troubleshooting de traducción EBCDIC / packed decimal

Los problemas de encoding son de los más difíciles de diagnosticar porque a veces los datos llegan al destino "casi bien" — se ven correctos a simple vista pero tienen caracteres corruptos en campos específicos.

Packed decimal (campos DEC en Db2 for i):

IBM i almacena campos decimales en formato "packed" — dos dígitos por byte, con el último nibble como signo. Ejemplo: el valor 12345.67 en un campo DEC(7,2) se almacena como 01 23 45 67 0F (5 bytes, F=positivo).

Si Connect CDC no traduce correctamente el packed decimal, el destino puede recibir:

• •Un número con signo incorrecto (negativo en lugar de positivo).
• •Un número truncado o desplazado.
• •Un valor absurdo (bytes interpretados como ASCII en lugar de packed).

Diagnóstico: comparar el valor en source (SELECT CAMPO FROM TABLA WHERE KEY=X) con el valor en destino. Si difieren, verificar la definición del mapping: el tipo source debe ser PACKED o DECIMAL, no CHAR.

EBCDIC → UTF-8 (campos CHAR/VARCHAR):

IBM i usa EBCDIC (CCSID 37 para US English, CCSID 284 para Spanish, etc.). El destino típicamente usa UTF-8. Connect CDC maneja la conversión, pero problemas comunes:

• •Caracteres especiales (ñ, á, ü) corruptos → verificar que el CCSID del source file esté correctamente detectado.
• •Campos con CCSID(65535) (hex data, no traducir) → el mapping debe marcarlos como BINARY, no como CHAR.

Re-sincronización — procedimiento

Cuando un pipeline se desincroniza (datos en destino no coinciden con source), la resincronización sigue estos pasos:

1. •Detener el pipeline CDC para el scope afectado.
2. •Ejecutar carga inicial (initial load / refresh) desde source al destino para las tablas afectadas. Connect CDC tiene un modo de refresh que carga la tabla completa y luego retoma CDC desde el punto actual del journal.
3. •Verificar la carga: comparar row counts entre source y destino.
4. •Reanudar CDC: el pipeline retoma desde el journal sequence posterior a la carga inicial.
5. •Validar: monitorear las primeras horas para confirmar que no hay nuevas divergencias.

Si la desincronización fue causada por un receiver purgado (el apply necesitaba un receiver que ya no existe), la re-sincronización completa es la única opción.

Transformaciones avanzadas

• •Agregaciones simples y filtros.
• •Lookups contra tablas de referencia.
• •Mapping de tipos complejos.
• •Cuándo dejar la transformación al destino (Snowflake / dbt) en lugar de hacerla en Connect.