Entradas Por :

SAPMiN

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

Sácale el máximo partido a la transacción SE03

Sácale el máximo partido a la transacción SE03 501 338 SAPMiN

La transacción SE03 posiblemente sea una de las herramientas más potentes y desconocidas proporcionadas por SAP para gestionar el sistema de transportes. Sácale el máximo partido. En esta entrada le otorgaremos la importancia que merece y explotaremos las utilidades más relevantes que nos ofrece.

En un vistazo a su pantalla inicial podemos ver, agrupadas por tipología, las diferentes opciones que os pasamos a describir a continuación:

transacción SE03

Buscar objetos en órdenes y tareas

Esta opción nos permitirá buscar cualquier tipo de objeto dentro del sistema SAP e identificar en qué ordenes/tareas se encuentra, poder revisar su contenido, las diferentes versiones por las que ha pasado el objeto, de qué sistema proviene, etc. Para ello, seleccionamos el tipo de objeto y rellenamos el campo de búsqueda. Por defecto aparecen en las primeras líneas los más usuales.

De forma adicional, también podremos buscar modificaciones concretas dentro del árbol de parametrización de la transacción SPRO:

BuscarObjetosEnOrdenesYTareas

Vayamos a un ejemplo práctico: queremos buscar qué órdenes contienen la definición o modificaciones sobre la tabla USR02. Para ello marcamos el flag del objeto Table/Structure, completamos el campo con el valor USR02, seleccionamos tanto las órdenes modificables como las liberadas, y por último ejecutamos para obtener el resultado:

se03_BuscarObjetosEnOrdenesYTareas_2

Obtenemos como resultado en este caso dos órdenes provienentes de parches:

se03_BuscarObjetosEnOrdenesYTareas_rdo

Esta opción también es especialmente útil para buscar órdenes con contenido de una tabla concreta seleccionando el objeto R3TR TABU nombre_de_tabla.

Incluir objetos en una orden de transporte

Esta opción nos permitirá seleccionar mediante diferentes criterios de selección (por usuario, paquete, sistema origen) los diferentes objetos e incluir los que necesitemos en una orden de transporte

Mediante la herramienta de selección (paso 1) pulsaremos los diferentes objetos que queramos escoger, y por último (paso 2) los incluiremos en una orden:

Visualizar los objetos reparados

Mediante esta opción podremos ver todos los objetos estándar que han sido modificados en el sistema y sus propiedades. Si pulsamos el botón Lock Overview además podremos ver directamente en qué orden de transporte se encuentra la modificación:

se03_VisualizarObjetosReparados

Actualizar propiedad de objetos

Con esta opción podremos, de forma individual o masiva, cambiar la propiedad de los objetos pertenecientes a uno o varias usuarios, de uno o varios paquetes e incluso de una o varias capas de transporte.

Desbloquear objetos en órdenes

Esta opción es posiblemente una de nuestras favoritas, y que en algunas ocasiones resuelve problemáticas aparentemente sin una solución sencilla. Por ejemplo, cuando necesitamos liberar una orden que se ha generado en un mandante que ya no existe, podemos utilizar esta característica para liberar el bloqueo sobre los objetos y marcar las tareas y órdenes como liberadas. También puede ser útil para liberar órdenes que contienen objetos con errores de generación, etc.

se03_lockObjects_2

se03_lockObjects_2

se03_lockObjects_3

Modificar atributos de las órdenes:

Por último, podemos configurar las siguientes opciones para todas las órdenes de transporte:

se03_modificarAtributosOrdenes

¿Os ha parecido interesante este post?

¿Os habéis encontrado algún problema o duda utilizando la TX SE03 para gestionar el sistema de transportes SAP?

No olvidéis dejarnos vuestros comentarios aquí 🙂

Configurar y optimizar backups Hana con Veeam Backup

Configurar y optimizar backups Hana con Veeam Backup 371 263 SAPMiN

Por todos son conocidas las grandes capacidades que tienen las soluciones de respaldo y restauración ofrecidas por Veeam Backup. En el post de hoy trataremos cómo configurar backups nativos de Hana a través de Veeam, y sin la necesidad de contar con el Hana Cockpit 2.0, aunque bien es cierto que esta herramienta puede sernos de gran ayuda (por ejemplo para planificar los backups sin un sistema SAP ABAP, gestionar el ciclo de vida de los backups, etc.)

¿Cómo funciona el agente de Veeam Backup para Hana?

El agente de Veeam utiliza el interfaz de backint de SAP Hana para comunicarse y enviar los datos a los repositorios del servidor de Veeam Backup, haciendo uso de técnicas de compresión y optimización para reducir el espacio necesario de almacenamiento para estos backups.

