Integración de sistemas para que tus programas dejen de ir cada uno por su lado

La integración de sistemas no es un capricho técnico, es la diferencia entre una empresa que consulta y una empresa que pregunta. Cuando los programas están conectados, el dato se escribe una vez en el sitio donde nace y viaja solo hasta donde hace falta. Cuando no lo están, la empresa dedica una parte enorme de su tiempo administrativo a mantener sincronizadas cinco versiones distintas de la misma verdad.

Hay cuatro formas habituales de conectar dos programas. La primera y mejor es la API, cuando el otro sistema la ofrece: se piden y se envían datos en tiempo real y con control de errores. La segunda son los webhooks, en los que el otro sistema avisa cuando ocurre algo, lo que evita estar preguntando cada pocos minutos. La tercera es el intercambio de ficheros, todavía muy común en logística y en banca, con exportaciones programadas en formatos como CSV o XML. Y la cuarta es el acceso directo a la base de datos, que solo se usa cuando el fabricante lo permite y no hay alternativa.

En España lo normal es que una pyme tenga una mezcla: un programa de contabilidad o facturación (Holded, Sage o A3 son de los que más nos encontramos), una tienda online, un sistema de almacén, la banca electrónica y la agencia de transporte. Cada uno ofrece cosas distintas, así que la integración se estudia caso por caso. No prometemos conectores ya hechos para un producto concreto sin haber revisado antes su documentación técnica: revisamos qué expone realmente y solo después damos plazo y precio.

Lo último y lo más importante es qué ocurre cuando algo falla, porque va a fallar. Una integración seria reintenta cuando hay un error temporal, no duplica registros si se ejecuta dos veces, avisa a una persona cuando el error es real y deja un histórico consultable de cada dato que se ha movido. Sin eso, una integración es una bomba de relojería silenciosa.

• El dato se escribe una vez y viaja solo
• API, webhooks, ficheros o base de datos
• Reintentos ante errores temporales
• Sin duplicados aunque se repita el envío
• Aviso a una persona cuando el error es real
• Histórico de todo lo sincronizado

Es una situación muy frecuente, sobre todo con programas de gestión antiguos instalados en un servidor de la propia empresa. Que no haya API no significa que no haya integración, significa que hay que elegir bien la vía y ser honestos sobre su fragilidad.

La opción más limpia suele ser el intercambio de ficheros. Muchos programas cerrados permiten exportar movimientos o importar altas en un formato fijo, y con eso se monta una sincronización programada que funciona durante años. Es menos inmediata que una API, porque va por tandas, pero es estable y fácil de auditar.

La segunda opción es leer directamente su base de datos. Es rápida y muy potente, pero solo la planteamos si el fabricante lo autoriza y si la escritura se hace siempre desde el programa original, nunca por detrás, porque escribir a mano en la base de datos de un producto ajeno es la mejor forma de corromper sus datos.

La tercera, y la última que recomendamos, es automatizar la propia interfaz del programa. Funciona, resuelve casos imposibles de otra manera y hay que asumir que se romperá cada vez que el fabricante cambie una pantalla. Si es la única salida, se plantea como puente temporal mientras se decide si ese programa debe seguir en el mapa.

• Ficheros programados, estables y auditables
• Lectura de base de datos solo si está permitido
• Nunca escribir por detrás en producto ajeno
• Automatizar la interfaz solo como puente
• Revisión previa de la licencia del programa
• Plan de salida si el sistema se queda corto