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: vender el caso de modernización — sacar valor de los datos del IBM i sin tocar el aplicativo legacy.

Discurso de elevator pitch

"Tenemos clientes con datos críticos en IBM i que el resto de la empresa quiere consumir en su data lake, su CRM, su Snowflake. Connect CDC los lleva en tiempo real, sin tocar la aplicación legacy, sin downtime y sin DBA-magic. La fuente sigue siendo lo que ya está; el dato fluye limpio hacia donde el negocio lo necesita."

Casos de uso concretos

• •Modernización de analytics — replicar IBM i a Snowflake / BigQuery / Databricks para reportería moderna.
• •Data lake corporativo — feed continuo de IBM i a S3/ADLS/GCS vía Kafka.
• •Sincronización con CRM/ERP — mantener Salesforce / SAP / Dynamics actualizados con datos del core IBM i.
• •Streaming en tiempo real — eventos de negocio del IBM i hacia consumidores Kafka.
• •Migración asistida — replicar mientras se reescribe la app, hasta el cutover.
• •Reducción de carga en producción IBM i moviendo reporting a destino externo.

Preguntas calificadoras

• •¿Tienen iniciativa de data lake / cloud analytics?
• •¿Cuáles son las fuentes de datos prioritarias?
• •¿IBM i es una de las fuentes "difíciles" para su equipo de datos?
• •¿Qué destino tienen ya operativo (Snowflake, Kafka, BigQuery)?
• •¿Qué herramientas de integración usan hoy y por qué no les alcanza?
• •¿Hacen ETL nocturno y lo quieren llevar a near-real-time?

Competencia

| Competidor | Posicionamiento | |---|---| | IBM InfoSphere Data Replication / CDC | Histórica solución de IBM. Connect compite con cobertura más amplia de destinos modernos y por integración suite Precisely. | | Qlik Replicate (ex-Attunity) | Player fuerte en CDC heterogéneo. Comparar matriz de fuentes/destinos por caso. | | HVR (hoy parte de Fivetran) | Otro CDC heterogéneo. | | Debezium (open source) | Para Postgres/MySQL/SQL Server CDC. Cobertura limitada para IBM i / mainframe. | | tcVISION (Treehouse Software) | Especializado en mainframe-Kafka, frecuente en deals con z/OS. | | Soluciones nativas IBM i | Algunos clientes intentan resolverlo con triggers + queues; suele escalar mal. |

Modelo comercial

Licenciamiento por core del source y/o por volumen de datos según contrato. Mantenimiento anual obligatorio para soporte y nuevas versiones. (Validar términos exactos contra el book of business actual de Precisely.)