Conectividad e interoperabilidad
Integración con sistemas legados y bases de datos sin API
01 · Origen
- Base de datos del sistema heredado
- Réplica de lectura o copia programada
02 · Captura
- Registro de transacciones si el motor lo permite
- Consulta incremental como alternativa
03 · Traducción
- Capa anticorrupción: códigos y estados al modelo actual
- Validación de tipos, fechas y codificación
04 · Destino y control
- Aplicación nueva o almacén analítico
- Conteos y sumas de control por lote
- Rechazos con motivo para revisión
El problema
Por qué hay que decidirlo bien
El atajo tentador es conectarse directamente a las tablas del sistema antiguo y leer o escribir lo que haga falta. Funciona hasta que una consulta pesada ralentiza la aplicación en horario de trabajo, una escritura se salta una regla que vivía en el código y deja registros huérfanos, o el proveedor cambia una columna en una actualización. Además, el software nuevo acaba heredando códigos crípticos y estructuras de hace décadas. El reto es obtener los datos que el negocio necesita con un impacto controlado y sin que el sistema viejo dicte el diseño del nuevo.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Lectura desde una réplica en lugar de producción
La aplicación heredada guarda pedidos en una base de datos relacional sin API. Se habilita una réplica de lectura o una copia programada y un usuario con permisos mínimos sobre vistas acordadas, de modo que las consultas nuevas no compiten con los usuarios del sistema.
02
Carga a un almacén analítico con ELT
Los datos se copian casi en bruto a un almacén analítico y las transformaciones se hacen allí, versionadas y repetibles. Si una regla de cálculo cambia, se recalcula el histórico sin volver a extraer nada del sistema antiguo.
03
Captura de cambios durante una coexistencia
Mientras conviven el sistema antiguo y el nuevo, cada alta o modificación debe llegar al nuevo en minutos. Si el motor y su soporte lo permiten, se lee el registro de transacciones; si no, se recurre a consultas incrementales con marcas de tiempo fiables.
04
Intercambio por ficheros de formato fijo
El sistema solo importa y exporta ficheros de ancho fijo con una codificación de caracteres antigua. Se construye un lector y un generador con pruebas sobre ficheros reales, control de duplicados por nombre y suma de control, y acuse de cada fichero procesado.
05
Escribir a través del propio sistema
Para registrar datos en la aplicación heredada se usan sus vías oficiales: un importador, un procedimiento almacenado documentado o una tabla de intercambio que el propio sistema valida. Nunca se insertan filas directamente en sus tablas internas.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
Vía de acceso
Por orden de preferencia: interfaz oficial aunque sea antigua, tablas o ficheros de intercambio, lectura sobre réplica o vistas y, solo como último recurso y en lectura, consulta directa. Cada opción se valida con quien da soporte al sistema.
02
ETL o ELT
ETL transforma antes de cargar y conviene cuando el destino es otra aplicación con reglas estrictas. ELT carga primero y transforma en destino, útil para análisis e histórico. Muchos proyectos combinan ambos según el destino.
03
Captura de cambios o consulta incremental
La captura basada en el registro de transacciones detecta también los borrados y apenas carga la base de datos, pero exige soporte del motor, permisos y licencia. La consulta incremental es más sencilla y depende de columnas de fecha que se actualicen siempre.
04
Capa anticorrupción
Un componente intermedio traduce estados codificados, claves compuestas y campos reutilizados a un modelo claro. El software nuevo solo conoce ese modelo, y cuando el sistema antiguo desaparezca bastará con sustituir la capa.
05
Escritura y consistencia
Se decide si el sistema heredado sigue siendo dueño de los datos o pasa a ser destino. Toda escritura pasa por su lógica, con confirmación de resultado, y se evita que dos sistemas escriban la misma entidad a la vez.
06
Control de lotes y reconciliación
Cada carga registra cuántos registros salieron, cuántos llegaron y cuántos se rechazaron, con sumas de control sobre importes. Las diferencias generan aviso en lugar de descubrirse semanas después en un informe.
Riesgos y límites
Lo que conviene tener presente
- Leer directamente de la base de datos de producción puede degradar el rendimiento del sistema; las consultas se prueban con volúmenes reales y en horarios acordados.
- La estructura interna de un producto comercial puede cambiar en cualquier actualización y el acceso directo puede no estar permitido por su licencia o soporte.
- Los datos antiguos suelen tener codificaciones mixtas, fechas imposibles y duplicados; la limpieza forma parte del trabajo, no es un imprevisto.
- Las credenciales de acceso a la base de datos deben limitarse a lo imprescindible y vivir fuera del código, con registro de su uso.
Preguntas frecuentes
¿Se puede integrar un sistema del que no tenemos documentación?
Normalmente sí, pero hay que dedicar tiempo a entender su modelo de datos observando tablas, ficheros y comportamiento con usuarios que lo conocen. Ese análisis se documenta, porque se convierte en la referencia que antes no existía.
¿La captura de cambios funciona con cualquier base de datos?
No. Depende del motor, de su versión, de la configuración del registro de transacciones y de los permisos que conceda quien administra la base de datos. Cuando no es viable, la consulta incremental o la comparación periódica son alternativas razonables.
¿Por qué no escribir directamente en las tablas si es más rápido?
Porque el sistema suele aplicar reglas en su código que la base de datos no impone: numeraciones, totales, estados dependientes. Saltárselas deja datos que la aplicación no espera y que pueden aflorar como errores mucho después.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- Modernización legacySustituir por partes un software antiguo que sigue sosteniendo la operación, empezando por entender bien qué hace.
- Integración de sistemasConexiones entre aplicaciones que mueven datos con reglas claras, detectan errores y permiten saber qué versión de cada dato es la buena.
- Analítica operativaIndicadores, alertas e históricos construidos sobre datos depurados y con definiciones acordadas, para que todos discutan la misma cifra.
Cuéntanos qué sistema antiguo tienes y qué datos necesitas sacar o meter
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.