Monitorización de telegramas en SAP EWM MFS: reintentos, canales CP, colas bloqueadas y depuración en la práctica

Por qué la «monitorización de telegramas» decide la estabilidad en los proyectos MFS

En SAP EWM MFS, la comunicación de telegramas no es un «detalle de interfaz», sino el pulso operativo entre SAP y el sistema de control subordinado (PLC). Cuando el flujo de materiales se detiene, las posiciones de las HU «saltan» o el rendimiento se desploma, en la práctica la causa muy a menudo no es la lógica de negocio (p. ej., la estrategia de ubicación), sino una anomalía en el estado del canal, el handshake, el reintento, la serialización de colas o el procesamiento de telegramas.

Por ello, la monitorización de telegramas no es una disciplina puramente informática, sino parte de la capacidad operativa: conecta señales técnicas (timeouts, búferes, sincronización de canales) con objetos de negocio (WT/WO/HU) y hace reproducibles los patrones de fallo, requisito para una depuración fiable y un hypercare estable.

Encontrará una clasificación del control de flujo de materiales dentro del stack de automatización en nuestra página de servicios SAP EWM Material Flow Control.

Estructura de la comunicación de telegramas: del flujo TCP/IP al procesamiento MFS

Transporte: TCP/IP, socket/stream y el «canal de comunicación»

SAP EWM MFS se comunica con un PLC mediante TCP/IP y utiliza canales de comunicación («channels») descritos por host/IP y puerto. Lo importante: en este contexto, TCP/IP suele estar orientado a flujo, es decir, no hay límites de mensaje garantizados. Precisamente por eso, en la práctica son tan importantes mecanismos como las longitudes fijas de telegrama, los delimitadores o los campos de longitud en la cabecera.

Nivel de protocolo: telegrama de datos frente a acuse de recibo (handshake)

A nivel de protocolo, MFS distingue entre telegramas de datos (con datos útiles que deben procesarse) y telegramas de acuse de recibo (confirmación o respuesta de aceptación/rechazo a nivel de protocolo). Esta distinción es fundamental para los mecanismos de reintento y para diagnosticar «perdido» frente a «duplicado».

Procesamiento en SAP: recepción, parsing, mapping, acciones posteriores

Para la recepción y el procesamiento de telegramas entrantes, SAP EWM MFS utiliza lógica estándar (p. ej., mediante un módulo de función de recepción) que sitúa el canal/PLC en contexto, formatea los telegramas y transfiere el contenido a una estructura global, de la que después se deriva y se procesa el tipo/estructura del telegrama. Si la cabecera o la estructura no pueden determinarse de forma inequívoca, se producen casos de error que normalmente no aparecen como un «proceso de negocio incorrecto», sino como un error de procesamiento en la ruta de comunicación.

Tipos de telegramas: qué clases hay que distinguir en la monitorización

En proyectos reales, las familias concretas de telegramas varían (según OEM/subsistema). Para la monitorización y la depuración, sin embargo, es esencial una clasificación sólida según el efecto funcional:

Comunicación con el PLC y canales CP: qué significa realmente «sincronización»

Un error frecuente en la operación es: «El canal está up, así que la comunicación funciona». En MFS, el estado del canal es solo una parte. Para un procesamiento estable, los canales deben estar sincronizados. En este contexto, sincronización significa: tras establecerse la conexión, el PLC pudo enviar todos los mensajes acumulados durante la desconexión; el búfer de envío del PLC está vacío y el PLC acusa recibo de cada telegrama enviado antes de que EWM lo contabilice como enviado.

Relevante para la operación:

• Mientras el canal esté sincronizado, EWM envía los telegramas automáticamente.
• Si falta el acuse de recibo, se activa el mecanismo de repetición (reintento).
• Si no se produce ninguna comunicación, EWM inicia una comprobación del canal mediante telegrama life (intervalo configurable).

Procesamiento de colas: por qué una acumulación de telegramas casi siempre es un problema de colas/serialización

Determinación de colas y serialización

MFS utiliza colas para serializar el procesamiento y controlar la responsabilidad (p. ej., de recursos/zonas de la instalación). La lógica de colas influye directamente en si los telegramas se generan y procesan en la secuencia esperada y en si el paralelismo se aprovecha de forma eficaz.

KZSUB/«estado de envío» como palanca de diagnóstico

En la monitorización operativa, una señal clave es si una WT es «relevante para el subsistema» y si ya se ha enviado al subsistema o puede enviarse. Esta lógica de estados suele ser visible en las vistas operativas de MFS y en los proyectos se utiliza también para permitir un reenvío selectivo.