Una vez instalado y configurado el agente de Veeam para Hana, e iniciado un backup desde la parte ABAP de SAP, el Hana Studio, el Hana Cockpit o incluso mediante comandos HDBSQL, el agente iniciará un job en el servidor de Veeam, se lanzarán los servicios para el movimiento de los datos hacia el repositorio destino utilizando la cantidad de procesos paralelos definidos hasta completar la transferencia de todos los datos seleccionados según el tipo de backup lanzado.

Pasos previos y requisitos para configurar y optimizar backups Hana con Veeam Backup

Dado que el agente de Veeam se ha de instalar en el servidor Hana, es un tanto improbable que no se cumplan los requisitos necesarios para poder hacerlo. Aún así, son estos:

  • versiones de S.O.: SuSE SLES / SuSE SLES for SAP 12 o superior, y Red Hat for SAP Hana / Red Hat for SAP 7.2 o superiores
  • versiones SAP Hana: Hana 1.0 SP12 o superior y Hana 2.0 SPS 02 o superior (las versiones Hana Express Edition no se encuentran soportadas) 
  • las versiones del plug-in y el servidor de Veeam han de ser compatibles
  • comunicación directa entre el servidor Hana y el servidor Veeam. Será necesario, al menos, habilitar los puertos (cuyo valor estándar por defecto) 10006, 2500 (y si utilizamos varios procesos paralelos para backup tantos puertos del 2500 en adelante como procesos paralelos utilicemos) desde el servidor Hana hacia el servidor de Veeam Backup. Revisar el siguiente enlace para otras opciones de almacenamiento
  • Una licencia de Veeam válida para poder llevar a cabo los backups

Instalación del agente

Descargamos la iso VeeamBackup&Replication_xx.x.x.xxxx.iso de la siguiente url https://www.veeam.com/backup-replication-vcp-download.html

De esta iso, obtenemos el paquete VeeamPluginforSAPHANA-xx.x.x.xxxx-x.x86_64.rpm ubicada en el directorio /Plugins/SAP HANA/x64, lo subimos al servidor hana y lo instalamos como root (o un usuario con permisos sudo) con el comando rpm -ivh VeeamPluginforSAPHANA-xx.x.x.xxxx-x.x86_64.rpm

Configuración del plug-in

Una vez instalado, configuraremos el plug-in con los datos relativos a nuestra instalación de Veeam Server. Para ello, con el usuario <sid>adm de nuestra instancia Hana y desde dicho servidor lanzaremos el siguiente comando que despliega en modo texto el asistente de configuración:

SapBackintConfigTool --wizard

Introducimos todos los datos para conectar con el servidor de Veeam, usuario y password con permiso para los repositorios, etc.

Nota importante: el usuario indicado ha de ser capaz de hacer login en el servidor de Veeam y tener permisos suficientes para gestionar los repositorios de datos en los que queremos dejar los backups.

Instalacion

Para su posterior consulta o modificación, el fichero principal de configuración para el agente se encuentra en la siguiente ubicación, que se ha generado tras la ejecución del comando anterior:

 /opt/veeam/VeeamPluginforSAPHANA/veeam_config.xml

Finalmente verificamos que la configuración en los parámetros de Hana se ha actualizado correctamente. Podemos verificarlo mediante el fichero global.ini → Backup, Hana Studio o mediante la ST04 si estamos utilizando un sistema SAP:

Como se puede apreciar en la imagen, los parámetros para realizar los backups mediante la interface de backint están completados, y haciendo uso del plug-in de Veeam.

Recomendaciones adicionales para optimizar los backups de Hana en Veeam.

A destacar en la parte inferior, correspondiente al backup de log de Hana, que hemos configurado también que Hana haga uso del backing a través de Veeam para salvar los logs de la BBDD, con una frecuencia de 15 minutos.Optimización de los backups (y también de la restauración)Optimización de los backups (y también de la restauración)

En el fichero de configuración de Hana global.ini → backup, podremos ver también los cambios efectuados por el asistente del plug-in Veeam:

global.ini

A partir de este punto, ya podemos lanzar los backups contra Veeam 🙂

Optimización de los backups (y también de la restauración)

Aunque por defecto la configuración de Hana utiliza un único proceso de backup, es posible configurar varios procesos paralelos de tal forma que los tiempos de backup se reduzcan considerablemente, así como también la duración de las restauraciones de BBDD, que harán uso de la misma cantidad de procesos paralelos (definido en el parámetro de Hana max_recovery_backint_channels). Si bien es cierto que Hana de forma automática aumenta esta cantidad de procesos para BBDDs de más de 128GB, nos adelantaremos a ello configurando los procesos que nos parezcan más adecuados para nuestra instalación. Es importante también aclarar que cuantos más procesos paralelos definamos, mayores recursos HW serán utilizados para realizar el backup, y que por tanto será necesario buscar un equilibrio para no afectar negativamente en el rendimiento del sistema Hana durante el tiempo de backup.

