Sin categoría

Estamos seguros de que en alguna ocasión habéis tenido la necesidad de verificar una orden antes de transportarla. O quizá os preguntabais si dicha orden iba a ser transportada correctamente sin  dejar objetos inconsistentes. Hoy os presentamos la herramienta que resuelve todos estos problemas. Una utilidad que anticipa errores antes de realizar un transporte o incluso antes de liberar una orden. Estamos hablando concretamente del report /SDF/CMO_TR_CHECK, utilizable también a través de la transacción /SDF/TRCHECK (ambos incluidos en el componente estándar de SAP ST-PI).

Con este programa es posible predecir errores de transporte antes de llevarlos a cabo. Esto nos permite solucionar más rápidamente la cascada de errores de transporte y dependencias entre ordenes que a veces se genera al pasar entre entornos un desarrollo importante con multitud de transportes. Evitaremos así inconsistencias y disrupciones en la funcionalidad del sistema productivo. O incluso indisponibilidades temporales.

Como requisitos principales indicar que es necesario contar con una RFC correctamente configurada hacia los sistemas origen y destino de la verificación. Además de lo indicado en las notas de 2475591 – Transport Check Report.

Caso práctico, Imaginemos una posible situación de error

Os ponemos un ejemplo muy sencillo pero que servirá para ilustrar la funcionalidad de esta herramienta. Imaginad que creamos un elemento de datos que dejamos en una orden de transporte. Posteriormente creamos una tabla con un campo que utiliza dicho elemento de datos, la activamos y liberamos una segunda orden. A la hora de transferir la tabla al entorno de calidad, si olvidamos pasar la orden con el elemento de datos y transportamos la segunda orden de la tabla, el transporte fallará porque el elemento de datos es desconocido:

Como era de prever, el campo de la tabla no se ha podido activar porque el elemento de datos no se encuentra en el sistema destino:

Este tipo de situaciones, en entornos más complejos y con más objetos y dependencias entre ellos, llega a complicarse mucho.

Manos a la obra

Este error se puede evitar haciendo uso del report /SDF/CMO_TR_CHECK.

Veamos a continuación cómo se utiliza: Nos dirigiremos al sistema de desarrollo. Tras lanzar el programa en la pantalla inicial indicaremos el sistema origen de la orden, el sistema destino, la orden u ordenes que queremos analizar. También tenemos la posibilidad de seleccionar todas las ordenes en la cola de transporte de otro sistema con las opciones Import Queue from System/Client. Indicaremos las clase de chequeos que queremos realizar, en este caso todos:

Los tipos de chequeo disponibles son estos:

• Cross Reference: Analiza que todos los objetos contenidos en las ordenes seleccionadas y sus dependencias se encuentren en los entornos origen y destino. Además de las versiones adecuadas, indicándose la última orden de transporte que los contiene en caso de que no existan. Esta comparación es válida para objetos de repositorio y diccionario ABAP, customizing, notas, objetos BW y vistas CDS. Éstas últimas a partir de versión Basis 7.52. Evitaremos con esta opción los tan molestos y conocidos return codes 8.
• Sequence Check: Esta opción identifica dependencias de secuencia entre transportes que contienen los mismos objetos, subobjetos o claves de parametrización. Muestra un error si dos transportes con los mismos objetos van a ser transportadas en una secuencia incorrecta. O si se va a tratar de importar una orden con un objeto que ya ha sido transportado al sistema destino en una versión más reciente. La comparación se realizará con ordenes de transporte que se han liberado en los últimos 90 días. Si fuese necesario se podría ampliar esta plazo de 90 días en la tabla de customizing /SDF/CMO_TR_CONF.
• Cross Release: Detecta los objetos críticos en las ordenes indicadas en el caso en el que el sistema origen y destino se encuentren en diferente nivel de parches. Si aparecen objetos en esta opción por defecto no deberían ser importados en el sistema destino al pertenecer éstos a componentes inconsistentes. En el caso del customizing se compara si las tablas correspondientes tienen las mismas estructuras. En caso de no ser así aparecerá un error advirtiendo de este problema
• Import Time in Source System: Esta opción muestra el tiempo de import de las ordenes seleccionadas en el sistema origen, generando así una previsión para el tiempo de import en el sistema destino
• Online Import Check: Esta chequeo detecta la criticidad e impacto de un transporte mientras los usuarios finales (o procesos no interactivos como jobs) están trabajando en el sistema destino, normalmente productivo. Para poder hacer un uso veraz de esta característica es necesario actualizar las estadísticas de uso de las tablas y programas involucrados durante al menos una semana. Esta tarea se realiza mediante el report /SDF/OI_ADMIN. Podemos definir los objetos críticos propios haciendo el uso del report /SDF/OI_CRITOBJ, tal y como se indica en el adjunto de la nota 2475591 – Transport Check Report