Causas típicas de las colas bloqueadas

• Bloqueo aguas abajo: el PLC/la instalación no acusa recibo o lo hace con lentitud ⇒ la cola crece.
• Falta de paralelismo: cortes de cola demasiado gruesos, todo en una sola serialización.
• Race/out-of-order: flujos concurrentes que están separados lógicamente pero serializados juntos a nivel técnico. (Visible en el diagnóstico por la secuencia de telegramas y el crecimiento del búfer).

Mecanismos de reintento: cómo separar limpiamente «perdido» de «duplicado»

EWM repite automáticamente los telegramas no confirmados tras un intervalo que puede configurarse en el canal.

Esto es técnicamente correcto, pero provoca malentendidos típicos:

• Los «telegramas duplicados» suelen ser reintentos porque un ACK llegó tarde.
• Un sistema robusto debe tratar los reintentos de forma idempotente (la lógica de acuse de recibo debe reconocer: «este ya lo conozco»).
• Una proporción alta de reintentos es un indicador temprano de problemas en la calidad del canal, la carga del PLC o el tiempo de procesamiento en SAP.

Transacciones de monitorización y vista operativa: lo que realmente importa en la sala de control

Punto central: Warehouse Monitor

En la operación de MFS, el Warehouse Monitor se utiliza normalmente como vista central. Allí son relevantes, entre otros, los siguientes objetos de monitorización:

• Estado de los canales de comunicación
• Estado/configuración de los puntos de comunicación
• Telegram Log
• Resumen de las HU en el sistema de transporte
• Tareas de almacén abiertas relevantes para MFS
• Estado de los recursos (p. ej., SRM)
• Búfer de telegramas entrantes/salientes

Transacciones operativas de mantenimiento/análisis de MFS

Para el soporte/hypercare, además de la monitorización se necesita acceso de mantenimiento/análisis a los objetos MFS (p. ej., puntos de comunicación, objetos PLC, canales, recursos, mapping de objetos, limpieza de logs). En proyectos reales esto se cubre mediante roles específicos y transacciones MFS.

Logging: qué hay que registrar (y cómo hacer los logs «aptos para el turno»)

Un telegram log solo tiene valor operativo si pasa de «datos brutos» a «información diagnosticable». En la práctica funciona bien lo siguiente:

• Campos de contexto (p. ej., zona, ID de instalación/subsistema, grupos de CP) en la vista del log
• Representación estructurada de los campos por tipo de telegrama (no todas las líneas son iguales)
• Resaltado en color de los campos relevantes por tipo
• Vista de detalle «Telegram Content View» para una interpretación rápida en la sala de control

El objetivo es claro: un jefe de turno debe poder ver en segundos quién ha enviado, qué se ha enviado, si se ha acusado recibo, qué objeto está afectado y dónde se ha detenido el proceso.

Aspectos de rendimiento: la latencia no es un extra, sino flujo de materiales

En el entorno MFS, los problemas de rendimiento se manifiestan de forma muy directa como:

• procesamiento retrasado de telegramas
• longitudes de cola crecientes
• búferes en aumento
• caída del rendimiento porque la instalación está «esperando a SAP»

Las causas técnicas típicas son:

• paralelismo insuficiente en el procesamiento de telegramas
• lógica lenta de procesamiento de acciones
• ajustes/mapping de proceso MFS poco favorables

Consecuencia para la monitorización: no solo se necesita una «monitorización de errores», sino también una monitorización de KPI (respuesta de telegramas, tasa de reintentos, tendencia de búferes, tendencia de colas).

Patrones de fallo típicos: síntomas → causas → enfoque de depuración

Soporte en el go-live e hypercare: la monitorización operativa como un dispositivo propio

Para los go-lives de MFS se aplica lo siguiente: la estabilidad no viene de «más personas», sino de herramientas operativas claras:

• vistas de monitor preconfiguradas (por zona/instalación)
• valores de alarma/umbral definidos (tasa de reintentos, crecimiento del búfer, sincronización de canales)
• runbooks: «Si X, comprobar Y»
• lógica de escalado clara entre el equipo SAP y el equipo PLC

El hypercare es eficiente cuando las preguntas de depuración más importantes pueden responderse en minutos:

• ¿Es el canal?
• ¿Es el ACK/reintento?
• ¿Es la cola/serialización?
• ¿Es una secuencia de acciones/excepciones de MFS?

Playbook de depuración

Para saber cómo apoyamos el procesamiento de telegramas y las pruebas reproducibles basadas en simulación en SAP EWM MFS, consulte la página Qinlox Toolbox for SAP EWM MFS.