✒️SAP BASIS / Herramientas de monitoreo de transportes Por Fernando Escola

Herramientas de monitoreo de transportes

Las herramientas de monitoreo

1. Las Herramientas de Monitoreo en el TMS

El Sistema de Gestión de Transportes (TMS) ofrece diversas herramientas para monitorear las actividades dentro de un dominio de transporte. Se accede a ellas principalmente a través de la transacción STMS, y se dividen según la vista seleccionada:

Monitoreo desde la Vista General de Sistemas

Para acceder, se debe seguir la ruta Menú → Overview → Systems (Vista General → Sistemas) y seleccionar uno o varios sistemas SAP. Las verificaciones disponibles son:

• Verificación de Conexión RFC (RFC connection test): Sirve para verificar los destinos RFC en ambas direcciones para todos los sistemas o para uno solo dentro del dominio. Se ejecuta mediante SAP System → Check → Connection Test.

• Verificación del Directorio de Transporte (Transport directory check): Valida la disponibilidad de los directorios de transporte a nivel general o individual. Se accede mediante SAP System → Check Directory → Transport Directory.

• Verificación del Programa de Control de Transportes (Transport control program check): Sirve para verificar el programa de control tp para todo el dominio o para un sistema específico. Se ejecuta en SAP System → Check → Transport Tool.

Monitoreo desde la Vista General de Importaciones

Para acceder, se sigue la ruta Menú → Overview → Imports (Vista General → Importaciones) y se hace doble clic en el sistema deseado:

• Historial de Importación (Import history): Muestra el histórico de importaciones mediante la ruta Goto → Import History. Esta información se recopila a partir del archivo de log ALOG y se almacena en las tablas TPALOG y TPALOGHDR. Para problemas de historial incompleto, se menciona la Nota SAP 375230.

• Monitor de Importación (Import monitor): El programa tp almacena información de estado en la base de datos antes y después de cada paso de importación. El monitor lee y muestra este estado a través de Goto → Import Monitor.

• Verificación de Consistencia de la Cola de Importación (Import queue consistency check): Verifica si los archivos de datos (data files) y los cofiles de las órdenes de transporte en una cola existen en los buffers del directorio y pueden ser leídos. Se accede mediante Queue → Check → Consistency.

2. Transacción /SDF/TRCHECK

La transacción /SDF/TRCHECK (o el reporte /SDF/CMO_TR_CHECK) entrega verificaciones proactivas para los objetos dentro de las órdenes de transporte, con el objetivo de predecir errores relacionados con el transporte antes de que las órdenes sean importadas al sistema destino. Estas verificaciones se entregan mediante el Plugin ST-PI (asociado a la Nota SAP 2475591).

Casos de Uso Típicos

1. Desarrolladores: Verifican su orden de transporte en el sistema de desarrollo antes de liberarla e importarla al sistema de pruebas.

2. Gerente de Transportes: Verifica un grupo de órdenes de transporte en un sistema de pruebas antes de que se importen a los entornos de pre-producción o producción.

Verificaciones Disponibles

• Referencia Cruzada (Cross Reference): Identifica los objetos referenciados en las órdenes mediante un análisis de dónde se usan (where-used-analysis). Si un objeto referenciado no está incluido en la orden, el sistema compara sus versiones entre el sistema de referencia y el destino. Si difieren o el objeto no existe en el destino, se resalta como un error potencial. Funciona para repositorio ABAP, diccionario de datos, objetos de Customizing, Notas SAP y objetos BW.

• Verificación de Secuencia (Sequence Check): Identifica otras órdenes de transporte con objetos idénticos que fueron liberadas en el periodo de análisis, pero que aún no se han importado al sistema destino.

• Verificación de Cross Release (Cross Release Check): Si el sistema actual y el de destino están en diferentes niveles de Support Package, identifica objetos críticos en la orden que pertenecen a componentes de software inconsistentes y que no deberían importarse (por ejemplo, Notas SAP). Para objetos de Customizing, compara si la estructura de la tabla difiere entre ambos sistemas.