Para habilitar esta funcionalidad modificaremos los siguientes parámetros en Hana (fichero global.ini):

  • parallel_data_backup_backint_channels: definiremos la cantidad de procesos paralelos
  • data_backup_buffer_size: indicaremos el parámetro anterior x 512

Recomendaciones adicionales para optimizar los backups de Hana en Veeam

  • utilizar un repositorio de backups exclusivo
  • hacer backups de BBDDs tenant de forma secuencial en vez de en paralelo para optimizar el uso de recursos hardware
  • definir también varios procesos paralelos para la restauración, y siempre menos de 64
  • utilizar el cifrado de datafiles y backups en Hana, ya que Veeam es compatible con este mecanismo
  • realizar también el backup del catálogo de backups, que por defecto se genera en el mismo directorio que los logs de Hana en disco, mediante el agente de Veeam Backup. Para ello configuraremos el parámetro catalog_backup_using_backint a true, y definiremos convenientemente el parámetro catalog_backup_parameter_file con valor /opt/veeam/VeeamPluginforSAPHANA/hdbbackint

Ejecución de backups

Tras configurar y optimizar las tareas de backup, ya estamos prestos a lanzar la primera copia.

Disponemos de diferentes opciones para realizarlas:

  • utilizar los comandos hdbsql de Hana: backup data for nombreDB using backint (‘nombre_backup’);
  • desde el Hana Studio
  • desde el Hana Cockpit
  • desde la TX DB13 en caso de usar Hana con un sistema ABAP

En nuestro caso haremos uso de la última opción:

DB13 Schedule

Como se puede ver en la imagen, hemos seleccionado el destino de tipo backint, y el campo Backup Destination aparece deshabilitado, dado que se utiliza con backups a discos, y por último indicamos el nombre que queremos que tenga el backup, pudiento utilizar algunas variables como el timestamp:

DB13 Schedule

Lanzamos el backup de forma inmediata, y comprobamos que ha finalizado correctamente:

Log

Si vamos a la consola de Veeam podremos ver los jobs que se generan con el plug-in.

Retención de los backups

Como último punto, y no menos importante, tenemos la forma con la que fijar el ciclo de vida para los backups que acabamos de generar. Tenemos varias opciones para gestionar su borrado:

  • borrado manual desde el Hana Studio
  • configurar el período de retención desde el Hana Cockpit
  • borrado mediante comando hdbsql: backup catalog delete {backup_id | all before backup_id}
  • borrado manual desde la consola de Veeam Backup
  • indicar el periodo de retención en el propio agente de Veeam

En esta ocasión haremos uso de la última opción, que permite de forma automatizada borrar en Veeam Backup los backups más antiguos del número de días configurado. Con el usuario <sid>adm y desde el servidor Hana lanzamos el siguiente comando:

SapBackintConfigTool --set-force-delete 

cli

¿te ha parecido interesante esta entrada? ¿te has encontrado algún problema configurando el agente de Veeam para Hana? 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í.

RestrictedArea

Cómo hacer un trace de autorizaciones en SAP

Cómo hacer un trace de autorizaciones en SAP 587 379 SAPMiN

Es muy frecuente tener que enfrentarse en el día a día a problemas de autorizaciones en un entorno SAP. Puede ser necesario añadir nuevos permisos durante el mantenimiento habitual, y también de forma adicional tras una actualización de parches o un proceso de upgrade de versión por ejemplo. Saber cómo hacer un trace de autorizaciones correctamente es de gran utilidad.

En este post desarrollaremos todas las herramientas y posibilidades que tenemos para solventar este tipo de situaciones, y cómo identificar las autorizaciones necesarias en las situaciones más complicadas.

Cuando ejecutamos una transacción desde el SAPGui, los primero que chequea el sistema es si tenemos autorización a dicha transacción, y posteriormente se verifican el resto de objetos y valores de autorización, si fuese el caso, mediante la instrucción ABAP AUTHORITY-CHECK.

De forma general, cuando nos encontramos con un problema de autorizaciones, solemos encontrar tres tipos principales de errores, sobre todo en la parte ABAP/R3:

  1. No existe acceso a una transacción. El permiso para poder ejecutar una transacción se concede añadiendo su id en el objeto de autorización S_TCODE.
  2. No está asignado el objeto de autorización.
  3. El objeto de autorización está dentro de los perfiles del usuario, pero sin los valores necesarios.