Resultado

El report finaliza tras comparar ambos sistemas con el siguiente resultado:

Como vemos en la imagen, detecta correctamente que antes de transportar la tabla ZEJEMPLO es necesario transportar el objeto ZEJEMPLO de tipo DTED. Es decir, es un elemento de datos, y además el programa indica que el objeto está únicamente en el sistema origen. En este caso se trata del entorno de desarrollo, y que se encuentra contenido en la orden indicada en el campo Missing Transport.

Los principales estados que nos podemos encontrar en el resultado del report son estos:

• Only in source: los objetos se encuentran únicamente en el sistema origen
• Locked in target system: el objeto se encuentra bloqueado en el sistema destino. Es decir, está siendo tratado o editado
• Other version: se da cuando las versiones de los objetos difieren en los sistemas origen y destino

El resto de chequeos en este ejemplo son correctos:

Midamos ahora el impacto del transporte

Como indicábamos un poquito más arriba, la opción Online Import Check nos permite medir el impacto del transporte en el sistema destino. Para poder comprobar la potencialidad de esta opción, vamos a analizar el transporte de una tabla que modifica la tabla VBAK, que como ya sabéis, tiene un uso intensivo en la mayoría de los sistemas.

Lanzamos de nuevo el report /SDF/CMO_TR_CHECK para esta orden de transporte y vemos en la pestaña Online Import Check el siguiente resumen:

Si hacemos doble-click en el valor del campo Table Reads per Hour nos encontramos con las estadísticas de uso en la tabla por franjas horarias la última semana:

Como podemos ver en la imagen, la franja de las 3 a 4 a.m. del domingo sería la más adecuada para programar el import de la tabla en el entorno productivo.

¿te ha parecido interesante este post? Déjanos tus comentarios aquí 😉

Es posible que en alguna ocasión te hayas visto en la necesidad de traspasar los datos de una tabla entre diferentes mandantes, o incluso entre sistemas que se encuentran aislados sin posibilidad de realizar transportes entre ellos. O que antes de lanzar algún proceso que afecta directamente a una o varias tablas sea necesario realizar un backup de ellas por si fuese necesaria una vuelta atrás, evitando tener que recuperar un backup completo de BBDD (en caso de no contar con un sistema de backup que permita una recuperación granular a nivel de tabla). Si la respuesta es afirmativa continúa leyendo este post donde te enseñamos a exportar e importar tablas con R3load,  seguramente este será de tu interés.

La herramienta R3trans

El ejecutable R3trans, que reside dentro del kernel de SAP, será el programa que nos permitirá realizar el export e import de los datos de la tabla. Habitualmente esta herramienta se suele llamar desde otros programas de actualización/migración, pero en este caso lo utilizaremos para el traspasado de datos para tablas.

Las opciones de llamada al R3trans son las siguientes:

Ficheros de configuración

Para un correcto proceso de export/import necesitaremos configurar los ficheros de control que gobernarán estas tareas. El fichero de export tendrá la siguiente estructura, cuyo objetivo será el de exportar la tabla ZTESTEXPORT en el mandante 000:

export
client = 000
SELECT * from ZTESTEXPORT

El fichero de import debería tener este aspecto para importar el contenido anteriormente exportado en el mandante 100 haciendo uso del contenido del fichero trans.dat generado en el paso anterior, y que contendrá las entradas de la tabla ZTESTEXPORT:

import file = '/usr/sap/trans/trans.dat' client = 100

Como realizar el export/import

Por último veamos cómo funciona todo el proceso en su conjunto, y para ello nada mejor que un ejemplo. Como decíamos más arriba, usaremos la tabla ZTESTEXPORT que únicamente tiene un registro y se encuentra en el mandante 000:

A continuación crearemos el fichero exp.ctl en el directorio /usr/sap/trans por ejemplo, con el contenido del punto anterior, y lanzaremos el siguiente comando desde Sistema Operativo y con el usuario administrador de SAP <sidadm> que exportará los datos:

R3trans -w exp.log exp.ctl

El comando finaliza correctamente, y si nos fijamos encontramos que se han generado en el directorio dos ficheros nuevos, uno de log del export, y otro un fichero .dat con los datos de la tabla:

Si revisamos el contenido del log, vemos todos el resumen de los datos relevantes de la operación:

Ahora realizaremos el import con el fichero de control con el contenido descrito más arriba y con el siguiente comando en Sistema Operativo con el usuario <sidadm>:

R3trans -w imp.log imp.ctl

La ejecución del comando finaliza correctamente aunque con un warning:

Como podemos apreciar en el log se ha actualizado una entrada:

Verificaciones

El último paso será comprobar que la entrada importada es correcta. Para ello iremos al mandante 100 y comprobaremos como en efecto, la entrada exportada ya se ve reflejada en el contenido de la tabla:

Ahora ya sabes como exportar e importar tablas con R3load.

Esperamos que esta entrada te haya servidor de ayuda y si tienes cualquier duda o necesitas ayuda, puedes contactar con nosotros aquí.

Normalmente, cuando necesitamos gestionar una orden de transporte, podemos de una manera sencilla conocer cuál es el usuario propietario de dicha orden, incluyendo las tareas que pueda contener mediante la TX SE01. Incluso podemos conocer cuál es el usuario que ha liberado dicha orden. Para ello, en la SE01, introduciremos el número de orden, pulsaremos el botón de Logs, y en el primer grupo de entradas, que contendrá el SID del sistema en el que se ha generado la orden, pulsaremos sobre el botón del log del export:

posteriormente desplegaremos todo el contenido, y buscaremos la palabra “user”:

Esta entrada nos indicará el usuario que lanzó el proceso de liberación de la orden, tal y como se puede apreciar en la imagen.

¿Qué usuario ha transportado una orden?

Pero vayamos más allá, y al quid de este artículo: ¿te ha pasado en alguna ocasión que necesitabas conocer quién ha sido el usuario que había transportado una orden en concreto a algún sistema?

Pues la solución a este enigma es muy sencilla. Identificar al usuario puede ser especialmente relevante en entornos con un gran volumen de transportes.

Para identificar al autor del import de una orden iremos a la TX STMS_IMPORT, y en ella seleccionaremos la opción Go To → Import History, y configuraremos el intervalo de tiempo que queremos analizar:

Ahora iremos por el menú superior a Edit y pulsaremos sobre la opción Display More, y en la pantalla con todas las ordenes importadas en el intervalo seleccionado se mostrarán nuevas columnas, entre ellas el propietario de la orden y el usuario que las importó:

Ahora sólo bastará con buscar nuestra orden, y ver el resultado:

En este caso concreto, el usuario SAPMiN es tanto el propietario como el usuario que importó la orden, pero estas indicaciones son especialmente útiles cuando necesitamos conocer el usuario que lanzó un import sobre una orden que no era de su propiedad.