• Tiempo de Importación en el Sistema Fuente (Import Time in Source System): Suma el tiempo de importación de las órdenes seleccionadas en el sistema fuente (el cual debe ser un sistema de pruebas donde dichas órdenes ya hayan sido importadas).

• Criticidad de Importación en Línea (Online Import Criticality): Estima la criticidad de una importación cuando los usuarios finales están trabajando en el sistema de producción.

Requisitos Previos para su Funcionamiento

Para que el reporte identifique los objetos dependientes y verifique el perfil de uso de todos los objetos, se requiere:

1. Recopilar las estadísticas de llamadas a tablas y de ejecución de reportes en el sistema de producción durante una semana.

2. Activar la recopilación de estadísticas de uso en producción mediante el reporte /SDF/OI_ADMIN.

3. Activar el Registro de Uso y Procedimiento (UPL) en el sistema de producción.

Resultados del Reporte de Perfil de Uso

• Para Tablas: La salida muestra el número de lecturas por hora, escrituras por hora y el tamaño de la tabla en KB.

• Para Reports: La salida muestra el número de pasos de ejecución del reporte por hora, basándose en los datos de UPL.

• Objetos Críticos: Es posible mantener una lista de objetos críticos respecto a la importación en línea en la tabla /SDF/OI_CRITOBJ del sistema de producción, los cuales también se visualizarán en el resultado.

El chequeo de los objetos críticos

El sistema permite verificar la presencia de objetos críticos en las órdenes de transporte para evitar impactos negativos en el entorno de destino. Existen dos opciones principales para realizar esta verificación:

Opciones de Verificación

• Antes de la Importación al Sistema Destino (Manual): Consiste en una visualización manual de la lista de órdenes de transporte que contienen objetos críticos dentro de la cola de importación.

• Durante la Liberación de la Orden de Transporte (Automática): Esta opción se ejecuta de forma automática al momento de exportar desde la transacción SE09. Para ello, se requiere que el parámetro de tp llamado CHK_CRIOBJ_AT_EXPORT esté configurado con el valor 'W' (warning / advertencia) o 'E' (error / error).

Procedimientos de Verificación y Mantenimiento Cómo Verificar Objetos Críticos en la Cola de Importación

Para comprobar si las órdenes acumuladas en una cola contienen elementos que no deberían importarse directamente, se utiliza la transacción STMS:

1. Ir a la Vista General de Importaciones (Menú → Overview → Imports).

2. Hacer doble clic en el sistema en cuestión.

3. En el menú, seleccionar la ruta: Queue → Check → Critical Objects (Cola → Verificar → Objetos Críticos).

El resultado se presenta en una lista jerárquica. Las órdenes de transporte que incluyen objetos críticos se marcan con un icono apropiado y los objetos en sí se resaltan con color.

Verificación en la Lista de Trabajo de QA (QA Worklist)

Esta función es clave para apoyar las decisiones de aprobar o rechazar órdenes de transporte en el flujo de asegurar la calidad:

1. Acceder a la Lista de Trabajo de QA.

2. Seleccionar la ruta de menú: Worklist → Check → Critical Objects (Lista de Trabajo → Verificar → Objetos Críticos).

3. Confirmar la ventana de diálogo si el sistema lo solicita.

Como resultado, aparece una vista general de las órdenes con objetos críticos. Si se prefiere, es posible filtrar la visualización previamente para analizar solo ciertas órdenes de transporte específicas.

Mantenimiento de Objetos Críticos

Antes de poder realizar cualquier validación, es obligatorio haber definido y mantenido qué elementos se clasifican como críticos.

• Ubicación: Este mantenimiento debe realizarse iniciando sesión específicamente en el sistema controlador del dominio de transporte.

• Distribución: Al guardar los cambios en el sistema controlador, la información sobre los objetos críticos se distribuye automáticamente a todo el dominio de transporte.