Nota importante: Cuando en SAP se realiza una verificación de autorizaciones, el sistema busca dentro de todos los perfiles que el usuario tiene asignados el objeto de autorización y los valores específicos. Basta con que éstos se encuentren en cualquier rol para que el acceso sea concedido.

Podemos tener por ejemplo el acceso a una transacción en un rol, y el objeto de autorización y ciertos valores en otro rol. El sistema SAP verificará la conjunción de todos los objetos y valores asignados en los perfiles. Un problema habitual suele darse cuando un usuario tiene acceso de forma inesperada a ciertas actividades o tareas que no debería, o que aparentemente no han sido concedidas explícitamente. Esta conjunción de autorizaciones suele estar detrás de estas situaciones.

Hay que tener en cuenta que algunas transacciones estándares hacen uso de objetos de autorización no sólo del módulo al que pertenecen, sino también de objetos relativos a otros módulos, y que una incorrecta parametrización de sus valores podría generar este tipo de problemas.

Es altamente recomendable, por este motivo, no utilizar valores * por desconocimiento o sin justificación, o incluso dejar sin completar campos en objetos de autorización.

Método más sencillo: transacción SU53

La forma más rápida y directa de analizar un error de autorizaciones consiste en ejecutar la transacción SU53 inmediatamente después de recibir el mensaje de error.

Fallo de autorizaciones

A modo de ejemplo, analizamos el error anterior, ejecutando la transacción SU53, y obtenemos el siguiente resultado:

SU53

Como veíamos en la explicación inicial, en este caso concreto el objeto de autorización que está dando error es el S_TCODE. Es decir, el que marca el acceso de inicio a la propia transacción, y el valor necesario para poder avanzar es SM37.

Bastaría con añadir un perfil o rol que tenga el objeto S_TCODE con el valor SM37 para solucionar el problema.

Como segundo ejemplo de tipos de error, ejecutamos con nuestro usuario de test la transacción FBC_BM_V. Hemos agregado únicamente el acceso a dicha transacción al usuario (con S_TCODE = FBC_BM_V), pero al entrar en dicha transacción obtenemos este error:

SU53 info

Si volvemos a ejecutar la transacción SU53 vemos que aparecen los siguientes objetos y valores de autorización que el usuario necesita:

SU53

Como en el ejemplo anterior, una vez identificados los objetos y valores de autorización necesarios, bastaría con asignárselos a alguno de los roles/perfiles que tenga el usuario, o asignando al usuario un rol/perfil que los contenga.

De forma adicional, y si contamos con los permisos suficientes, podemos revisar los fallos de autorización de otros usuarios. Para ello pulsaremos el siguiente botón (F5):

SU53 para otro usuario

SU53 otro usuario2

Indicando el id del usuario que queremos revisar, y pulsando el botón de ejecutar, obtendremos los registros de sus fallos de autorización.

Este método puede ser apropiado para una situación en la que son pocos los valores u objetos que son necesarios añadir en los roles del usuario. Pero si nos encontramos con que son muchos los objetos/valores que faltan, será más apropiado utilizar el segundo método.

Método más completo: trace de autorizaciones en la transacción ST01

Hemos encontrado circunstancias en las que nos hemos dado cuenta, sobre todo en versiones Netweaver 7.0 y anteriores, que la transacción SU53 no funcionaba completamente, o que daba la sensación de que no estaba aportando toda la información necesaria. Por esos casos, el uso del trace de autorizaciones suele ser una garantía de éxito.

El trace de autorizaciones nos permitirá seleccionar y analizar no sólo los fallos de autorizaciones, sino también todas las verificaciones que el sistema lleva a cabo. Nos permitirá además indicar el usuario concreto para el cual queremos generar el trace; o si preferimos, hacerlo por transacción, etc.

Siguiendo con los ejemplos anteriores, vamos a generar un trace que muestra todas las verificaciones de autorización para el usuario test. Para ello ejecutaremos la transacción ST01 con los siguientes pasos:

  1. Marcaremos el trace de autorizaciones e indicaremos si queremos analizar todas o únicamente los errores
  2. Pulsaremos el botón para definir los filtros del trace
  3. Configuraremos los parámetros para el trace
  4. Activaremos el trace

ST01

Una vez activado el trace, ejecutaremos las tareas específicas con el usuario de test, y desactivaremos el trace, para posteriormente analizarlo:

ST01 2

En la pantalla de selección marcaremos el usuario, mandante, fecha y hora, y los traces para autorizaciones:

ST01 opciones

