Cómo integrar un ERP con una aplicación web (opciones, arquitectura y errores a evitar)

Antes de la técnica, tres preguntas de negocio

1. ¿Qué datos y en qué sentido? Productos, precios, stock, clientes, pedidos, facturas… Y para cada uno, si va del ERP a la web, de la web al ERP o en ambos sentidos.
2. ¿Cómo de frescos? No es lo mismo publicar el stock “de hace una hora” que impedir en tiempo real que se venda lo que no hay. Cada nivel de frescura tiene un coste distinto.
3. ¿Quién manda? Cuando la web y el ERP discrepen (y discreparán), hay que saber qué sistema es la fuente de verdad de cada dato. Casi siempre recomendamos lo mismo: el ERP manda en precios, stock y clientes, y la web manda en lo que nace en ella (el pedido, el registro del usuario). Funciona incluso cuando el ERP es intocable.

Con esas tres respuestas, la conversación técnica se vuelve corta.

Las cuatro vías, con sus trade-offs

1. API del ERP

Si el ERP expone una API (REST o similar), suele ser la vía preferente. Tiene un contrato definido y permisos, y el fabricante la mantiene entre versiones.

• A favor. Estabilidad, seguridad y soporte del fabricante.
• En contra. Muchas APIs de ERP son incompletas (cubren el catálogo pero no las tarifas especiales, por ejemplo), tienen límites de uso o se licencian aparte.
• Cuándo. Siempre que exista y cubra los datos que necesitas.

2. Acceso directo a la base de datos

Esta vía y la anterior son las que más se confunden. Lo explicamos en cuándo usar la API y cuándo entrar a la base de datos, con los riesgos de cada una.

Consiste en leer (y a veces escribir) directamente en la base de datos del ERP.

• A favor. Acceso a todo, sin los límites de la API.
• En contra. Es la vía más delicada. El esquema interno no es un contrato, así que una actualización del ERP puede romperlo todo sin aviso. Y escribir directamente en la base de datos de un ERP puede corromper datos o saltarse su lógica de negocio.
• Cuándo. Para lectura, con un ERP antiguo sin API, puede ser perfectamente razonable. Para escritura, solo como último recurso y con mucho cuidado (idealmente usando los mecanismos de importación que valide el propio ERP).

3. Intercambio de ficheros

Es el método veterano: el ERP exporta e importa ficheros (CSV, XML…) de forma programada.

• A favor. Lo soportan hasta los ERPs más antiguos, y es sencillo de auditar porque el fichero es la evidencia.
• En contra. La frescura queda limitada por la frecuencia, y hay que gestionar errores de formato y ejecuciones a medias.
• Cuándo. Cuando no hay nada mejor, o cuando el dato llega por lotes por naturaleza (tarifas que cambian una vez al día, por ejemplo). Automatizado y validado, es mucho más digno de lo que su fama sugiere.

4. Middleware (capa intermedia)

Es un servicio propio entre el ERP y la web que orquesta la sincronización. Lee de un lado por la vía que sea, transforma, valida y escribe en el otro.

• A favor. Desacopla los sistemas (si el ERP se cae, la web sigue y los pedidos se encolan), centraliza validación y logs, y permite combinar vías (API para pedidos, ficheros para tarifas).
• En contra. Es una pieza más que construir y mantener.
• Cuándo. En cuanto la integración deja de ser trivial, porque hay más de un flujo de datos, sistemas delicados o necesidad de trazabilidad. En nuestra experiencia, es la arquitectura que acaba teniendo casi cualquier integración seria.

        WEB / APP
            ↕
       MIDDLEWARE     ← validación · cola · registro · avisos
            ↕
   API | BD | ficheros
            ↕
           ERP

Tiempo real vs sincronización programada

La petición inicial casi siempre es “en tiempo real”. Lo que hay que preguntarse es qué pasa si este dato tiene X minutos de antigüedad. Para el stock de un ecommerce con margen, poco; para un catálogo, nada; para confirmar la disponibilidad exacta de la última unidad, mucho.

El tiempo real estricto acopla los sistemas (la web depende de que el ERP responda ya) y multiplica la complejidad. Una sincronización programada frecuente, con colas para lo que nace en la web, cubre la gran mayoría de casos con una fracción del riesgo. Reserva el tiempo real para los datos que lo exigen.

Los errores que vemos repetirse

1. Conectar sin validar. La integración “funciona” hasta que llega el primer dato imperfecto, y los datos reales siempre lo son. Cada lote debe validarse, y los registros problemáticos deben apartarse y notificarse, sin bloquear al resto ni colarse sucios.
2. No registrar las ejecuciones. Cuando algo no cuadra (“¿por qué este pedido no está en el ERP?”), la respuesta debe estar en un log que diga qué se movió, cuándo y con qué resultado. Sin eso, cada incidencia es una investigación arqueológica.
3. Olvidar la idempotencia. Si repetir una sincronización duplica pedidos, tienes una bomba. Toda operación debe poder relanzarse sin efectos dobles.
4. La web escribiendo a pelo en el ERP. Saltarse la lógica de negocio del ERP escribiendo directo en sus tablas es la vía rápida a datos corruptos.
5. Dos fuentes de verdad. Si el precio se puede editar en los dos sistemas, tendrás dos precios. Decidir quién manda en cada dato es una decisión de negocio y va antes que cualquier línea de código.
6. Todo o nada. Es intentar sincronizarlo todo desde el día uno. Funciona mejor poner en producción primero el flujo más doloroso y ampliar desde ahí.

¿Y si mi ERP es antiguo o “no tiene integración”?

Es la situación más común en pymes, y casi nunca es bloqueante. La mayoría de ERPs veteranos permiten al menos leer la base de datos o intercambiar ficheros, y con un middleware delante se construye una integración sólida con esos mimbres. Lo hemos hecho sobre sistemas con décadas de historia. Así que la cuestión casi nunca es si se puede, sino qué vía es razonable y cuánto cuesta mantenerla.

Preguntas frecuentes

¿Necesito que mi ERP tenga API para integrarlo? No. Ayuda, pero hay tres vías más. Lo determinante es qué datos necesitas mover y con qué frescura.

¿Cuánto se tarda en integrar un ERP con una web? Una integración acotada (un flujo, un sentido) puede estar en producción en semanas; un proyecto con varios flujos bidireccionales, más. La fase de análisis inicial es la que da la cifra honesta.

¿Qué pasa si el ERP se actualiza? Si la integración va por API oficial, normalmente poco. Si va por base de datos o ficheros, cada actualización del ERP debe probarse contra la integración. Es otra razón para tener staging y monitorización.

¿Puedo integrar también el CRM, el ecommerce y la web corporativa? Sí. De hecho, el middleware existe para eso: una vez construida la capa, añadir sistemas es incremental.