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: operar pipelines en régimen, detectar errores típicos, recolectar evidencia.

Operación normal

• •Verificar status diario de los pipelines.
• •Verificar lag (segundos/minutos entre cambio en source y aplicación en destino).
• •Revisar mensajes de QSYSOPR y joblog del agente CDC en IBM i.
• •Verificar logs del motor Connect en su host.

Errores típicos a reconocer

• •Tabla nueva no journaled — el equipo de aplicación creó una tabla y no se journalizó. Bloquea su captura.
• •Imagen de journal incorrecta — BEFORE solamente en lugar de AFTER/BOTH. CDC no puede operar bien.
• •Authentication error contra destino — credenciales rotadas, token expirado, certificado vencido.
• •Lock en destino — DDL en la tabla destino impide aplicar.
• •Mapping mismatch — la columna nueva en source no tiene mapping al destino.
• •Cola de Data Queue saturada — backlog en IBM i, suele indicar destino caído o lento.

Recolección de evidencia

• •Joblog del agente CDC en IBM i.
• •Logs del motor Connect (timestamp del problema).
• •Error específico devuelto por el destino (Kafka broker error, Snowflake error code, ODBC error).
• •Versión de Connect CDC instalada (revisar contra docs de la versión específica en help.precisely.com).

Verificar estado de pipelines en la consola Connect

La consola de administración de Connect CDC tiene una interfaz web. La navegación típica para verificar estado:

1. •Acceder a la consola: http://[host-motor]:puerto/connect (el puerto depende de la instalación, típicamente 8080 o similar).
2. •En el menú principal, navegar a Replication > Pipelines (o Subscriptions según la versión).
3. •Para cada pipeline se muestra: nombre, estado (Running/Stopped/Error), lag, último evento procesado, timestamp.
4. •Un pipeline en estado Running con lag bajo (<10 segundos) es normal.
5. •Un pipeline en estado Error requiere atención: hacer clic para ver el detalle del error.
6. •En la sección Activity Log (o Event Log) se muestra el historial de eventos con timestamps.

Indicadores de pipeline sano vs pipeline con problemas:

| Indicador | Sano | Problema | |---|---|---| | Estado | Running | Stopped / Error | | Lag | <10 segundos | >60 segundos o creciendo | | Último evento | Reciente (últimos segundos) | Viejo (>5 minutos sin nuevo evento) | | Errores (last 1h) | 0 | >0 |

Ejemplo de entrada de log con error

2026-05-08 10:23:45.123 ERROR [Pipeline: ORDERS_TO_KAFKA]
  Source: IBM i PRODSYS / ORDLIB.ORDERDETAIL
  Error: Journal entry type 'PT' not supported for table ORDERDETAIL.
  Journal receiver: QZRDJRN0042 at sequence 1,234,567.
  Action: Entry skipped. Pipeline continues.
  Impact: Record at sequence 1,234,567 not replicated to target.

Cómo interpretar: el tipo de journal entry PT (program temporary — una operación interna del sistema) no es un cambio de dato replicable. Connect CDC lo saltea y continúa. Si la entrada dice Entry skipped, no suele ser crítico. Si dice Pipeline stopped o Fatal error, es crítico.

Mensajes de error comunes de Connect CDC

| Mensaje | Significado | Acción L1 | |---|---|---| | Journal image type BEFORE only — AFTER or BOTH required | La tabla tiene journaling pero solo con imagen *BEFORE. CDC necesita *AFTER o *BOTH. | Escalar a operaciones para cambiar el tipo de imagen con CHGJRNOBJ. | | Connection to target refused | El motor no puede conectarse al destino (Kafka broker, Snowflake, etc.). | Verificar que el destino esté up. Verificar red/firewall entre motor Connect y destino. | | Authentication failure for target [nombre] | Credenciales inválidas o expiradas para el destino. | Verificar credenciales. Común tras rotación de passwords o expiración de tokens. | | Data queue EDTAQ overflow | La data queue en IBM i está llena — el motor Connect no está consumiendo lo suficientemente rápido. | Verificar que el motor Connect esté running. Si está running, puede ser un problema de throughput — escalar a senior. | | Schema mismatch: column [nombre] not found in target | Se agregó una columna en la tabla source pero el mapping no se actualizó. | Escalar a senior o desarrollo para actualizar el mapping del pipeline. |

Cómo escalar

• •Portal Precisely Support con contrato vigente.
• •Adjuntar versiones, logs, descripción reproducible.
• •Categorizar severidad: pipeline caído en producción ≠ aviso de mapping menor.