✒️SAP BASIS / La administración de usuarios con CUA Por Luis Caro Montañez
SAP BASIS La administración de usuarios con CUA
Unidad 6.Administracion de usuarios con CUA
Con la administracion de los usuarios, una vez activado el CUA, en donde notaremos que la administracion se sigue realizando desde la transaccion SU01 pero con algunos cambios propios de la configuracion que hemos realizado. Veremos como configurar un usuario y asignarlo a diferentes sistemas con la flexibilidad inclusive de poder asignar diferetes roles dependiendo del sistema en donde es creado.
Veremos como en el administracion de usuarios una vez que henos activado CUA, los usuarios se siguen administrando a traves de la transaccion SU01, pero existen algunos cambios ya que los usuarios solo pueden ser creados desde el sistema central.
Creamos un nuevo usuario (User Test), logon data (Initial password y Repeat password: colocamos una contraseña inicial la cual sera valida en todos los sistemas hijos donde creemos el usuario. En la pestaña System, 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 administracion se realiza en el sistema central, si queremos crear un usuario en ese mismo mandante deberemos explicitar en la lista de sistemas en la pestaña System.
En la pestaña Roles, ahora tendremos una nueva columna con el nombre del sistema donde estamos creando el rol, osea de esta manera un usuario puede tener diferentes roles en diferentes sistemas hijos y en el mismo sistema central.
La funcion Test Comparison from Child, obtiene los nombres de los roles que existen en los sitemas hijos hacia el sistema central, de esta forma podremos hacer la asignacion de roles.
En el campo Receiving system colocamos el nombre del sistema central y luego ejecutamos (icono del reloj de color verde del lado derecho), de esta forma sincronizamos los nombres de los roles desde los sistemas hijos hacia el sistema central, cabe destacar que la funcion obtiene los nombres de los roles que existen en los sistemas hijos y no los roles en si mismos de esta forma podremos hacer la asignacion desde el sistema central.
De esta manera podemos asignar los roles independiente por cada sistema hijo y el mismo sistema central si es que fuera necesario. Agregaremos ahora algunos campos adicionales para ver como se comporta los atributos de distribucion hacia los sistemas hijos, por ultimo guardamos el usuario.
De esta forma se crearan en los sistemas hijos y en el sistema central para este caso.
Veamos ahora como cambia el comportamiento de las funciones de cambio de contraseña, como podemos ver ahora esto es independiente por cada sistema hijo donde exista el usuario por lo que deberemos seleccionar 1ero en que sistema es donde queremos hacer el cambio de contraseña para el usuario. La funcion de bloqueo y desbloqueo, ahora nos permite realizar un bloqueo global a todos los sistemas donde existe el usuario o un bloqueo local en el mandante donde estemos logueados.
Recordemos que en la transaccion SU, hemos seleccionado los atributos para la distribucion de los campos del registro maestrode usuarios .
Ahora veremos que opciones tenemos para el mantenimiento del usuario del sistema hijo, podemos tambien ver que las funciones de la pantalla inicial para crear y borrar usuarios aparecen deshabilitadas en el sistema hijo.Tambien podemos ver que no en todos los campos son modificables ahora en el registro maestro de usuarios. Realizaremos modificaciones en los usuarios para ver como se comporta segun el atributo que tenga cada campo. En la pestaña sistemas no aparecen los sistemas hijos y en la pestaña roles solo veremos aquellos roles que estan asignados para el mandante donde estamos modificando el usuario, tambien podemos ver que la informacion de la ultima modificacion la realizo el usuario de sistemas de la conexion RFC que va del sistema central a este sistema hijo.
Ahora volvemos al sistema central, para ver si los cambios que realizamos al sistema hijo afectaron a la informacion en este sistema; como podemos ver la informacion no se ha alterado, los atributos de los campos que hemos elegido eran de tipo propose por lo que ahora cada mandante administrara de manera local esos campos. Ahora modificaremos un campo que tiene el atributo global en la transaccion SU, regresamos una vez mas al sistema hijo en la transaccion su01, en este caso como el atributo era de tipo global para el campo first name vemos que en el sistema hijo tambien se ha modificado.
Escanear / Compartir
Sobre el autor
Publicación académica de Luis Alberto Caro Montañez, en su ámbito de estudios para la Carrera Consultor SAP BASIS NetWeaver Nivel Avanzado.
SAP Master
Luis Alberto Caro Montañez
Profesión: Ingeniero en Sistemas - Mexico - Legajo: ML16S
✒️Autor de: 106 Publicaciones Académicas
🎓Egresado de los módulos:
- Carrera Consultor SAP BASIS NetWeaver Nivel Avanzado
- Carrera Consultor SAP BASIS NetWeaver Nivel Inicial
Disponibilidad Laboral: FullTime
Presentación:
Mi principal objetivo es formar parte de un equipo profesional, en el que los logros y éxitos de cada uno sean reconocidos en un ambiente de trabajo optimo y agradable.
Certificación Académica de Luis Caro