Obtenemos los resultados del trace:

ST01 resultado

ST01 resultado 2

Deberemos fijarnos en el valor de RC (Return Code) de los registros para diferenciar si las verificaciones han sido correctas o no. Si hacemos doble click en cada registro de verificación encontramos la información detallada:

ST01 detalle

Además de los escenarios detallados, este modo de análisis podría ser muy útil cuando queremos generar por ejemplo un nuevo rol y necesitamos conocer los objetos/valores de autorización que verifica el sistema para realizar una serie de tareas. Podemos activar para ello el trace, y con un usuario con suficientes autorizaciones llevar a cabo todas las actividades requeridas, analizar el trace, y añadir los objetos y valores de autorización que hayan aparecido en éste.

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

Puedes dejarnos tus comentarios o dudas aquí.

Uso de la transaccion STAD para análisis detallados

Uso de la transaccion STAD para análisis detallados 140 120 SAPMiN

Seguramente todos, en alguna ocasión, nos hemos encontrado con problemas de rendimiento en SAP en algún report o función; ya sea estándar o un desarrollo propio, y que nos gustaría poder analizarlo de forma pormenorizada de forma adicional o complementaria a lo que desarrollamos sobre la transacción SE30. O por contra nos gustaría conocer con detalle cuáles son los reports/programas/transacciones  funciones que uno o varios usuarios han ejecutado, y de forma general analizar la carga del sistema y las estadísticas de ejecución en un intervalo concreto de tiempo. Hoy os presentamos una nueva forma de hacerlo, mediante la transacción STAD.

STAD

Según entramos en la transacción STAD, se nos muestra una pantalla de selección en la que completaremos la fecha del análisis, la duración del mismo, podremos especificar un mandante concreto, el usuario o usuarios, los datos de una transacción o programa concretos, incluso un tipo de tarea (diálogo, en fondo, actualización, impresión, RFC, http, …)

Por simplicidad tomaremos un intervalo de 10 minutos, únicamente para nuestro usuario y mostrando todos los tipos de ejecución:

stad_1

En la parte superior de la pantalla de selección podremos configurar cómo se muestran los resutados, agrupándolos por diferentes criterios:

  • Según su tiempo de ejecución
  • Agrupados por transacción
  • Totales sobre transacciones

Por último, podemos añadir los datos de uso de memoria y estadísticas de aplicación, datos que normalmente suelen ser de gran interés.

Resultado

No nos queda mas que pulsar enter, y obtendremos los resultados de la medición:

stad_2

Como se puede apreciar en la imagen, aparecen todos los registros de actividad para el usuario SAPMiN en el intervalo indicado ordenados cronológicamente. Podemos observar la transacción ejecutada, el report/funciones que se han lanzado incluyendo el número de dynpro (lo cual nos permite una gran trazabilidad para analizar problemas), los tiempos de respuesta, y los consumos de red y memoria.

Si pulsamos sobre alguna de las entradas, el sistema mostrará un mayor detalle de cada uno de los campos que se muestran en el resumen. Podemos ver los tipos de tareas ejecutadas y tiempo de respuesta, análisis de uso SQL, consumo de memoria, uso de red, por ejemplo:

stad_3

stad_4

Truco:

Esta transacción nos permite seleccionar los campos que queremos que visualice el listado con los resultados. Para ello pulsaremos el botón stad_5 y aparecerá un listado seleccionable

Podremos seleccionar algunos campos muy interesantes como:

  • tiempo de CPU
  • peticiones de BBDD
  • cantidad de entradas en tablas de BBDD
  • operaciones de insert, delete, update sobre BBDD
  • número de WorkProcess de ejecución
  • y una de nuestras favoritas, Terminal ID

stad_6

Tras agregarla podremos ver el terminal desde el que se ha ejecutado la transacción. Esto es especialmente interesante por ejemplo para averiguar desde que equipo se ha lanzado una transacción concreta si por ejemplo se está haciendo uso de la característica multilogin, y un mismo hace login en equipos diferentes:

stad_7

Todas estas opciones nos permitirán analizar tanto los tiempos de respuesta, como las transacciones y reports ejecutados, los usuarios que los han lanzado, el uso de memoria y red, e incluso el equipo desde el que se ha hecho. Esto nos permitirá descubrir cuellos de botella en el rendimiento, procesos costosos en recursos, los responsables de ejecución de algunas tareas, y un largo etc de posibilidades más.

Importante: Las estadísticas de la transacción STAD, debido a su nivel de detalle, no perduran eternamente en el sistema, y son reorganizadas según el valor del parámetro stat/max_files. Este parámetro fija la cantidad de ficheros de estadísticas que se generan como máximo. Teniendo en cuenta que se genera un fichero de este tipo cada hora, un valor de 48 (que es el fijado por defecto) determina que se almacenarán los datos estadísticos con un máximo de 48 horas.