• Ruta de acceso en STMS: En el sistema controlador, se debe ir a Overview → Imports (Vista General → Importaciones) y luego seguir la ruta de menú Extras → Critical Transport Objects (Extras → Objetos de Transporte Críticos).

Estructura Técnica y Ejemplos de Objetos Críticos Comportamiento de Objetos y Subobjetos (LIMU vs R3TR)

• Objetos Principales: Solo aquellos objetos que poseen el formato Tipo de Objeto = R3TR se verifican directamente como objetos de transporte principales.

• Subobjetos (LIMU): Los objetos de transporte que comienzan con LIMU son subobjetos de un objeto de repositorio (el cual ya posee una entrada en el directorio de objetos).

• Procedimiento para subobjetos: Para poder verificar subobjetos LIMU, el administrador debe determinar primero la entrada del directorio de objetos correspondiente al objeto principal R3TR, e ingresar dicha entrada principal en la tabla de objetos críticos.

Ejemplos Comunes de Objetos Críticos

Algunos de los componentes más habituales que se clasifican bajo este filtro por su criticidad para el negocio son:

• R3TR XPRA (XPRAs): Programas que se ejecutan de manera automática e inmediata después de finalizar la importación.

• R3TR TABL (Definiciones de tabla): Modificaciones directas a las estructuras físicas de las tablas, las cuales pueden alterar el diccionario de datos.

• R3TR TABU (Contenido de tabla): Específicamente el contenido de tablas clave, datos maestros o configuraciones que resulten altamente interesantes o sensibles para la operación del negocio.

El congelamiento de los desarrollos y las pruebas

Para garantizar un entorno de desarrollo y pruebas que sea completamente estable, se utiliza un plazo límite de desarrollo (development deadline). Su propósito es congelar el trabajo sobre los objetos en el sistema de desarrollo (DEV) hasta que finalice por completo la verificación y el testeo en el sistema de control de calidad (QAS).

Procedimiento Estándar de Desarrollo y Pruebas

El ciclo de vida recomendado para el desarrollo y las pruebas de objetos sigue estos pasos secuenciales:

1. Liberar las órdenes de transporte que contienen los objetos ya desarrollados en DEV.

2. Congelar el desarrollo posterior de esos mismos objetos en el sistema de desarrollo.

3. Importar los objetos y verificar exhaustivamente los cambios en el entorno de control de calidad (QAS).

4. Dar la aprobación (sign off) a los cambios una vez que las pruebas sean exitosas.

5. Si es necesario y solo tras la aprobación, permitir nuevamente el desarrollo posterior de los objetos en el sistema de desarrollo.

Herramientas de Administración para Forzar la Congelación

Un administrador del sistema puede forzar la congelación de código para un entorno SAP utilizando herramientas específicas a nivel de sistema operativo. Existen dos comandos u opciones principales para lograr este bloqueo técnico:

• Detener Exportaciones: Consiste en crear un archivo vacío o con texto llamado T_OFF. (según el gráfico) o simplemente T_OFF en el directorio de transporte /usr/sap/trans/bin/. Cuando un usuario intente liberar una orden de transporte desde el Organizador de Transportes, el sistema detendrá el proceso y mostrará como mensaje la primera línea de texto contenida en este archivo.

• Detener Importaciones: Consiste en crear un archivo llamado NOIMPORT. (según el gráfico) o NOIMPORT en el directorio de transporte /usr/sap/trans/tmp/. A diferencia del anterior, el contenido de este archivo no es evaluado por el sistema; su sola presencia bloquea la importación de órdenes.

Impacto de los Ciclos de Corrección de Errores

Cuando un objeto presenta fallas en QAS y pasa por un ciclo de corrección de errores, terminará incluido en al menos dos órdenes de transporte diferentes dentro de la cola de importación del sistema de producción (PRD): la orden de transporte original y la orden de transporte que contiene la corrección (fix).

