Análisis DEBUG de errores de Autorización

[dairolozano]

Muchas veces recibimos errores relacionados con autorizaciones aunque no siempre el mensaje es tan claro como para poder analizarlo.  Como primera medida, si en el texto del mensaje de error vemos una frase como “Usted no tiene autorización para.. “ o “Falta autorización para.. ” entonces lo más probable es que se debe a una validación de un objeto de autorización sobre el cual no tenemos los permisos necesarias para la actividad.

Un ejemplo típico es el siguiente:

Aquí el mensaje es bastante claro, No tenemos acceso a la transacción MM01 por lo cual hay que tramitar la solicitud de acceso justificando la razón por la cual lo requerimos.

Sin embargo en otras ocasiones el mensaje no es tan explícito, por ejemplo:

En estos mensajes es claro que no tenemos autorización para consultar o modificar cierta información, pero ya no es tan fácil identificar cual es la autorización que debemos solicitar.

Bueno, en primer lugar debemos verificar si se trata de un objeto de autorización para el cual no tenemos las credenciales necesarias. Esto se puede verificar fácilmente mediante la transacción SU53.

En esta transacción podemos identificar que nos hace falta la autorización para la Actividad 02 del objeto S_USER_GRP.  Con esta información podemos solicitar los permisos correspondientes si alguna de nuestras tareas depende de que tengamos esta autorización.

Supongamos que ahora necesitamos saber exactamente en qué momento durante la ejecución de la transacción se genera el chequeo de autorización.  Esto es útil por ejemplo si se trata de una transacción Z o una modificación en una transacción estándar (EXIT, BADI, Etc).  Esto lo podemos hacer activando el modo debug, de forma similar a como se explica en el blog:

Para nuestro ejemplo supongamos que pretendemos modificar el usuario FTEST mediante la transacción SU01.  Entramos a la transacción, escribimos /h en la línea de comandos y presionamos ENTER.

Posteriormente escribimos el nombre del usuario y presionamos el botón del lápiz para modificar.  Una vez se active el debugger seleccionamos las siguientes opciones del menú BREAKPOINTS

Aquí digitamos la sentencia AUTHORITY-CHECK, que es la que ejecuta las validaciones de objetos de autorización.  Luego presionamos ENTER o el botón de aceptar.

Presionamos F8 para que continúe la ejecución de la transacción, la cual se detendrá justo en el momento en que se realice un chequeo de autorización.

Aquí vemos que la ejecución se detuvo en la línea 71 donde se válida que se tenga autorización en el objeto S_USER_GRP para la actividad 02 sobre la clase PRUEBA.  La actividad 02 corresponde   a modificación por lo cual esta sentencia se podría traducir como Autorización para modificar la clase PRUEBA.

En la imagen anterior, se puede observar también que se han creado Breakpoints diferentes para cada sentencia AUTHORITY-CHECK que se ejecuta dentro de la transacción, de modo que podría ser posible que haya otras validaciones a la que nos está generando el problema. En este caso al presionar F8 la ejecución continuara sin generar mensaje de error hasta llegar a la siguiente validación que se haga mediante la sentencia AUTHORITY-CHECK.

Muchas gracias por su atención y espero que les sea de utilidad.