Sin categoría

¿Qué usuario ha transportado una orden?

¿Qué usuario ha transportado una orden? 495 495 SAPMiN

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:

Log overview

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:

Import history

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ó:

Import history, detalle

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

busqueda

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:

Reultado

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

ComandoCalEnSAP

Cómo ejecutar comandos de Sistema Operativo desde SAP

Cómo ejecutar comandos de Sistema Operativo desde SAP 709 410 SAPMiN

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

Permisos

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:

Ejecucion

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:

SM69

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:

ComandoExternoSM69

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í.

¿Cómo comparar las diferencias de Workbench y Customizing de dos entornos SAP?

¿Cómo comparar las diferencias de Workbench y Customizing de dos entornos SAP? 1872 1012 SAPMiN

Es bastante frecuente encontrarnos la situación en la que los entornos de desarrollo y producción están muy desalineados en cuanto a Workbench y/o Customizing se refiere.

Se trata de un estado potencialmente peligroso, dado que estas diferencias de configuración y repositorio podrían causar que un transporte desde desarrollo pudiera dejar inconsistente un sistema productivo al traspasar cambios obsoletos o no consistentes con la configuración del sistema de explotación en ese momento.

Para poder identificar todas las diferencias entre dos entornos os presentamos las 3 herramientas más útiles y habituales.

TX SREPO – Comparación de objetos de repositorio

Mediante esta transacción podremos seleccionar los objetos de repositorio que queremos comparar entre dos entornos. Primero deberemos indicar la RFC que (deberá ser previamente configurada) que apunte al segundo sistema con el que queremos hacer la comparativa, y posteriormente indicar los objetos o componentes que queremos comparar:

Entre los criterios de comparación podemos encontrar los siguientes elementos:

  • paquetes
  • namespaces
  • objetos de un usuario concreto
  • objetos de un componente de aplicación
  • objetos seleccionados libremente

y especialmente interesantes estas dos últimas opciones:

  • todos los objetos no estándar (objetos Z e Y)
  • todos los objetos estándar modificados

Una vez finalizada la comparación podremos analizar los resultados, que se almacenarán en un histórico para posibles revisiones futuras:

Como se puede ver en la imagen anterior, en el análisis se han detectado dos objetos estándar que se encuentran en un estado diferente en ambos sistemas y deberán ser revisados.

Si pulsamos en una entrada concreta, aparecerá el detalle de las diferencias.

TX SCU0 – Comparación de Customizing

De forma muy similar a la comparativa de los objetos de Workbench encontramos la herramienta SCU0 para la parte de Customizing. Al entrar en esta transacción nos encontramos los diferentes criterios de selección para llevar a cabo la comprobación:

Es posible seleccionar todo el customizing, unas áreas concretas de éste, etc. Lanzamos por ejemplo una comparativa para todo el Customizing y analizamos los resultados:

El proceso nos devuelve cada uno de los objetos cuyas entradas son diferentes.

Al igual que en el caso del Workbench, podemos seleccionar cada objeto con entradas distintas e ir a la parte de parametrización correspondiente para poder analizarlo pulsando el botón Img Environment:

En la parte inferior de la transacción podremos seleccionar los resultados de ejecuciones anteriores y revisar dichos resultados:

TX SCMP – Comparación de entradas en tablas

Por último, podemos comparar el contenido de las tablas y vistas que necesitemos y que sospechemos que puedan tener diferencias significativas. Para ello en la transacción SCMP introduciremos la tabla o vista a comparar, la RFC al segundo sistema a comprar y varios flags de opciones como visualizar únicamente las diferencias, ejecutar el proceso en fondo e incluso restringir los campos a comparar:

Obtenemos el resultado de la comparación entre ambos entornos:

Esperamos que este post os haya servido de ayuda. Si tenéis cualquier problema/duda y necesitáis que os ayudemos no tenéis mas que dejar vuestros mensajes aquí.

Nuevo formato de entradas SAP GUI

Nuevo formato de entradas SAP GUI 612 459 SAPMiN

A partir de la release 7.40 del SAPGui encontramos disponible un nuevo formato de entradas SAP GUI para gestionar la información de las conexiones con los diferentes sistemas SAP, el denominado SAP UI Landscape.

Esta nueva configuración es utilizada como estándar a partir de la versión SAPGui 7.50 en adelante.

Como podemos ver a continuación todos los ficheros de configuración de las versiones antiguas pasan a ser sustituidos por dos ficheros en formato xml:

SAP Gui < 7.40           SAP Gui >= 7.40
saplogon.ini             SAPUILandscape.xml
sapshortcut.ini          SAPUILandscapeGlobal.xml
SapLogonTree.xml
sapmsg.ini
saproute.ini

