autorizaciones

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