Middleware

El middleware es una capa de software que se ubica "en el medio" entre dos o más sistemas y se encarga de conectarlos, traducir sus formatos y coordinar el intercambio de datos sin que cada aplicación tenga que conocer los detalles internos de la otra. El término viene del inglés (middle = medio, ware = software): es la plomería invisible que hace que un ERP, un CRM, una pasarela de pago y un sistema contable trabajen como un todo coherente.

En la práctica, en vez de programar una conexión punto a punto entre cada par de aplicaciones (lo que genera un "plato de espaguetis" inmanejable), el middleware ofrece un punto central donde se definen las reglas: qué dato sale de dónde, cómo se transforma y a qué sistema llega. Esto es justamente parte de lo que se diseña y gobierna en una implementación sobre Salesforce, donde el middleware suele orquestar el flujo entre la nube de Salesforce y los sistemas legados de la empresa.

A diferencia de una API (que es la "puerta" que cada sistema expone) o de un webhook (un aviso puntual cuando ocurre un evento), el middleware es la infraestructura que consume esas puertas y avisos y los convierte en procesos de negocio integrados, con lógica de reintentos, mapeo de campos y manejo de errores.

Para qué sirve el middleware

Toda empresa con más de un sistema enfrenta el mismo problema: el CRM no sabe lo que pasó en el ERP, el ERP no conoce los pagos de la pasarela y el área de logística trabaja con planillas aparte. El middleware resuelve esa fragmentación actuando como traductor y orquestador entre piezas que nunca fueron pensadas para hablarse. Su trabajo es recibir un dato de un sistema, transformarlo al formato que espera el otro y entregarlo de forma confiable, registrando qué pasó en cada paso.

Un buen middleware no se limita a "copiar y pegar" datos. Suele encargarse de cuatro tareas centrales: mapear campos (que "razon_social" en un sistema sea "Nombre de la cuenta" en el otro), transformar y validar (convertir fechas, normalizar un CUIT, descartar registros incompletos), enrutar (decidir a qué destino va cada mensaje según reglas de negocio) y garantizar la entrega (reintentar si el sistema destino está caído, encolar mensajes y alertar ante fallas).

Cómo funciona en un caso real

Pensá en una distribuidora de Consumo Masivo en Argentina que vende por varios canales. Un pedido entra desde el e-commerce, pero el stock vive en el ERP, la facturación electrónica se emite contra AFIP, el cliente se gestiona en el CRM y el reparto se coordina en un sistema de logística. Sin integración, alguien copia datos a mano entre cinco pantallas, con la demora y los errores que eso implica.

Con un middleware en el medio, el flujo se automatiza: cuando entra el pedido, el middleware toma los datos del e-commerce, valida el stock contra el ERP, crea o actualiza el cliente en el CRM, dispara la factura electrónica y notifica al sistema de reparto. Si el ERP no responde, el middleware reintenta y encola el mensaje en lugar de perderlo. El resultado es un proceso de extremo a extremo sin intervención manual, donde cada sistema sigue siendo el dueño de su parte pero todos comparten la misma información.

Tipos de middleware

No todos los middleware son iguales. Estos son los más comunes en proyectos de negocio:

• iPaaS (plataforma de integración como servicio): middleware en la nube, con conectores prearmados para cientos de aplicaciones. Es la opción más usada hoy para conectar SaaS como Salesforce, sistemas de marketing y ERPs.
• ESB (bus de servicios empresarial): el enfoque clásico on-premise, pensado para integrar muchos sistemas internos a través de un bus central. Potente pero más pesado de mantener.
• Cola de mensajes (message broker): middleware enfocado en transportar mensajes de forma asíncrona y confiable entre sistemas, desacoplando al emisor del receptor.
• Middleware de orquestación / workflow: coordina procesos de varios pasos con lógica condicional, ideal cuando la integración es además un flujo de negocio.

Middleware vs API vs integración punto a punto

La confusión más habitual es pensar que tener APIs ya resuelve la integración. La API es necesaria pero no suficiente: alguien tiene que consumir esas APIs, transformar los datos y manejar los errores, y eso es exactamente el rol del middleware. Esta tabla resume las diferencias:

Errores comunes al implementar middleware

El primero es subestimar el mapeo de datos: la mayor parte del esfuerzo de una integración no está en "conectar" sino en limpiar y conciliar campos entre sistemas con criterios distintos. El segundo es ignorar el manejo de errores y la idempotencia: si un mensaje se reenvía, no debe duplicar un pedido ni una factura. El tercero es no monitorear: un middleware sin tablero de control falla en silencio y nadie se entera hasta que un cliente reclama. Y el cuarto, tratar al middleware como un proyecto "de una vez": cada nuevo sistema o cambio de formato exige mantenimiento continuo.

Bien diseñado, el middleware deja de ser un costo técnico y pasa a ser el sistema nervioso de la operación: la pieza que permite que los datos fluyan en tiempo real entre áreas, evita la doble carga manual y sostiene una única fuente de verdad sobre la que se apoyan ventas, finanzas y logística.