Cuatrocientas líneas de ABAP que no escribiste, en un lenguaje que no depuras, sobre un programa que no has abierto nunca.
Así que haces una captura, se la mandas al de desarrollo, y esperas.
Las cinco líneas de arriba te habrían dicho si esa era la llamada correcta. Y la mayoría de las veces no lo es.
El primer post de esta serie trataba un fallo que no anuncia nada. Este es el problema contrario: un fallo que anuncia tanto que nadie lo lee. El efecto es idéntico —no investigas— y el remedio es un hábito de unos noventa segundos.
Primero: tres cosas distintas que la gente llama «un dump»
Antes de leer nada, establece qué estás mirando de verdad. Se comportan distinto y viven en sitios distintos:
| Qué viste | Qué es | Dónde está el detalle |
|---|---|---|
| Un popup, y al cerrarlo sigues en la misma transacción | Mensaje de error — el programa lo gestionó | El propio mensaje; SE91 para su texto largo |
| Aterrizas en otra pantalla, llena de detalle técnico | Short dump — el programa terminó | ST22 |
| Un popup sin líneas pulsables | Update termination — la tarea de actualización falló después de terminar el diálogo | SM13, no ST22 |
La tercera fila conviene memorizarla. Un update termination es el que se reporta como «guardó y luego no pasó nada», y buscarlo en ST22 es una forma habitual de concluir, equivocadamente, que no hay nada que encontrar.
Las cinco líneas que van antes del ABAP
Abre el dump en ST22 e ignora todo lo que hay debajo de la cabecera. Hay un argumento fuerte de que esas cinco filas son el asunto entero: la propia documentación de troubleshooting de SAP te pide que pegues exactamente esas cinco filas en un incidente para acelerar el análisis. Que una organización de soporte te diga qué líneas quiere es una señal razonable de dónde está la información.
Un apunte práctico antes de empezar a leer: guarda el dump como fichero de texto. Buscar dentro de un fichero de texto le gana a hacer scroll en una pantalla de SAP GUI, y SAP documenta los pasos en la KBA 1896868. Si vas a pasar veinte minutos en un dump, dedica los primeros treinta segundos a esto.
Runtime Errors es un término de búsqueda, no un diagnóstico
La segunda fila es a la que se agarra todo el mundo, porque parece una respuesta. TIME_OUT se lee como una causa. No lo es: es una forma de fallo que aparece en decenas de escenarios sin relación, y buscarla sola devuelve todo y por tanto nada.
Búscala junto a palabras que describan tu proceso. El tipo de dump más el contexto de negocio es la consulta que encuentra una KBA; el tipo de dump a secas es la consulta que desperdicia una hora.
La línea que dice de quién es el problema
Application Component es la cuarta fila, y es la que responde a la pregunta con la que de verdad entraste.
En el ejemplo, SCM-EWM-WOP — Warehouse Order Processing. No es Basis, no es un desarrollo a medida, no es la interfaz. Es un componente dentro de EWM, y uno que se corresponde con un área funcional que conoces: creación de warehouse orders, las reglas que hay detrás, la confirmación de tareas. De pronto este dump no es de otro.
El componente es además lo que decide adónde debe ir un incidente. Un incidente abierto contra el componente equivocado no se rechaza: se encola, espera, y vuelve días después reasignado. La línea estaba ahí desde el principio.
Y cuando el dump no es el objeto que necesitas
A veces el objeto que falla no es toda la historia: encuentras una clase, una tabla o un report que parece responsable y quieres saber qué componente es dueño de ese. Todos los objetos responden igual — busca su paquete, y lee ahí el componente de aplicación:
| Objeto | Ruta |
|---|---|
| Clase | SE24 › Display › Properties › doble clic en el Package |
| Tabla | SE11 › Display › Attributes › doble clic en el Package |
| Report | SE38 › Attributes › doble clic en el Package |
| Transacción | SE93 › Display › doble clic en el Package |
| Mensaje de error | SE91 › clase de mensaje › Attributes › Display › doble clic en el Package |
El mensaje escondido detrás del dump
Baja de la cabecera hasta Contents of System Fields. A menudo hay un mensaje de error debajo del dump, y es mucho más específico que nada de lo que hay arriba.
Busca SY-MSGTY. Si pone E, hay mensaje, y otros dos campos te dicen cuál: SY-MSGID guarda la clase de mensaje y SY-MSGNO el número. En el ejemplo de SAP eso da /SCWM/WM_SEL 001.
Ahora sí tienes algo que merece la pena buscar. Pruébalo en SAP for Me o en la SAP Community, y pruébalo de las dos formas — con y sin espacio entre clase y número, porque los resultados cambian:
«/SCWM/WM_SEL001» — y luego — «/SCWM/WM_SEL 001»
Si no vuelve nada, ve a SE91, introduce clase y número, y lee el texto del mensaje. Un detalle decide si merece la pena seguir: el flag Self-Explanatory. Si está marcado, el texto corto es todo lo que hay. Si no lo está, selecciona la línea del mensaje y pulsa Long Text — ahí vive la explicación, y casi nadie la abre.
Tres transacciones que conviene conocer antes de escalar
ANST— Automated Note Search Tool. Ejecuta tu escenario y busca notas de SAP por ti, a partir del código que se ejecuta de verdad. Si sospechas de un bug, esto encuentra la nota antes que tú. KBA 1818192.ST12— Single Transaction Analysis. Trazas para localizar el código crítico, la causa raíz de un rendimiento malo, o la tabla que creció tanto que sus selects ya no vuelven a tiempo. Nota 755977.- Comparación de versiones en
SE24. Abre la clase, doble clic en el método, y luego Utilities › Versions › Version management, selecciona dos líneas y Compare. Así ves qué cambió una nota de verdad — azul es añadido, blanco es eliminado.
Escribir el incidente que SAP quiere recibir
Si resulta que sí es suyo, hay una KBA que casi nadie encuentra: 2349831 — How to create the perfect incident for EWM (SCM-EWM) component and subcomponents. SAP publica qué quiere de ti.
El mínimo, de esa misma documentación: pega esas cinco filas de la cabecera en el texto del incidente. No una captura del dump. Las cinco filas, como texto, más el componente que determinaste y el escenario de negocio con tus palabras.
Aquí es donde los noventa segundos se pagan solos. Un incidente que abre con el runtime error, el programa, el componente y la marca de tiempo se salta una ida y vuelta entera de «por favor, aporte los detalles del dump».
La forma de este problema
El primer post de esta serie iba de un fallo sin nada que leer. Este va de un fallo con demasiado — y los dos terminan igual, con un consultor decidiendo que no es su problema sin haberlo comprobado.
Un short dump no es un problema de ABAP. Es un mensaje que contiene un problema de ABAP, envuelto en cinco líneas de metadatos en lenguaje llano que cualquiera puede leer. Cuatro de esas líneas te dicen cómo buscar. Una te dice de quién es.
Puede que sigas sin ser la persona que lo arregla. Pero serás la persona que supo, en minuto y medio, quién era.
En el siguiente post de esta serie seguiremos con los fallos que sí se anuncian y cogeremos el más ruidoso de todos: la cola qRFC que no está atascada, sino fallando una y otra vez con la misma entrada — y cómo distinguir un reintento que se resolverá solo de uno que no lo hará nunca.
Lecturas relacionadas
- No hubo error. No falló nada. Tu entrega simplemente nunca llegó. — el fallo contrario: nada que leer, y el documento esperando en una cola que nadie mira.
- Tu regla nunca se ejecutó. Y aquí está quién llegó antes. — otro caso de un solo campo respondiendo en segundos lo que una revisión de configuración responde en una hora.
- SAP EWM movimiento 561: dos caminos hacia el almacén — cuando el fallo no es un dump sino una ausencia, y la pregunta es por qué camino iba la contabilización.
¿Tienes un dump delante ahora mismo?
Dile lo que pone la cabecera y recibe la transacción, la ruta de Customizing 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
Deja un comentario