Comportamiento de la Importación Masiva

Si se decide importar la cola de importación completa en el sistema de producción utilizando la opción Import all requests después de haber otorgado la aprobación general, el objeto defectuoso de la orden de transporte original no tendrá un impacto negativo en el entorno productivo. Esto se debe a que la versión corregida (el fix) se encuentra más adelante en la cola y se importará después, sobrescribiendo y subsanando el error de forma automática durante el mismo proceso.

Estrategia de Transporte Recomendada por SAP

SAP aconseja como buena práctica transportar todas las órdenes de transporte de un proyecto CTS (Change and Transport System) completo juntas en un único paso. Esto debe hacerse una vez que todos los objetos involucrados se encuentren en un estado aceptable y aprobado, evitando explícitamente la práctica de transportar cada objeto de manera individual tan pronto como esté listo.

La nomenclatura del directorio de transporte

Debido a que el programa de control de transportes tp se ejecuta en muchos sistemas operativos diferentes, se requieren convenciones de nombres restrictivas. Las órdenes de transporte siempre se representan con la siguiente estructura fija de 10 caracteres: las siglas SID de origen, seguidas de la letra K, el número 9 y finalmente 5 dígitos o caracteres.

Desglose del Formato de la Orden

• SID de origen: Indica el identificador del sistema SAP en el que se creó originalmente la orden de transporte.

• K9: La letra K seguida del número 9 indica que se trata de una orden de transporte de cliente (customer transport request).

• Los cinco dígitos finales: Forman un número de serie correlativo, el cual puede llegar a expandirse utilizando caracteres.

Ejemplo práctico del gráfico: La orden de transporte DEVK900827 indica que se originó en el sistema DEV. Contiene los programas del usuario llamado CATON, fue liberada desde el ambiente de desarrollo e importada al ambiente de QAS.

Subdirectorios Esenciales del Directorio de Transporte

El directorio de transporte general está compuesto por varios subdirectorios críticos. A continuación se detalla el contenido y la función específica de cada uno de ellos:

• actlog (Action Log): Contiene los archivos de log de las tareas y de las órdenes de transporte en sí. Se genera un archivo individual por cada orden de transporte y por cada tarea para la que se hayan ejecutado acciones. Este archivo se actualiza automáticamente cuando ocurre un nuevo evento, como la creación o la liberación de una orden.

• bin: Almacena de forma exclusiva los archivos de configuración globales para todo el dominio de transporte.

• buffer: Contiene un archivo de buffer de transporte específico para cada sistema SAP (nombrado con el SID correspondiente). Al liberarse una orden de transporte, el archivo de buffer del sistema de destino se actualiza para incluirla en la cola.

• cofiles (Command Files): Guarda los archivos de comando, los cuales se nombran bajo la estructura de la letra K seguida de los 5 dígitos de la orden y la extensión del SID de origen (por ejemplo: K900827.DEV). Estos archivos contienen información técnica de control, como la lista de los pasos de importación que ya fueron ejecutados.

• data: Almacena los archivos de datos exportados reales que contienen los objetos físicos transportados. Su nomenclatura utiliza la letra R seguida de los 5 dígitos de la orden y la extensión del SID de origen (por ejemplo: R900827.DEV).

• log: Contiene todos los archivos de log definitivos del sistema de transporte, tales como los archivos ULOGs, ALOGs y SLOGs, además de los logs específicos de las órdenes finalizadas en los distintos ambientes (como por ejemplo DEVK900827.DEV o DEVK900827.QAS).

• sapnames: Guarda archivos nombrados exactamente igual al nombre de inicio de sesión de los usuarios (utilizando caracteres estándar). Se crea un archivo para cada usuario del sistema SAP que trabaja con el CTS, y se actualiza al liberar una orden. En el caso de órdenes relacionadas con reparaciones, también se genera un archivo para el propietario de los objetos reparados (para mayor información, remite a la Nota SAP 2379949).

