Entre el lector y el ERP hay una capa que nadie quiere asumir: el middleware. Recibe miles de eventos de lectura por minuto, la mayoría duplicados, y debe producir unos pocos hechos de negocio que finanzas y operaciones puedan defender.

Si la arquitectura está mal, los síntomas parecen fallos de hardware: movimientos de stock duplicados, cantidades obsoletas, eventos desordenados o un pórtico que funciona hasta que la red parpadea.

¿Qué debe hacer realmente el middleware?

Cinco trabajos, y solo el primero tiene que ver con hablar con lectores.

Abstracción de dispositivos: gestionar lectores, antenas, potencia, sesiones y firmware entre fabricantes.
Normalización de eventos: convertir lecturas propietarias en un esquema único con lector, antena, marca de tiempo, RSSI y EPC.
Filtrado y deduplicación: colapsar lecturas repetidas del mismo tag en la misma zona en un evento lógico.
Enriquecimiento de negocio: añadir ubicación, dirección, pedido o contexto de palé.
Entrega fiable: almacenar, reintentar y reproducir para que el ERP nunca vea una imagen parcial.

Todo lo que no sea uno de estos cinco es lógica de negocio y pertenece a la capa de aplicación.

¿Cuáles son las cuatro capas?

Un reparto viable es capa de dispositivo, capa de borde, capa de negocio y capa de integración. Los nombres importan menos que las fronteras.

Dispositivo: LLRP o SDK del fabricante, configuración, inventario de antenas, estado de firmware.
Borde: se ejecuta en sitio, almacena localmente, aplica reglas de zona, sobrevive a la caída de red.
Negocio: ventanas de deduplicación, lógica de sesión, inferencia de dirección, reglas de excepción.
Integración: adaptadores ERP/WMS, APIs idempotentes, tablas de mapeo, registro de auditoría.

El error arquitectónico más común es poner la deduplicación en la capa de integración. Así corre después del búfer, y una reproducción duplica documentos de negocio.

¿Dónde ayuda LLRP y dónde estorba?

LLRP es un protocolo estándar de configuración y reporte de tags, y es la abstracción correcta con varios fabricantes de lectores: un driver, un modelo de datos, una ruta de configuración.

No es una respuesta universal. Algunas funciones del fabricante —conmutación avanzada de antenas, filtrado en el lector, datos de tag personalizados— solo se exponen por SDK propietario. Un diseño híbrido es normal: LLRP para el 80 % estándar y SDK para el 20 % específico, tras la misma interfaz interna.

Usa LLRP para configuración, control de inventario y reportes estándar.
Usa SDK del fabricante para lo que LLRP no puede expresar.
Nunca dejes que el SDK se filtre a la capa de negocio: envuélvelo.

¿Cómo deben funcionar el búfer y la operación offline?

Las redes fallan. Un pórtico que pierde conexión 30 segundos no puede perder 500 lecturas.

La capa de borde necesita una cola local con almacenamiento persistente, capacidad para al menos un turno y un comportamiento definido al llenarse: descartar lo más antiguo, lo más nuevo o bloquear la línea. Bloquear una línea de producción suele ser inaceptable, así que defínelo explícitamente.

Cola local persistente, cifrada en reposo.
Plan de capacidad: lecturas pico por hora × horas de autonomía.
Política de desbordamiento documentada y probada.
Reproducción con claves de idempotencia.

¿Qué reglas de filtrado y deduplicación se usan?

Tres reglas cubren la mayoría de los despliegues y deben ser configurables, no codificadas.

Deduplicación por ventana temporal: el mismo EPC en la misma zona dentro de N segundos cuenta una vez. Deduplicación direccional: un EPC visto en antena de entrada y luego en la de salida dentro de una ventana se convierte en un movimiento, no en dos lecturas. Supresión por estado: si el ERP ya tiene el artículo en la ubicación destino, la lectura no hace nada.

La ventana depende del proceso: 2–5 s en pórtico, 30–60 s en barrido de estantería.
La inferencia de dirección necesita RSSI por antena o secuencia, no solo marcas de tiempo.
Registra los eventos suprimidos para auditoría; no los descartes en silencio.

¿Qué monitorización necesita?

El middleware es donde puedes ver la verdad pronto, así que instrumenta.

Sigue la tasa por antena, la latencia de lectura a commit en el ERP, la profundidad de cola, los reintentos y la ratio de supresión. Alerta sobre tendencias, no solo sobre fallos: una cola que crece lentamente es un disco muriendo o un atasco creciendo, meses antes de una caída.

Tasa y nulos por antena en el tiempo.
Latencia extremo a extremo p95, no media.
Profundidad de cola y número de reproducciones.
Deriva de firmware y configuración entre lectores.

Conclusión

El middleware existe para convertir ruido en hechos: abstraer dispositivos, normalizar eventos, filtrar y deduplicar, enriquecer y entregar con fiabilidad. Pon la deduplicación antes del búfer, encierra el código del fabricante tras una interfaz, define el comportamiento offline antes de que la red te pruebe e instrumenta la capa para ver la degradación cuando aún es barata de arreglar.