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 configuración avanzada, automatizar, integrar.

Configuración como código

• •Versionar configuraciones de pipeline en Git.
• •Pipelines parametrizables por entorno (dev/QA/prod).
• •Despliegues controlados con scripts.

Mapping y transformaciones avanzadas

• •Definición declarativa de mapping source→target.
• •Lookups, derivaciones, normalización.
• •Buenas prácticas: minimizar transformaciones en CDC; preferirlas en el destino moderno (dbt, Snowflake SQL, Spark).

Integración con plataformas de streaming

• •Kafka: estrategia de tópicos (uno por tabla vs uno por dominio), schemas (Avro / Confluent Schema Registry), particionado por clave de negocio.
• •Confluent: Connect CDC se integra directamente con Confluent Platform. El flujo típico es: Connect CDC captura cambios desde IBM i/mainframe y los publica en tópicos Confluent Kafka. El Schema Registry de Confluent gestiona la evolución de esquemas de los mensajes usando Avro, garantizando que productores y consumidores mantengan compatibilidad cuando el esquema cambia. Desde Confluent, los datos pueden fluir hacia cualquier consumidor Kafka estándar (aplicaciones, ksqlDB, Kafka Connect hacia otros destinos).

Buenas prácticas de aplicación IBM i

• •Toda tabla productiva nace journaled con AFTER/BOTH.
• •Documentar el contrato de datos (qué tablas/columnas son públicas hacia downstream).
• •Cambios de schema con periodo de coexistencia.
• •Triggers / nuevos endpoints de aplicación deben considerar el impacto sobre downstream CDC.

Ejemplo de configuración de pipeline (source → Kafka topic)

La configuración de un pipeline Connect CDC se define declarativamente. A continuación un ejemplo conceptual del mapping de una tabla IBM i hacia un tópico Kafka:

# Pipeline: ORDERS to Kafka
pipeline:
  name: ORDERS_TO_KAFKA
  source:
    type: ibmi
    connection: PRODSYS
    schema: ORDLIB
    table: ORDERS
    journal: ORDLIB/ORDJRN
    image: BOTH
  target:
    type: kafka
    broker: kafka-cluster:9092
    topic: ibmi.ordlib.orders
    format: avro
    schema_registry: http://schema-registry:8081
  mapping:
    - source: ORDNUM     target: order_number    type: INTEGER
    - source: CUSTID     target: customer_id     type: INTEGER
    - source: ORDDAT     target: order_date      type: DATE       format: ISO
    - source: ORDAMT     target: order_amount    type: DECIMAL    precision: 11  scale: 2
    - source: ORDSTS     target: order_status    type: VARCHAR    length: 10
    - source: UPDTMS     target: update_ts       type: TIMESTAMP
  options:
    initial_load: true
    batch_size: 1000
    commit_interval: 5000

Notas sobre el mapping: ORDAMT es un campo packed decimal en IBM i — el mapping lo traduce a DECIMAL(11,2) en Avro. ORDDAT se convierte de formato IBM i (*ISO o *JOB) a ISO 8601.

Ejemplo de schema Avro para una tabla IBM i

El schema Avro que registra Connect CDC en el Schema Registry de Kafka describe la estructura del mensaje:

{
  "type": "record",
  "name": "orders",
  "namespace": "ibmi.ordlib",
  "fields": [
    {"name": "order_number", "type": "int"},
    {"name": "customer_id", "type": "int"},
    {"name": "order_date", "type": {"type": "int", "logicalType": "date"}},
    {"name": "order_amount", "type": {"type": "bytes", "logicalType": "decimal", "precision": 11, "scale": 2}},
    {"name": "order_status", "type": "string"},
    {"name": "update_ts", "type": {"type": "long", "logicalType": "timestamp-millis"}},
    {"name": "_op", "type": "string", "doc": "Operation type: I=insert, U=update, D=delete"},
    {"name": "_ts", "type": {"type": "long", "logicalType": "timestamp-millis"}, "doc": "Journal entry timestamp"}
  ]
}

El campo _op es metadata que Connect CDC agrega para indicar el tipo de operación CDC. Los consumidores downstream usan este campo para decidir si hacer INSERT, UPDATE o DELETE en su destino final.

Ejemplo de regla de transformación

Las transformaciones se definen en el pipeline para adaptar los datos de IBM i al modelo del destino:

transformations:
  # Derivar un campo calculado
  - type: derive
    name: order_total_with_tax
    expression: "order_amount * 1.21"

  # Filtrar solo registros activos
  - type: filter
    condition: "order_status <> 'CANCELLED'"

  # Lookup contra tabla de referencia
  - type: lookup
    source_key: customer_id
    reference_table: ORDLIB.CUSTOMERS
    reference_key: CUSTID
    output_field: customer_name
    reference_field: CUSTNAME

  # Renombrar campo con nombre reservado en destino
  - type: rename
    source: DATE
    target: order_date

Query template para reconciliación source/target

Cuando hay sospecha de datos faltantes o duplicados, esta query compara counts y checksums:

En el source (IBM i):

SELECT COUNT(*) AS row_count,
       SUM(ORDAMT) AS total_amount,
       MAX(UPDTMS) AS last_update
FROM ORDLIB.ORDERS
WHERE ORDDAT >= '2026-05-01';

En el destino (Snowflake/PostgreSQL):

SELECT COUNT(*) AS row_count,
       SUM(order_amount) AS total_amount,
       MAX(update_ts) AS last_update
FROM ordlib.orders
WHERE order_date >= '2026-05-01';

Comparar los tres valores. Si row_count difiere, hay registros faltantes o duplicados. Si total_amount difiere con el mismo row_count, hay un problema de traducción de packed decimal. Si last_update en el destino es anterior al source, hay lag no resuelto.

Troubleshooting desde el ángulo del dato

• •Validar fila a fila ante incidentes (count diff, hash diff).
• •Reconciliar receivers IBM i con offsets en destino.
• •Replay controlado desde un punto.

Recurso oficial

help.precisely.com — Connect CDC