Estos ficheros se encuentran por defecto en la siguiente ubicación %APPDATA%\SAP\Common (por ejemplo C:\Users\usuario\AppData\Roaming\SAP\Common).

En caso de tener un SAPGui instalado en versiones anteriores, y pasar al nuevo formato, el propio programa recopilará todos los datos de los ficheros de configuración .ini y los transformará de forma automática al formato .xml estándar actual.

Edición del fichero de configuración

Tenemos varias alternativas para configurar las entradas a los sistemas, organizarlas en carpetas, crear favoritos etc:

◊ Modo tradicional: mediante el propio SAPGui

Como sucedía hasta ahora podemos incluir entradas directamente en el SAPGui

SAP GUI

El propio SAPGui generará toda la información necesaria en el fichero xml:

XML

Edición manual de los ficheros

Al tratarse de un fichero con formato xml, podemos editar su contenido mediante un editor de texto. En la imagen superior podíamos ver cómo es el detalle del formato de entradas SAP GUI  en el fichero editado generado.

Para que la edición sea correcta, serán necesarias las reglas de definición contenidas en el esquema XML SAPUILandscape.xsd contenido en la siguiente nota:

https://launchpad.support.sap.com/#/notes/2112449

Las etiquetas para definir los diferentes tipos de elementos/recursos dentro del fichero son estas:

Etiquetas XSD

Hay que poner especial atención en el hecho de que si necesitamos añadir una entrada o elemento nuevo, será necesario generar un uuid mediante algún generador externo como por ejemplo https://www.uuidgenerator.net/.

Transacción SLMT

Posiblemente esta es la opción más novedosa: poder editar el fichero XML directamente desde una transacción SAP SLMT (Landscape Maintenance Tool). Para poder utilizarla es necesario tener implementada en el sistema la nota 2311166, y tiene el siguiente aspecto:

Transacción SLMT

Mediante esta transacción podremos crear nuevos accesos a sistemas, nuevos elementos como entradas de saprouter, servidores de mensajes para grupos de logon, etc.

Esta herramienta también nos posibilitará adaptar las entradas de ficheros .ini de releases anteriores al formato actual, editar un xml adicional y consolidarlo con el contenido de nuestro .xml actual, etc:

Transacción SLMT

Distribución de los ficheros xml

Una vez que tengamos definidos los ficheros xml con todas las entradas necesarias, podremos seguir algunas de las siguientes estrategias para hacerlos accesibles a los diferentes usuarios según nuestras necesidades:

  1. Ficheros locales:los ficheros de configuración se guardarán de forma local en el equipo del usuario.
  2. Ficheros en recursos compartidos: podremos compartir en una ubicación de red el fichero con los permisos adecuados para que los usuarios puedan hacer uso de ellos. Por seguridad lo publicaremos con acceso de sólo lectura para restringir la edición de las entradas a usuarios administradores. Para poder utilizar esta estrategia será necesario definir la variable de entorno SAPLOGON_LSXML_FILE con el valor del Path y nombre del fichero xml.
  3. Ficheros en recurso web: Es posible publicar los ficheros xml en un servicio web de tipo http://servidor:puerto/config/SAPUILandscape.xml y configurar el SAPGui para que haga uso de dicho recurso. Adicionalmente añadiremos la url del fichero xml como valor en la varaible CoreLandscapeFileOnServer en la entrada del registro de Windows
    HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAPLogon\Options en versiones de 32 bit 
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SAP\SAPLogon\Options en versiones de 64 bits
    

    También podemos utilizar la nueva variable de entorno SAPLOGON_LSXML_FILE para indicar la ubicación sin modificar el registro.Conviene destacar, que dentro de SAPUILandscape.xml podemos indicar la ubicación de otros ficheros, con lo que podríamos modificar, por ejemplo, la ubicación de SAPUILandscapeGlobal.xml. Conviene que ambos estén apuntando en la misma dirección para evitar quebraderos de cabeza:

    SAPUILandscapeGlobal.xml en APUILandscape.xml mediante Include

Las dos últimas opciones nos permitirán realizar una gestión centralizada de todos los cambios. En estos casos es interesante activar la opción ‘Allow caching of server configuration files’. De esta forma, los ficheros de configuración quedan cacheados ante un eventual problema con los centralizados. Adicionalmente podemos reflescarlos en cada reinicio o cada cierto intervalo de horas:

SAP GUI Options, allow caching

Podemos encontrar mucha más información de éstas y otras opciones en las guías de administración de SAPGui:

https://www.sap.com/documents/2017/07/883c670b-c97c-0010-82c7-eda71af511fa.html

Esperamos que esta información os haya servidor de ayuda.

¿os habéis encontrado algún problema con el nuevo formato XML del SAPGui? Déjanos tus comentarios abajo o a través de nuestro correo, te ayudaremos encantados.