Trucos

Categories, unlike tags, can have a hierarchy.

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

¿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?

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

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

Microsoft 365, antes Microsoft Office 365, es un conjunto de herramientas que nos permite crear, acceder y compartir a documentos tanto en un entorno local como en la nube, gestión de correo electrónico, etc. entre muchas otras posibilidades.

La integración del correo Microsoft 365 en SAP es una de las formas en las que ambas suites interactúan.

En la siguiente nota (722513 – Desktop Office Integration: Maintenance information) podréis encontrar más información al respecto.

La integración del correo saliente Microsoft 365 en SAP no es un proceso complicado y con Microsoft 365 no difiere mucho de otras alternativas. En esta entrada trataremos el correo saliente y dejamos para una futuro el correo entrante. La configuración del correo saliente es notablemente más sencilla que la del entrante:

Configuración de red / conectividad

El primer paso es asegurarnos de que tenemos acceso desde SAP al servidor smtp.office365.com.

Desde el propio servidor SAP podemos realizar ping y telnet a dicha dirección y puerto 587, y con ello comprobaremos si accedemos correctamente. En caso de no tener éxito habrá que revisar los diferentes elementos de red que intervienen en esta comunicación.

telnet

Nodo de salida a Office 365

Para definir un nodo de salida deberemos ir a la transacción SCOT y definir un nodo de tipo SMTP que enviará los e-mails a través del host smtp.office365.com en el puerto 587.

scot

Como se muestra en la imagen de arriba es necesario indicar en el apartado SMTP Connection → Security la opción más restrictiva: TLS obligatorio. El resto de opciones no funcionarán o podrían presentar problemas, por lo que no es aconsejable su uso.

Dentro de las opciones (SMTP Connection → Settings) del nodo recién creado recomendamos activar las siguientes dos opciones:

  • Check Host Name
  • Check Server Certificate

De esta forma se comprobarán el nombre del servidor de correo y el certificado con el que se autentique. El hecho de utilizar esta última opción nos ofrecerá permitirá indicar el contenedor PSE en el que albergaremos el certificado que debemos aceptar de Microsoft. Indicaremos el contenedor SSL Client por defecto en el campo Client Identity, donde posteriormente importaremos dicho certificado.

Por último, deberemos indicar un usuario y contraseña de una cuenta válida dentro del servicio Microsoft 365.

scot2

Es importante destacar que la cuenta de usuario que hayamos definido en la imagen anterior será la emisor de los correos. Si queremos cambiar el emisor de los mails por otra cuenta diferente, por ejemplo la de un usuario final, la primera cuenta deberá tener permisos para enviar correos en nombre de la segunda dentro de Microsoft 365.

Certificados de seguridad

Una vez definido que debe aceptarse el certificado del servidor, debemos incluir dicho certificado o el de las entidades que lo generen en la transacción STRUST dentro del contenedor pse que hemos definido. De lo contrario veremos en los traces del ICM aparecer errores de certificado cada vez que tratemos de enviar un correo y dichos correos no llegarán al destinatario.

Podemos obtener el certificado del servicio SMTP de Microsoft 365 ejecutando el siguiente comando:

openssl s_client -starttls smtp -showcerts -connect smtp.office365.com:587 -servername smtp.office365.com | openssl x509 > o365.cer

Tras ello abriremos el contenedor definido en el punto anterior, cargaremos el certificado y lo incluiremos en la lista de certificados admitidos, guardaremos y distribuiremos. En función de la versión es posible que sea necesario reiniciar el ICM.

strust

 

Cuentas de correo

En la transacción SU01 podemos añadir/modificar la cuenta de correo de cada usuario. Si la cuenta coincide con la del servidor Microsoft 365 no habrá problema.

No obstante es muy habitual que cada usuario tenga su propia cuenta. En ese caso podemos encontrarnos con errores como el siguiente en la SOST:

ErrorRelay

o en los traces del ICM:

Error_relay

Este problema se debe a que la cuenta de correo definida para el usuario SAP, en la transacción SU01, no tiene permiso para enviar correos en nombre de la que hayamos definido en la transacción SCOT. Debemos entonces asignar estas autorizaciones desde el centro de administración de Microsoft 365. Puede hacerse de forma global mediante comandos PowerShell o manualmente para cada usuario/buzón compartido. Hay que tener en cuenta que no es válido para grupos de Microsoft 365. Para ello seleccionamos un usuario y editamos sus opciones:

buzon_office365

Y añadimos la cuenta definida más arriba en el apartado de autenticación de la TX SCOT:

Delegacion_buzon

Con ésto ya estaría el sistema listo para enviar correos desde SAP haciendo uso del servicio Microsoft 365.

Resumen

En apenas unos pocos pasos hemos configurado la integración del correo saliente Microsoft 365 en SAP con seguridad TLS y comprobación del certificado.

Próximamente configuraremos el correo saliente.

JavaSupportTool