• tmp: Funciona como un área de almacenamiento temporal para los archivos de log antes de que sean movidos de forma definitiva al directorio principal log.

• EPS (Electronic Parcel Service): Este subdirectorio contiene elementos externos al flujo habitual, incluyendo de forma obligatoria el subdirectorio in y, de manera opcional, el subdirectorio download. Su función principal es servir de destino para copiar los Paquetes de Soporte SAP (SAP Support Packages) antes de ser aplicados formalmente en el sistema mediante el SAP Support Package Manager (transacción SPAM).

Los pasos para la resolución de problemas

Durante el proceso de importación, las herramientas como R3trans y los jobs de fondo (identificados con el patrón RDD*) interactúan escribiendo inicialmente logs en el subdirectorio temporal tmp. Una vez completado el paso de transporte, el programa de control tp mueve de forma definitiva estos archivos al subdirectorio log, generando registros globales como ULOG, SLOG y ALOG.

Los archivos de log individuales de las acciones de transporte se nombran bajo la estructura fija: siglas del SID de origen, seguidas de un carácter que representa la acción, el número 9, 5 dígitos provenientes de la orden de transporte correspondiente y, finalmente, el SID de destino como extensión (por ejemplo: DEVH900827.QAS).

Niveles de Detalle del Log

Al expandir la visualización de un archivo de log dentro de SAP, el administrador puede seleccionar cuatro niveles de detalle distintos:

• Acciones realizadas y código de retorno (Performed actions and return code).

• Mensajes de error adicionales (Additional error messages).

• Logs para el usuario final (End-user logs).

• Detalles para desarrolladores y hotline (Details for developers and hotline).

Monitoreo y Análisis: Archivos de Logs de tp

Para importaciones de larga duración, es fundamental monitorear los tres archivos de log principales que se almacenan en el directorio de transporte común:

• ULOG (User Log): Registra todos los comandos tp ejecutados que están libres de errores de sintaxis. Se nombra bajo la convención ulog{YY}_{Q}, donde YY representa el año y Q el trimestre del año. Cada línea en este archivo equivale a un comando tp.

• SLOG (System Log): Se utiliza para monitorear las actividades de transporte de un Servidor de Aplicación ABAP específico. Ofrece una vista general de los transportes realizados indicando explícitamente el código de retorno y el éxito de cada operación. Se puede configurar mediante el parámetro global SYSLOG y su nombre predeterminado es SLOG{YY}{WW}.{SID}, donde WW indica la semana del calendario.

• ALOG (All Log): Registra el código de retorno para todos los pasos de transporte gestionados en el directorio de transporte común. Se puede configurar mediante el parámetro global ALLLOG y adopta el nombre predeterminado ALOG{YY}{WW}.{SID}.

Códigos de Retorno de tp (rc)

El programa tp recibe e interpreta los códigos de retorno propios y de las herramientas subyacentes involucradas en la importación. El valor numérico del código de retorno se interpreta de la siguiente manera:

• De 0 a 16 (Valor Máximo de Herramientas): Indica el valor máximo de todos los códigos de retorno recibidos de las herramientas de transporte subyacentes. Se desglosa internamente en: 0 para transporte exitoso, 4 para advertencia (warning), 8 para error en un objeto y 16 para error grave en el transporte.

• De 17 a 99 (Advertencia de tp / tp warning): Son valores calculados a partir de los códigos de las herramientas que implican una advertencia propia de tp. Por ejemplo, se genera si el buffer de transporte del sistema destino no tiene permisos de escritura.

• De 100 a 199 (Advertencias de tp debido a fallas): Significa que algo salió mal y tp no pudo realizar todas las tareas.

  • De 100 a 149: Advertencias normales (por ejemplo, si el job RDDIMPDP no pudo dispararse mediante la herramienta sapevt).

  • De 150 a 199: Códigos de retorno poco comunes que indican una operación incorrecta por parte de un usuario. Por ejemplo, el sistema devuelve específicamente un código de retorno 152 si tp intenta importar una orden de transporte que no se encuentra incluida dentro del buffer de transporte.

