✒️SAP BASIS La administración de usuarios con CUA
SAP BASIS La administración de usuarios con CUA
6.5 - Administración de Usuarios con CUA
Veremos cómo es la administración de usuarios, una vez activado CUA.
Los usuarios se siguen administrando desde la transacción SU01, pero existen algunos cambios, ya que por ejemplo, los usuarios solo pueden ser creados desde el sistema central.
En el sistema central en la pantalla inicial de SU01 podremos ver las mismas funciones que teníamos antes de activar CUA. Vamos a crear ahora un nuevo usuario.
Las solapas que tendremos disponible para la creación del usuario son las mismas, a excepción de algunos cambios y la nueva solapa Systems. Ingresamos una contraseña inicial, la cual será válida en todos los sistemas hijos donde creemos el usuario.
En la solapa Systems ingresaremos todos los sistemas hijos en donde queremos crear el usuario cuando mantenemos el usuario.
Si quitamos un sistema hijo desde esta solapa, lo que estamos haciendo es eliminar el usuario del mandante hijo.
A pesar de que la administración se realiza desde el sistema central, si queremos crear un usuario en ese mismo mandante, deberemos explicitarlo en la lista de sistemas en la solapa Systems.
En la solapa roles, ahora tendremos una nueva columna con el nombre del sistema donde estamos creando el rol, es decir, de esta manera un usuario puede tener diferentes roles en distintos sistemas hijos y en el mismo sistema central también.
La función Text Comparison From Child Sys obtiene los nombres de los roles que existen en los sistemas hijos hacia el sistema central, de esta forma podremos hacer la asignación de roles.
En el campo receiving system. Ingresamos el nombre del sistema central y luego ejecutamos.
De esta manera sincronizamos los nombres de los roles, desde los sistemas hijos hacia el sistema central. Cabe destacar que la función obtiene los nombres de los roles que existen en los sistemas hijos y no los roles en sí mismos. De esta forma podremos hacer la asignación desde el sistema central.
De esta manera realizamos la asignación de roles independiente por cada sistema hijo y el mismo sistema central, si es que fuera necesario. Agregaremos ahora algunos campos adicionales para ver cómo se comporta os atributos de distribución hacia los sistemas hijos.
Por último, guardamos el usuario, de esta forma se crearán en los sistemas hijos y en el sistema central para este caso.
Veamos ahora cómo cambia el comportamiento de la función de cambio de contraseña.
Como podemos ver ahora, esto es independiente por cada sistema hijo donde existe el usuario.
Por lo que deberemos seleccionar primero en qué sistema es donde queremos hacer el cambio de contraseña para el usuario. La función de bloqueo y desbloqueo ahora nos permite realizar. Un bloqueo global para todos los sistemas donde existe el usuario o un bloqueo local en el mandante donde estemos logueados.
Recordemos que en la transacción SCUM hemos seleccionado los atributos. Para la distribución de los campos del registro maestro de usuario.
Veamos ahora qué opciones tenemos para el mantenimiento del usuario en el sistema hijo. Podemos ver también que las funciones en la pantalla inicial para crear y borrar usuarios ya no aparecen en el sistema hijo.
Podemos ver que no todos los campos son modificables ahora en el registro maestro de usuario. Realizaremos modificaciones para ver cómo se comportan según el atributo que tenga cada campo.
La solapa sistemas no aparecen los sistemas hijos y en la solapa roles solo veremos aquellos roles que están asignados para el mandante donde estamos modificando el usuario.
También podemos ver que la información sobre la última modificación la realizó el usuario del sistema de la conexión RFC, que va desde el sistema central a este sistema hijo.
Bien, ahora volvemos al sistema central para ver si los cambios que realizamos en el sistema hijo afectaron a la información en este sistema. Como podemos ver acá, la información no fue alterada.
Los atributos de los campos que hemos elegido eran de tipo proposal, por lo que ahora cada mandante administrará de forma local esos campos, ahora modificaremos un campo que tiene el atributo global en la transacción scum.
Regresamos una vez más al sistema hijo la transacción SU01. En este caso, como el atributo era de tipo global para el campo first name. Vemos que en el sistema hijo también se ha modificado.
Sobre el autor
Publicación académica de Israel Cespedes Penaloza, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
SAP Senior
Israel Cespedes Penaloza
Profesión: Ingeniero Electrónico - Bolivia - Legajo: DO67A
✒️Autor de: 90 Publicaciones Académicas
🎓Cursando Actualmente: Consultor BASIS Nivel Avanzado
🎓Egresado del módulo:
Disponibilidad Laboral: PartTime