En el siguiente ejemplo, que pertenece al import de parches de SPAM, ST-PI y ST-A/PI, vemos que el usuario creador de las ordenes es SAP/SAPUSER, pero que el usuario que realizó el import es otro:

¿te ha parecido interesante esta artículo? Puedes dejarnos tus comentarios aquí.

Estamos seguros de que en alguna ocasión te has visto en la necesidad ejecutar comandos de Sistema Operativo en el host que alberga una instancia SAP, pero por desgracia no tenías acceso para poder hacerlo. En el post de hoy os traemos una pequeña guía para que podáis hacer frente a este tipo de situaciones.

Información importante a tener en cuenta

Es imprescindible tener en mente los siguientes puntos:

• Los comandos se ejecutarán siempre con el usuario <SID>adm de la instancia SAP o SAPService<SID> en el caso de windows.
• Todos los comandos y permisos estarán restringidos a los grupos y permisos concedidos a este usuario, <SID>adm o sapservice<SID>
• En caso de encontrarnos en un sistema SAP con varios servidores de aplicación, los comandos se ejecutarán en el servidor en el que nos hayamos logueado
• Los posibles comandos a ejecutar dependerán de la versión y Sistema Operativo del servidor de aplicación
• Bajo ningún concepto utilicéis estos métodos para hacer el mal 😉

A grandes rasgos, es posible lanzar comandos en el Sistema Operativo de la instancia SAP por dos vías:

Report RSBDCOS0

Este report emula una interfaz de comandos de Sistema Operativo desde SAP. El programa nos presenta una línea editable en amarillo en la que podremos escribir los comandos que requiramos y nos permite ejecutarlos tras pulsar la tecla ENTER.

¿Qué necesitamos?
Para poder ejecutar el report RSBDCOS0 necesitaremos tener acceso a las transacciones SA38/SE38, que las transacciones SM69 y SM49 no estén bloqueadas en el sistema, y los siguientes objetos y valores de autorización como se indica en la nota 2297349

Es importante tener en cuenta que este report no tiene las mismas características que una shell de comandos, y que sus funciones están limitadas. Por ejemplo los comandos interactivos no funcionan correctamente o de la forma habitual, o que simplemente devuelvan un error.

Si lanzamos el report tiene la siguiente forma:

Como se puede ver en el ejemplo de la imagen, hemos lanzado varios comandos en un Sistema Operativo Linux para comprobar el usuario de ejecución, el directorio en el que nos encontramos y el directorio HOME del usuario que lanza los comandos.

A partir de aquí se abre un mundo de posibilidades y comandos y scripts a lanzar, pero como decíamos antes siempre con cautela y conocimiento de lo que estamos ejecutando.

Podemos ver en la transacción SM21 un log de las ejecuciones:

Transacción SM69

En la transacción SM69 podremos ejecutar y definir diferentes comandos lógicos en SAP que lancen su propio comando de Sistema Operativo. Al entrar en la transacción podemos ver que de forma estándar existen unos cuantos comandos definidos:

Es posible ejecutar un comando marcándolo de entre todos en la lista, y pulsando el botón de Ejecutar (tecla F8), copiarlo, renombrarlo, transportarlo a otros entornos, pero la opción más interesante es poder crear nuestros propios comandos.

Pasemos a un ejemplo: vamos a definir el comando ZLISTALLFILES, que ejecutaremos en un S.O. Linux, y que ejecutará el script /home/usuario/scripts.sh. Podemos pasar además parámetros en la llamada y activar el trace en la ejecución del comando. La definición del comando tendría este aspecto:

Una de las características más importantes de los comandos definidos en la TX SM69 es que podemos planificar su ejecución mediante un job, desencadenar su llamada mediante un evento, lanzarlo desde un programa ABAP, etc.

Esperamos que esta información te haya servido de ayuda.

Puedes dejarnos tus comentarios aquí.