SAP NW Java Support Tool

SAP NW Java Support Tool 637 466 SAPMiN

Como continuación al artículo que tratábamos la instalación de parches en una instancia Java sin necesidad de la herramienta SUM, en esta ocasión detallaremos el propósito y funcionamiento del componente SAP NW Java Support Tool (info: SAP Note 2352717 – SAP NW Java Support Tool).

Este software nos permite conectarnos a una instancia Java y realizar las siguientes tareas:

  • Recopilar traces y logs para un análisis detallado de problemas, y poder enviar el resultado al soporte de SAP en caso de ser necesario
  • Identificar el último nivel de parches disponibles para la instancia y resolver las dependencias entre componentes para poder instalarlos, proporcionando los links de descarga directos, pudiendo añadirlos al download basket directamente.
  • Grabar la pantalla mientras se reproducen los errores

Esta herramienta que puede descargarse aquí, está escrita en Java, y puede ejecutarse en cualquier equipo que cumple con las siguientes especificaciones:

  • JRE 1.7 o superior
  • Acceso a Internet para descarga de información desde el portal de SAP
  • Acceso al puerto 5XX14 de la instancia Java a la que queremos conectarnos
  • Las releases Java a las que se puede acceder son 7.10 en adelante, aunque para versiones anteriores también se pueden desplegar una serie de ficheros .jar y hacer funcionar la app

Cómo funciona

Una vez descargado el fichero, lo descomprimimos, y extraemos NWJavaSupportTool.jar. Para ejecutarlo necesitaremos una versión JRE 1.7 o superior y podemos lanzarlo mediante el siguiente comando:

java -jar NWJavaSupportTool.jar

A continuación aparece la pantalla de login a la instancia Java a la que nos queremos conectar:

JavaSupportTool_Login

Introducimos los datos de conexión y aparecen las siguientes opciones:

JavaSupportTool

Exception

Este apartado nos permitirá grabar un vídeo con lo que suceda en la pantalla principal de nuestro equipo quedando registrados los posibles errores que se den en la instancia:

JavaSupportTool_Exception

Hanging/Crashing

Esta opción nos permite recopilar toda la información del estado del entorno Java para poder enviárselo a SAP y/o analizarla de forma local. El contenido de la información recopilada se ofrece al usuario antes de realizar el envío.

Expert

Esta sección nos permitirá entre otros revisar todos los ficheros de log y trace de la instancia, generar un dump de los procesos server, o verificar los componentes instalados y versión de los mismos

JavaSupportTool_Expert

SC Patch Tool

Posiblemente una de las opciones más interesantes. Tras iniciarla, nos pedirá un usuario y contraseña de acceso a la web de soporte de SAP:

JavaSupportTool_PatchTool JavaSupportTool_PatchTool2

Recomendamos utilizar un usuario técnico para hacer login en la herramienta. A continuación nos aparecerán los componentes con las versiones de parches instalados y últimos disponibles:

JavaSupportTool_PatchTool3

Podemos seleccionar varios componentes, y pulsar el botón Check para chequear todas las dependencias necesarias para poder instalar el último nivel de parches disponible:

JavaSupportTool_PatchToolFin

Nos aparecen en un listado todos los componentes y niveles de parche a instalar. Si pulsamos cada uno de ellos, nos llevará al enlace de descarga de cada uno de ellos, y si los seleccionamos podemos incluirlos en el download basket para una posterior descarga con SAP Download Manager:

JavaSupportTool_Down

Esperamos que podáis sacarle partido.

Si tienes cualquier duda del funcionamiento de la herramiente SAP NW Java Support Tool, déjanos aquí tus preguntas o comentarios.

Instala parches en Netweaver Java sin utilizar SUM

Instala parches en Netweaver Java sin utilizar SUM 419 290 SAPMiN

Instala parches en Netweaver Java sin utilizar la herramienta SUM

Es muy posible que se os haya presentado en alguna ocasión la circunstancia de tener que instalar un parche para, por ejemplo, subsanar una vulnerabilidad de seguridad en un entorno Java, como el Solution Manager, el portal, etc. y que hayáis pensado en el esfuerzo que tiene hacerlo mediante el SUM (Software Update Manager) de SAP, y se os hayan pasado las ganas de actualizar nada. Si es así, la entrada de hoy os será de gran utilidad.

Hagamos un poco de memoria: a lo largo del año 2013, ha llovida bastante ya, SAP dejaba de soportar la instalación de parches en los entornos J2EE mediante el JSPM. Esta herramienta permitía, por ejemplo, instalar parches individuales de forma rápida y efectiva, mediante unos pocos clicks. De 2013 en adelante la herramienta “obligada” para las actualizaciones es la SUM.

Esta decisión provoca que cualquier actualización dentro de una instancia Java, ya sea un parche, ya sea un sp-stack completo, se eternice, y nos haga pasar a través de un montón de pasos, como si de un upgrade se tratara.

