Dos colas, el mismo almacén, la misma mañana. Las dos en rojo en el monitor. Las dos con un texto de error que habla de repetir la unidad de trabajo más tarde.
Una se resolverá sola antes de comer. La otra seguirá ahí en marzo, y cada día alguien la mirará, leerá lo de repetir, y decidirá darle un poco más de tiempo.
La diferencia entre esas dos colas no está en el texto del error. Ni en cuánto llevan esperando, ni en cuántas entradas tienen, ni en qué intentaba hacer la aplicación. Está en una palabra de la columna de estado, y responde a una pregunta que casi nadie se hace:
¿Alguien programó realmente un reintento?
Porque una cola no reintenta por optimismo. Un reintento es un job de fondo, programado por el gestor de qRFC, a partir de un ajuste que alguien hizo en un sitio concreto. Si no se programó ningún job, no va a pasar nada — ni hoy, ni en marzo. La cola no está siendo paciente. Está terminada, y está en rojo, y de lejos las dos cosas se ven igual.
La frase sobre la que se construye este post
Algunos estados de cola significan «el sistema ha pedido otro intento más tarde». Otros significan «el sistema se ha rendido y ha dejado de procesar esta cola». Los dos te enseñan una fila roja y un texto de error. Solo uno de ellos va a alguna parte.
Nadie reintenta nada sin un job
El primer post de esta serie trataba una cola que retenía en silencio un documento que nadie estaba buscando. Este es la situación contraria: todo el mundo la está mirando, y todo el mundo la está leyendo mal.
Cuando una aplicación se encuentra un problema mientras se ejecuta una unidad de trabajo —una LUW, que es como aparece escrito en todos los textos de estado y botones que vas a ver a continuación— no falla y ya está. Le dice al gestor de qRFC qué tipo de problema era, y esa decisión se propaga hasta el estado que ves:
Si la aplicación dice que esto es temporal, el gestor de qRFC programa un job de fondo para otro intento.
Si la aplicación dice que esto es grave, el gestor cancela la unidad de trabajo y no se programa ningún job.
Si es el sistema destino el que lanza un error grave al ejecutar la primera unidad de trabajo, la ejecución se interrumpe, no se programa ningún job de repetición, y la cola deja de procesarse por completo.
Tres desenlaces, tres futuros distintos, y el único sitio donde queda registrada esa distinción es el estado. Léelo como una etiqueta y no aprendes nada. Léelo como una firma —quién decidió, y qué decidió— y responde a la pregunta en unos cuatro segundos.
El estado es una firma
Aquí está todo en una tabla. Busca tu estado a la izquierda; la última columna es si esperar va a servir de algo alguna vez.
Hay dos filas en esa tabla en las que conviene pararse, por motivos opuestos.
SYSFAIL es la que cuesta semanas. Es el estado más habitual en una cola que todo el mundo cree que está reintentando, y significa explícitamente lo contrario: la ejecución se interrumpió, no se programó nada, y la cola se ha parado. Al hacer doble clic en el estado obtienes el texto del error. A menudo el detalle que hay detrás es un short dump en el sistema destino — exactamente la cabecera que el post anterior te enseñó a leer. Cuando en ST22 no hay nada, el detalle está en otro sitio: el propio mensaje en la tabla T100, o el log de aplicación en SLG1, que es el camino que recorre el primer post. Un ST22 vacío no es prueba de que no haya nada que encontrar.
WAITUPDA es la que se resuelve sola mientras todavía estás escribiendo el ticket. La unidad de trabajo está bloqueada hasta que termine una actualización. Si lleva ahí más de un par de minutos, lo que hay que mirar no es la cola: es la petición de actualización en SM13, que es donde vive un update termination.
El error de comunicación que no es un error de comunicación
Esta es la parte del post que justifica el post entero.
CPICERR se lee como un veredicto: se ha producido un error de red o de comunicación durante la transmisión o el procesamiento. Manda tickets a Basis. Abre conversaciones sobre cortafuegos, sobre timeouts de gateway y sobre si el martes pasado cambió algo en la red.
Y a veces no ha pasado nada de eso.
Cuando una aplicación qRFC descubre que una unidad de trabajo no puede seguir procesándose por un problema temporal en la aplicación, llama al módulo de funciones RESTART_OF_BACKGROUNDTASK. Eso hace que el gestor de qRFC cancele la ejecución y la repita más tarde según los ajustes del destino. Y para expresarlo, qRFC simula un error de comunicación.
No informa de uno. Simula uno. Con su texto de estado y todo:
Command to tRFC/qRFC: Execute LUW once again.Esa frase es la pista. No es el sonido de una red cayéndose. Es una aplicación diciendo «ahora no, vuelve a preguntarme luego», disfrazada de error de comunicación porque es la única forma que tiene qRFC de expresarlo.
Puede que te hayas encontrado esa frase antes, bajo otra etiqueta. El primer post de esta serie se la encontró en una cola parada en RETRY. No es una contradicción: el texto te dice que una aplicación pidió otro intento, y nada más. Bajo qué estado llega es lo que te dice cómo registró el gestor de qRFC esa petición, y por tanto bajo qué reglas corre la repetición. El texto es la súplica. El estado es la sentencia.
Qué significa de verdad «si este error ocurre a menudo»
La guía documentada para este caso es contactar con el equipo de la aplicación si pasa con frecuencia — y esa instrucción lleva el diagnóstico dentro. Si un error de comunicación simulado se repite una y otra vez, el problema temporal de la aplicación no es temporal. Hay algo que no está listo de forma recurrente: un bloqueo que siempre está tomado, datos maestros que nunca llegan a tiempo, una dependencia que todavía no se ha creado. El mecanismo de reintento está funcionando perfectamente y tapando un problema de diseño por debajo, un intento cada vez.
Esa cola recurrente es justo la que señalaba el post anterior: no atascada, sino fallando una y otra vez con la misma entrada. Es el fallo ruidoso, y los fallos ruidosos acaban arreglándose, porque alguien se cansa. El que te cuesta un trimestre es su gemelo silencioso — la cola que nunca pidió ninguna repetición, y que lleva ahí desde marzo con exactamente el mismo aspecto.
La consecuencia práctica es una decisión de enrutado, y conviene acertarla a la primera. Un CPICERR genuino es de Basis, y el detalle vive en el syslog y en las trazas RFC. Uno simulado es del equipo funcional dueño de la aplicación, y ninguna cantidad de investigación de red va a encontrar nunca nada — porque no hay nada que encontrar.
Dónde vive de verdad la programación del reintento
Si se programó una repetición, algo decidió cada cuánto y cuántas veces. Esa definición no está en la cola ni en el monitor. Está en el destino RFC:
SM59 → el destino → menú Destino → Opciones tRFC
Esto importa porque «va a reintentar» no es una propiedad del error. Es una propiedad de ese destino, y tiene un final. Una cola en estado de reintento no reintenta para siempre: reintenta según unos valores que alguien puso, posiblemente hace años, posiblemente por defecto, y casi con seguridad nunca revisados.
Ese destino es además lo que resuelve el depende de la fila de CPICERR. Lleva tanto el número de intentos como un flag que suprime el job de fondo cuando se produce un error de conexión. Con ese flag puesto, un error de comunicación no programa absolutamente nada — y la cola que parece estar esperando a la red no está esperando a nadie.
Antes de decirle a nadie cuánto tiene que esperar, ve y lee esos valores. Convierte «dale un rato más» en un número real, y es la diferencia entre dar un estado y dar una suposición.
Dos niveles, una sola luz roja
Hay un segundo fallo que desde donde tú estás se ve exactamente igual que el primero, y no es la cola.
La cola es un objeto. El planificador que procesa las colas es otro. Las colas de entrada las mueve el planificador QIN y las de salida el QOUT, y esos planificadores tienen sus propios estados — incluido su propio SYSFAIL y sus propios errores de comunicación, completamente independientes de cualquier cola individual.
La distinción cambia lo que hay que mirar:
Un detalle que conviene llevarse: una vez resuelto un problema del planificador, el planificador de salida no rearranca automáticamente las unidades de trabajo del destino registrado. Las colas que se quedaron en SYSFAIL hay que resetearlas a mano. Así que un planificador arreglado y una cola todavía en rojo es un estado normal, no una señal de que el arreglo no funcionó.
La referencia de qué significa cada estado en los dos monitores es la nota SAP 378903. Para el planificador de entrada en concreto, la nota SAP 1579728. Merece la pena tener las dos abiertas la primera vez que haces esto.
Donde los equipos se queman
Existe un informe que resetea el estado de las colas en error de comunicación, reintento y fallo de sistema, y rearranca el planificador de salida. Funciona. Deja el monitor limpio. Y como funciona, alguien acaba programándolo todas las noches para que las colas amanezcan siempre limpias. SAP dice explícitamente que es para casos excepcionales y que no debe programarse de forma regular, y la razón no es que sea frágil: es que todos los errores graves que el mecanismo estaba diseñado para sacar a la luz se resetean en silencio antes de que nadie los lea. El monitor se pone verde y se queda verde, y el fallo de fondo corre durante meses.
Cuando de verdad necesitas verlo ocurrir
A veces el texto de estado no basta y necesitas estar dentro de la unidad de trabajo mientras se ejecuta. Hay una forma soportada de hacerlo, y es un parámetro de usuario en vez de una transacción — se pone en Perfil de usuario → Datos propios:
Fíjate en qué dirección funciona esto: el parámetro va en un sistema y la cola se para en el otro.
El detalle que te cuesta una tarde
Si pones el parámetro en el lado de ERP, el qRFC queda sin procesar en el lado de EWM. Es el comportamiento documentado, no un fallo — pero si se te olvida que dejaste el flag puesto, acabas de crear exactamente el síntoma que estabas investigando, y te lo vas a volver a encontrar mañana sin recordar que lo provocaste tú. Ponlo a propósito, y quítalo a propósito.
El orden en que hacer esto
El método entero, para cuando alguien te pare con un «la cola está atascada»:
1. Lee el estado, no el texto del error. El texto te dice qué pasó. El estado te dice si va a pasar algo a continuación.
2. ¿Hay siquiera un job de reintento programado? SYSFAIL y ANORETRY significan que no. Deja de esperar inmediatamente.
3. Si pone CPICERR, lee el texto de estado. Si pide ejecutar la unidad de trabajo una vez más, esto es la aplicación, no la red. Enrútalo en consecuencia.
4. Si hay una repetición programada, ve a leer el destino. Los intentos y el intervalo viven en las opciones tRFC, y se acaban.
5. Si está todo en rojo a la vez, mira el planificador, no las colas.
6. Solo entonces resetees nada — y de una cola en una, nunca en bloque.
Y si SMQ1 y SMQ2 no son tuyas para tocarlas, casi todo esto es alcanzable desde el nodo de colas de mensajes del monitor de gestión de almacenes, /SCWM/MON — las mismas colas, los mismos estados, y una función de resetear estado, sin rol de Basis.
Los pasos 1 y 3 resuelven la mayoría. El valor no está en que sean ingeniosos; está en que ocurren antes de que alguien se haya pasado un día en el sistema equivocado.
La forma de este problema
El primer post iba de una ausencia: nada que leer, y un documento esperando donde nadie mira. El segundo iba de ruido: cuatrocientas líneas de él, y cinco que importaban.
Este es una tercera forma, y la más cara de las tres, porque no parece un fallo en absoluto. Parece progreso. Una cola que dice que lo volverá a intentar es una cola que parece estar gestionándose sola, y la reacción natural ante algo que se gestiona solo es dejarlo en paz.
Así que el hábito es pequeño y ligeramente a contracorriente: cuando una cola te diga que va a reintentar, comprueba que alguien lo programó. La mayoría de las veces sí. Las veces que no son las que te cuestan un trimestre.
Lo siguiente en esta serie: el estado que no es un fallo en absoluto. STOP no significa que algo se haya roto — significa que alguien, o algo, bloqueó la cola a propósito, y el bloqueo sobrevivió al motivo que lo puso. Veremos de dónde salen esos bloqueos, por qué una sesión de depuración abandonada deja uno detrás, y cómo distinguir una cola en la que alguien está trabajando de una que todo el mundo olvidó.
Lecturas relacionadas
- No hubo error. No falló nada. Tu entrega simplemente nunca llegó. — las mismas colas, leídas para otra pregunta: qué documento está atrapado ahí dentro, y dónde vive de verdad el texto del error.
- ¿Quién tiene realmente la cantidad de stock: EWM o ERP? — qué llevan estas colas entre los dos sistemas, y qué lado manda sobre el número cuando no coinciden.
- SAP EWM movimiento 561: dos caminos hacia el almacén — una contabilización que puede llegar por dos rutas distintas, y la fila de mapeo cuya ausencia la para sin ningún error.
¿Tienes una cola en rojo delante ahora mismo?
Dile el estado y el texto del error, y recibe si hay algo programado, dónde viven los ajustes de reintento y el artículo del que sale — respondido como lo respondería un arquitecto de almacén.
Preguntar al asistente EWM →Cuenta gratuita · 20 preguntas al día · sin tarjeta
Parte de la serie Troubleshooting
Siguiente →
La cola que nadie desbloqueó (próximamente)
Deja un comentario