✒️SAP BASIS La configuración de CUA

6.4 - Configuración de CUA

1. La configuración de CUA.

A continuación de este describirá la configuración de un CUA de un sistema, como ventajas de la utilización de CUA en nuestro landscape podemos citar que información de usuarios es administrada uniformemente en donde la administración de roles, perfiles y el maestro de usuarios, son mantenidos en el sistema central para luego distribuirse a los sistemas hijos facilitando a la vez la auditoría de los mismos.

En esta lección realizaremos una configuración de CUA en el sistema de entrenamiento. Para ello configuraremos uno de los mandantes como sistema central y el mandante creado en las lecciones anteriores como el sistema hijo.

Lo primero que tendremos que hacer, es verificar y crear los sistemas lógicos que sean necesarios.

Esto lo haremos en la transacción BD54. El nombre lógico para el mandante que utilizaremos como sistema central ya está definido. Veamos un nombre de sistema lógico para el mandante que hemos creado.

Las entradas que generemos o modifiquemos en vez de 54 serán guardadas en una orden de transport, luego deberemos importar esta orden en todos los sistemas que participen en el landscape de CUA.

En la transacción SCC4 asignaremos los sistemas lógicos a cada uno de los mandantes.

Una vez guardado, iremos a la transacción PFCG.

En la transacción de mantenimiento de roles, lo que haremos es crear los roles necesarios en base a una copia de los roles estándar para la configuración y mantenimiento de CUA.

El copiaremos cada uno de los roles estándar dentro del espacio de nombres propios. Todos los roles que necesitamos tanto para el mandante que actúa en el sistema central y los mandates hijos estarán detallados en la práctica de esta lección.

Generamos el perfil de autorizaciones para el rol que hemos creado. Asignaremos cada uno de los roles, ya sea en el sistema central o en los sistemas hijos. A los usuarios que utilizaremos para las conexiones RFC entre los sistemas.

Estos usuarios deberán ser de tipo sistemas para las conexiones RFC que van desde el sistema central a los sistemas hijos y de cada uno de los sistemas hijos el sistema central.

En cada uno de los mandantes que actuarán como sistemas hijos, también deberemos crear los roles necesarios para la configuración y mantenimiento de CUA.

Algunos roles como el que se muestra ahora solo serán necesarios para la configuración de CUA.

Podríamos quitarlos de los usuarios de sistemas que se usan en las conexiones RFC. Una vez que esté todo el landscape de CUA configurado.

En los sistemas hijos tendremos que crear una conexión RFC al sistema central, el nombre de esta conexión deberá ser exactamente igual que el nombre que le asignamos en el sistema lógico al sistema central.

La información de logon ingresaremos el usuario de sistema creado en el sistema central de central para la conexión RFC. En el mandante que actúa como sistema central, también deberemos crear una conexión RFC a cada uno de los mandantes que actúen como sistema hijo.

En este caso también deberemos respetar la Convención de nombres que usamos para los sistemas lógicos y los nombres de conexión RFC.

En los datos del logon ingresaremos el usuario del sistema creado en el mandato de que actuará como sistema hijo.

Parte II

Desde la transacción SCUA generaremos el modelo de distribución para nuestro entorno CUA.

Ingresamos un nombre para el modelo y luego el botón de crear. En la lista ingresaremos todos los nombres de los sistemas lógicos que actuarán como sistemas hijos para el ambiente de CUA.

A medida que ingresamos los nombres de los sistemas lógicos, la función verificará si la conexión remota RFC funciona correctamente. Una vez que guardamos el modelo, la función realizará una serie de pasos en el sistema central y en los sistemas hijos para activar CUA en nuestro landscape.

Desde la transacción SCUM. Podremos configurar, el comportamiento para la distribución de los campos del registro maestro de usuarios, esto quiere decir de los campos que podemos ver en la transacción SU01, se hacía en el sistema central como los sistemas hijos.

Por defecto, todos los campos están marcados con el atributo global. Esto quiere decir que solo se puede mantener desde el sistema central. El atributo proposal permite crear un valor inicial para el campo en el sistema central.

A partir de ahí, el valor es mantenido de forma local en cada uno de los sistemas hijos. Un campo con el atributo local no distribuye el valor desde el sistema central y siempre se mantiene desde los sistemas hijos para cada uno de ellos.

Desde la transacción SCUG en el sistema central, sincronizaremos las Company Address y los usuarios entre el sistema central y los sistemas hijos.

Esta actividad también es parte de la configuración de CUA, solo deberíamos realizarla en esta etapa.

Con cada uno de los sistemas hijos realizamos una comparación de Company Addresses y luego de usuarios.

Para el ejemplo seleccionaremos la Company address que existe solo en el sistema central y la enviaremos al sistema hijo. Ahora verificaremos los usuarios que sean necesarios sincronizar.

La función realiza una comparación de todos los usuarios que ya existen en el sistema central con el sistema hijo, para luego en cada solapa nos indicarán los usuarios con diferencias idénticos o nuevos usuarios que puedan existir en el sistema hijo.

Cabe destacar que una vez activado CUA, los usuarios son sólo creados en el sistema central, por lo que en el futuro no debería haber inconsistencias entre el sistema central y los sistemas hijos.

En la práctica de la lección se describe cómo se debería trabajar con cada una de estas solapas.

Ahora marcaremos el usuario que existe en el sistema hijo y aún no existen el sistema central para transferirlo a este. La Transacción SCUL nos permite visualizar los logs de las distribuciones, ya sea de Company Address y de usuarios, desde el sistema central a los sistemas hijos.

Si existieran registros sin confirmados, los cuales se indican con un icono blanco, deberá procesarse en los sistemas hijos a los cuales fueron los enviados. El procesamiento de los sistemas hijos, se realiza la transacción BD87.

Al desplegar cada una de las entradas podemos ver quién fue el recipiente para la sincronización, si el sistema hijo o el sistema central.