• 200 o más (Errores de tp): Indica errores críticos propios de tp. Por ejemplo, el código de retorno 212 se genera si no se pudo acceder a un archivo físico requerido por el proceso de importación.

Nota técnica: Para visualizar el texto descriptivo y significativo de un código numérico de retorno específico, se puede ejecutar en consola el comando: tp explainrc <valor_del_código>. El significado global de estos códigos está documentado en la Nota SAP 2878102.

Estrategia para la Resolución de Problemas

Para resolver fallas en los entornos de transporte se establece un flujo ordenado de análisis basado en tres herramientas principales:

1. Monitor de Alertas (Alert Monitor / TMS Alert Viewer): Es el primer paso ante un problema. Registra todas las acciones de transporte del TMS, mostrando fecha, hora, nombre de usuario, el mensaje de estado y el Servidor de Aplicación ABAP de destino. Al hacer doble clic sobre el mensaje se accede al texto completo del error. Permite ver fallas de conexión de tp, problemas de permisos y fallos de las RFCs.

2. Log del Sistema (SLOG): Se revisa en segunda instancia para verificar de manera general todos los códigos de retorno globales e identificar el éxito o fracaso de las órdenes.

3. Log de Acciones (ALOG): Se utiliza para localizar qué orden de transporte o fase genérica produjo el error o la advertencia. A partir de allí, se pasa a revisar los archivos de log individuales a nivel de sistema operativo.

Acceso a Logs No Específicos

Los archivos de log que no dependen de órdenes específicas (como los de conversión de estructuras o movimiento de nametabs) se pueden consultar de dos formas: a nivel de sistema operativo en el directorio de transporte, o desde la transacción STMS seleccionando la orden en la cola de importación, eligiendo Logs y expandiendo la carpeta Import steps not specific to transport request.

Monitoreo de Jobs y Herramientas a Nivel Técnico

Adicionalmente, se debe comprobar que el despachador de importación RDDIMPDP esté correctamente programado (scheduled) y que se esté disparando por eventos (event-triggered).

Monitoreo de Jobs RDD* (Transacción SM37)

Para monitorear los jobs de fondo relacionados a la importación se utiliza la transacción SM37:

1. Introducir RDD* en el campo Job name.

2. Introducir un asterisco * en el campo User name y en el campo Or after event.

Problemas Comunes de Transporte

Las fallas habituales suelen deberse a:

• Versiones incorrectas de los ejecutables tp o R3trans.

• El programa tp no se está ejecutando (en sistemas UNIX se debe verificar en el sistema operativo mediante el comando ps -ef | grep tp).

• Problemas de permisos o de compartición (share problems) con el directorio de transporte común.

• Falta de espacio libre en el disco.

Análisis y Recuperación Avanzada

Al analizar un problema complejo, se deben comparar los logs y las entradas del buffer de transporte con las tablas de la base de datos TRBAT y TRJOB utilizando la transacción SE16. Si es necesario, se debe insertar la orden de transporte o la cabecera (header) en la tabla TRBAT y reiniciar manualmente el job RDDIMPDP.

Problemas de Comunicación y sapevt

Si se detecta un problema de comunicación entre el ejecutable tp y el Servidor de Aplicación ABAP, se debe intentar iniciar la herramienta sapevt a nivel de sistema operativo para disparar el trigger del job RDDIMPDP.

• Consideraciones sobre sapevt: Debido a que sapevt se comunica de manera no autorizada con el message server (servidor de mensajes), es posible que falle si la comunicación segura del message server está activa. Como excepción, cuando sapevt se ejecuta en el servidor de aplicación usando el usuario del sistema operativo propietario del sistema SAP, el parámetro pf={perfil de instancia} también debe ser enviado de forma obligatoria (ver Nota SAP 2000417).