Si tienes cualquier duda o necesitas ayuda, puedes contactar con nosotros aquí.

 

TransaccionSE30

¿Cómo funciona la transacción SE30?

¿Cómo funciona la transacción SE30? 709 528 SAPMiN

¿Cuantas veces has encontrado problema de rendimiento en algunos servicios, transacciones, function modules? ¿Por donde empezar a analizarlo? ¿Cómo funciona la transacción SE30?

La transacción SE30 nos permitirá analizar el tiempo de ejecución de los diferentes bloques que componen un report, transacción o función que queramos analizar. Podremos utilizar los resultados obtenidos para optimizar el funcionamiento de éstos y mejorar de esta manera el rendimiento general en nuestro entorno SAP o prevenir cuellos de botella.
Esta transacción se incorpora con el componente SAP_BASIS y está disponible en cualquier release de motores Netweaver ABAP.

Fase 1: Ejecución y medición

El primer paso será entrar en la transacción SE30 e introducir una descripción para identificar la sesión de análisis. Posteriormente optaremos por ejecutar la transacción/report/función a analizar de forma interactiva (In Dialog), en un proceso paralelo, o planificarlo para una ejecución posterior (Schedule):

TransaccionSE30

Vamos a utilizar para el ejemplo una transacción estándar como es la SUIM, en la que realizaremos una búsqueda sencilla. Tras indicar esta transacción en el campo Transaction, nos aseguramos de que el check Eval. Immediately está marcado, y pulsamos el botón de Execute. A continuación nos aparecen la pantalla inicial de la SUIM, y la utilizamos de forma habitual:

TransaccionSUIM

TransaccionSUIM_2

Pulsamos el botoón de ejecución, y el sistema nos muestra los resultados para la selección:

TransaccionSUIM_3

Por último pulsamos el botón de retroceso hasta salir de la transacción de ejemplo y volver a la pantalla original de la SE30.

Fase 2: Evaluación de resultados

Tras obtener la medición de tiempos, pulsamos la pestaña Evaluate y vemos la sesión que acabamos de generar:

TransaccionSE30_RuntimeAnalysis

Pulsamos doble-click sobre la entrada, y nos aparece el resumen del análisis:

TransaccionSE30_RuntimeAnalysis_2

En la parte izquierda encontramos divididos por bloques de funcionalidad las llamadas con sus respectivos consumos, y en la parte derecha se despliegan las sentencias correspondientes al bloque seleccionado:

TransaccionSE30_RuntimeAnalysis_3

Si pulsamos con doble-click por ejemplo a la primera entrada, la transacción nos llevará al punto exacto en el que se encuentra dicha sentencia:

TransaccionSE30_RuntimeAnalysis_4

TransaccionSE30_RuntimeAnalysis_5

En la pestaña DB Tables podemos encontrar las tablas cuya utilización han consumido la mayor parte del tiempo de ejecución:

TransaccionSE30_RuntimeAnalysis_6

Podemos utilizar esta mecánica para identificar los puntos más problemáticos de nuestro código.

Fase 3: Implementación de correcciones

Por último, únicamente nos restaría dar solución a las áreas de mayor consumo si realmente es posible. Algunas de las soluciones más comunes suelen ser:

  • Condiciones más restrictivas en selecciones sobre tablas tanto internas como de diccionario
  • Creación de índices adicionales
  • Selects con clausulas first / top
  • Evitar full scans de tablas
  • Etc.

Tips & Tricks

Una opción muy agradecida que nos brinda la transacción SE30 es el botón de Tips & Tricks, ya que si pulsamos sobre este botón, se nos mostrará organizados por recurso, una serie de trucos y recomendaciones para optimizar el rendimiento de nuestro código:

TransaccionSE30_RuntimeAnalysis_7

Ahora que conoces como funciona la transacción SE30, esperamos que te sirva de ayuda para mejorar tu código o analizar cuantos problemas te encuentres.

Puedes dejarnos tus comentarios aquí.

Integración de correo Microsoft 365 en SAP, correo entrante

Integración de correo Microsoft 365 en SAP, correo entrante 939 449 SAPMiN

Como vimos en la entrada anterior, integracion-de-correo-microsoft-365-en-sap-correo-saliente, es posible configurar el correo saliente de SAP con Microsoft 365. En esta entrada trataremos el caso opuesto, configurando la integración de correo entrante Microsoft 365 en SAP.