Además del Java Support Tool, que hablaremos en otro post, os presentamos una forma más directa aún de instalar los parches de forma manual, a través de telnet. Adelante, manos a la masa!

Lo primero de todo, como es costumbre, consistirá en asegurar que tenemos un backup de la BBDD por si acaso. Seguidamente descargamos el parche en cuestión:

Por supuesto, deberemos comprobar si existe alguna dependencia de otros componentes y/o versiones de parches. En caso afirmativo los descargaremos, y volveremos a verificar sus posibles dependencias de forma recursiva, hasta asegurar que contamos con todos los parches necesarios para que el update sea consistente:

A continuación subimos los parches a una carpeta del servidor

Creamos un fichero .txt que contenga el nombre y la ruta absoluta de los parches que vamos a instalar, por si acaso los ponemos en el orden exacto en el que los queremos importar:

Nos conectamos a la consola de administración vía telnet a la dirección localhost 5xx08, donde xx es el número de instancia de la pila Java y hacemos login con el usuario administrador

Listamos los nodos disponibles con el comando lsc, y nos dirigimos a uno de ellos con la instrucción jump id_nodo, lanzamos el comando add deploy y por último ejecutamos:

deploy list=unidad:\usr\sap\XXX\tmp\parches\parches.txt version_rule=all on_prerequisite_error=stop donde el parámetro list se corresponde con la ruta absoluta al fichero que hemos generado en el paso anterior, y que contiene las rutas absolutas a los ficheros de todos los parches que queremos instalar.

En caso de que alguno de los componentes tenga que desplegarse en modo offline, se desconectará la sesión de telnet. Nos volveremos a conectar de nuevo, una vez esté levantada y disponible la instancia, y lanzaremos el comando get_result para comprobar la finalización del proceso.

Verificaremos que todos los componentes se han actualizado adecuadamente:

En ocasiones nos hemos encontrado, sobre todo en entornos Windows, que al realizar el despliegue de tipo offline, la pila Java no levanta pasado un tiempo, cuando debería hacerlo para finalizar la actualización. En estos casos habrá que revisar los logs de los procesos principales para determinar la causa del problema.

¿os habéis encontrado algún inconveniente al utilizar este u otros métodos de actualización?

Déjanos tus comentarios aquí 😉

sapgui_fondo_rojo

SAPGui: Asignar diferente color de fondo para cada entorno

SAPGui: Asignar diferente color de fondo para cada entorno 761 285 SAPMiN

Problemática

Estás trabajando en SAP, con conexiones a varios sistemas diferentes, y con unos cuantos modos en cada una de ellas, y de repente, lanzar una transacción/acción en uno de ellos, y te das cuenta de que lo has hecho en la instancia equivocada.

Comienzas a borrar una serie de datos, cuando de repente ves que lo estás lanzando en producción, cuando creías que lo estabas haciendo en el entorno de calidad.

¿te suenan estas situaciones? ¿te han sucedido en alguna ocasión?

Solución

A continuación te enseñamos un pequeño truco que seguramente te será de gran ayuda. Desde hace ya unas cuantas versiones de SAPGui es posible asignar a cada sistema un color de fondo determinado, de tal forma que podemos configurar el entorno productivo un color de fondo rojo por ejemplo, que nos alertará cada vez que pongamos el foco en un modo correspondiente a este sistema.

Para activar esta configuración basta con hacer login en el sistema deseado y abrimos el botón de opciones del SAPGui que tiene este icono   sapgui_options

y pulsaremos Options. A continuación se desplegará una ventana, y deberemos selección el siguiente path:

Visual Design → Color settings → Colours in System

Como podemos apreciar en la imagen anterior, tenemos unos cuantos colores para elegir. Por si fuera poco, la configuración de diferentes no sólo es aplicable a un sistema, sino que es posible definir diferentes colores para cada mandante en cada uno de los sistemas.

Por ejemplo, configuramos en color rojo para el fondo del entorno de producción, y observamos los resultados:

sapgui_fondo_rojo

Los diferentes temas del SAPGui nos ofrecen una amplia gama de posibilidades. Por ejemplo, seleccionando el tema Enjoy es posible elegir entre los siguientes colores o combinaciones:

Recordatorio: Como de costumbre os recomendamos actualizar la release del SAPGui a la última versión soportada, y con un parche lo más reciente posible. Actualmente sólo se encuentra soportada para Windows la versión 7.60, y la 7.50 en su modalidad Java. Podemos encontrar el roadmap para este componente en la siguiente nota:

147519 – Maintenance strategy / deadlines for SAP GUI for Windows / SAP GUI for Java

Esperamos que este pequeño truco os sea de utilidad y que nadie vuelva a equivocarse de sistema al lanzar las tareas 🙂

¿tienes alguna duda? Si podemos ayudarte no tienes mas que contactar con nosotros a través del siguiente enlace.

  • 1
  • 2