Ésta casuística puede ser más complicada ya que pueden darse múltiples configuraciones, casi tantas posibilidades como entornos existan. Muchas de estas peculiaridades pueden suponer un reto a la hora de realizar una implementación sencilla.

Para ilustrar este post, vamos a basarnos en un caso con las siguientes premisas:

  • Correo corporativo en Microsoft 365
  • Un único dominio
  • Un entorno grande consolidado que busca el mínimo de cambios sobre la estructura actual
  • Conservación de todos los correos en las cuentas entrantes
  • Necesidad de reforzar la seguridad.

Visión general

Para la integración de correo entrante Microsoft 365 en SAP con este caso práctico, dado que Office recepcionará los correos entrantes y deben permanecer en las cuentas originales, deberemos indicarle cual y cómo es el destino al cual debe reenviar una copia de dichos correos.

Para ello generaremos una o más reglas y uno o más conectores según sean las necesidades. Habremos de tener en cuenta dos particularidades del entorno de correo:

  • Microsoft 365 solo enviará información al puerto 25 del destino del conector que definamos. En entornos unix no es recomendable utilizar puertos por debajo del 1024, por lo que utilizaremos el firewall para redirigir el tráfico, evitando así tener que enlazar puertos del sistema.
  • Microsoft 365 utiliza internamente el protocolo propietario TNEF (Transport Neutral Encapsulation Format), por lo que todos los correos enviados hacia uno de los dominios propios utilizará dicho protocolo salvo que se modifique. Puede desactivarse de forma global, pero dado que se va a intentar maximizar la compatibilidad y minimizar los cambios en la infraestructura ya existente, se llevará a cabo una alternativa.

Éstos puntos serán importantes en la solución que se va a proporcionar.

Entorno de Red

Como en la entrada anterior, el primer punto es configurar las conexiones, esta vez en sentido inverso. Debe permitirse el tráfico entrante que llegue desde Microsoft a nuestro entorno, denegando las que lleguen de cualquier otra dirección. Deberemos además redireccionar el tráfico entrante en el puerto 25 a nuestro sistema y puerto adecuado que definiremos más adelante (en este caso el puerto 25000).

Podemos ver las direcciones e ips de Microsoft aquí.

Perfiles, servicio SMTP y SAPConnect [incoming]

Deberemos configurar el parámetro para levantar un servicio SMTP con el arranque de SAP similar al siguiente:

Parametros

icm/server_port_X, donde X es un número correlativo para los servicios del ICM que hayamos definido.

En este parámetro estaremos indicando que se haga uso de un servicio smtp por el puerto 25000 con autenticación TLS/SSL.

El valor TLS especifica los posibles valores para el cifrado TLS usando STARTTLS. Los valores para este parámetro son:

  • 0: indica que no debe utilizarse
  • 1: se ofrece pero es opcional
  • 2: que su uso es obligatorio.

Tal y como indica Microsoft, esta última es la opción correcta.

Hay otros valores que podría ser interesante añadir como TIMEOUT y PROCTIMEOUT para limitar el  intervalo antes del timeout y tiempo de procesamiento respectivamente, que típicamente suelen ser valores entre 60 y 120 segundos. En caso de no indicarlos se tomará el valor por defecto del kernel que suele ser de 60.

Es necesario utilizar un puerto que no interfiera con otros ya activos, como los reservados para el sistema operativo. En entornos linux, si fuera necesario, podríamos utilizar la opción EXTBIND=1 para autorizar el uso de puertos dentro del rango <1024 (más info: 421359 – ICM: Binding ports < 1024 on UNIX), siempre y cuando no exista ya un servicio smtp activo en dicho puerto.

Para que estos parámetros tomen efecto deberemos reiniciar el ICM o directamente la instancia. Podremos ver los valores aplicados en la transacción SMICM → Pasar a → Servicios:

smicm

Una vez el parámetro está definido hay algunos campos que podemos modificar dinámicamente:

smicm2

smicm3

Podemos comprobar que el servicio se ha creado y responde con un telnet:

telnet2

Para poder recepcionar los correos desde SAP es necesario activar el servicio SAPConnect en la transacción SICF:

sapconnect

Una vez llegados hasta este punto el entorno SAP está listo para recibir emails, aunque aún deberemos hacérselos llegar.

Conectores y reenvíos Office 365

En este apartado las combinaciones son numerosas, podríamos reenviar a SAP todos los correos que lleguen a un buzón o solo aquellos con determinado asunto, etc.

Para una de estas posibilidades podemos crear un conector similar al siguiente en el centro de administración de Exchange → Flujo de correo → Conectores:

En la siguiente imagen podríamos, en caso de tener dos dominios, utilizar uno en exclusiva para el reenvío de correos a SAP, aunque en este caso dejaremos la elección del envío en manos de otras reglas:

Indicaremos la(s) IP(s) a la que se intentará realizar el envío, detrás de la cual tendremos el servicio SAP:

 

Con preferencia, y tal como hemos definido en el parámetro del servicio smtp, utilizaremos siempre la capa de seguridad TLS

Será preciso completar un test aunque sea incorrecto para poder avanzar y guardar el conector. Para ello pulsamos validar:

 

Y finalmente pulsamos en crear conector:

Podremos utilizar este conector para reenviar correos a través de él mediante reglas con mayor o menor complejidad. Por ejemplo, podemos crear una regla para que todos los correos enviados a una cuenta en concreto, se canalicen hasta SAP a través del conector:

regla

Es importante tener en cuenta que con dicha configuración estándar el correo no llegará al buzón, sino que será redirigido exclusivamente a SAP salvo error en el conector.

En caso de que quisiéramos que se mantuviera en el buzón, podemos crear una regla para que se envíe una copia dentro del propio buzón marcando la opción de conservar:

reenvio

Transacción SOIN

Podemos verificar los correos entrantes en la transacción SOIN.

Es probable que durante las pruebas iniciales queramos realizar traces a todos los correos entrantes para poder determinar su correcto enrutamiento. Podemos gestionar el uso del trace mediante la opción SOIN →Utilidades → Parametrizaciones de trace:

parametrosTrace

Es importante desactivarlo o activarlo sólo cuando recibamos errores para evitar más traces de los necesarios.

Podremos ver los traces en la transacción SOIN → Utilidades → Selección de trace.

Con ésto habremos terminado la integración de correo entrante Microsoft 365 en SAP. Opcionalmente conviene tener en cuenta el siguiente punto acerca de el formato TNEF.

Formato TNEF [opcional]

Por defecto Outlook, Ms Exchange y por extensión Office 365 utilizan el formato propietario TNEF (https://es.wikipedia.org/wiki/TNEF) siempre y cuando sea posible. Es posible Es probable que por ello nos encontremos con el inconveniente de que lleguen correos a SAP con adjuntos de tipo winmail.dat que nos será imposible tratar dentro del sistema. Dentro de este adjunto encontraríamos la información codificada en dicho formato pero no podremos hacer uso de ella.

Más info: https://support.microsoft.com/en-us/topic/how-email-message-formats-affect-internet-email-messages-in-outlook-3b2c0536-c1c0-1d68-19f0-8cae13c26722

Para abordar este problema Microsoft propone dos soluciones:

  1. Cambiar el formato para los contactos externos
  2. Cambiar el formato para los contactos de un dominio específico.

Más info: https://support.microsoft.com/es-es/topic/c%C3%B3mo-especificar-el-formato-del-mensaje-de-correo-electr%C3%B3nico-que-se-usa-para-los-destinatarios-externos-para-evitar-los-datos-adjuntos-de-winmail-dat-4a379475-1557-9554-ab72-91c5867afc11

Para poder aplicar cualquiera de las dos soluciones deberemos conectarnos a la PowerShell de nuestro Exchange Online:

https://docs.microsoft.com/en-us/powershell/exchange/connect-to-exchange-online-powershell?redirectedfrom=MSDN&view=exchange-ps

Instalamos el proveedor de paquetes a instalar

Install-PackageProvider -Name NuGet -Force Install-Module -Name PowerShellGet -Force 

Posershell1

Instalamos el módulo EXOV2, ExchangeOnlineManagement, que contiene un pequeño conjunto de cmdlets nuevos y optimizados para escenarios de recuperación de datos en masa (miles y miles de objetos).

Install-Module -Name ExchangeOnlineManagement

Posershell2

Modificamos la política para hacerla menos restrictiva:

Set-ExecutionPolicy RemoteSigned

Posershell3

Importamos los modulos:

Import-Module ExchangeOnlineManagement; Get-Module ExchangeOnlineManagement

Posershell4

Import-Module ExchangeOnlineManagement

Posershell5

Nos conectamos para poder operar:

 Connect-ExchangeOnline -UserPrincipalName <UPN> [-ShowBanner:$false] [-ExchangeEnvironmentName <Value>] [-DelegatedOrganization <String>] [-PSSessionOption $ProxyOptions] Connect-ExchangeOnline -UserPrincipalName correo_usuario_admin@...onmicrosoft.com

Posershell6

Esto nos abre una ventana de login y nos conectamos.

Finalmente configuramos nuestro exchange como mejor nos convenga.

¿Te ayudamos a configurarlo?

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.