Introduction:
Usin
g Central User Administration, you can maintain user master records centrally in one system. Changes to the information are then automatically distributed to the child systems. This means that you have an overview in the central system of all user data in the entire system landscape.
Distribution of the data is based on a functioning Application Link Enabling landscape (ALE Landscape). In this way, data can be exchanged in a controlled manner and is kept consistent. An ALE System Group is used by the Central User Administration to distribute user data between a central system and child systems linked by ALE. You should therefore familiarize yourself with basic information about the ALE Integration Technology.Benefits of Central User Administration
· Administration of a whole system landscape from one single central system
· Overview of all user data in the whole system landscape
· Consistent user data in the whole system landscape
· Additional local maintenance is still possible
· Requires little resources (hardware and/or diskspace)
· Consistent user master data in the whole system landscape
· One single point of administration and control
Disadvantages
- Maintenance of CUA central system has immediately impact on production –no test of CUA functionality possible
- Unavailability of CUA central system has impact on the whole system landscape
- Planned downtime of CUA central system has to be confirmed by all system owners
- High volume of user data and high number of changes to user master records (e.g. caused through client copy in DEV) can result in decrease of performance of the CUA central system
- Not suitable for customers where responsibilities for user administration are organizationally split based on systems
Pre Requisite
· You have defined logical systems. You can see list of logical system names from SCC4.
· RFC Connections are created between central and child systems.
· User ID used in all the system is ADM_CUA and this users is a communication user Authorization for Central system SAP_BC_USR_CUA_SETUP_CENTRAL and SAP_BC_USR_CUA_CENTRAL.
· Authorization for Client system SAP_BC_USR_CUA_SETUP_CLIENT and SAP_BC_USR_CUA_CLIENT.
Architecture
Central User Administration consists of Central System and child systems. The central system sends data to the child systems and each child system also sends data to the central system.
Setting Up CUA
Go transaction code BD64 and create a model view
Create the new model and SAVE it. After this you need to BAPI to created model view and input parameters as shown below. Give your sender and receiver systems logical systems names.
Generate partner profiles for CUA by selecting Generate Partner Profiles from Environment Menu.
After successful profile generation distribute model view. This will distribute CUA across the child systems.
Follow above same steps in admin and child systems. After configuration is completed in both systems go TCode SCUA in admin system.
u
Create a distribution model and input receipent system.
After successful configuration you can see system tab in su01 of any user. Here you can maintain user system and and his assignments centrally.
Deactivating CUA
Procedure in the Central System
1. Log on to the central system.
2. Run report RSDELCUA (for example, using transaction SA38).
The system displays the screen Delete Entire Central User Administration. The name of the distribution model is displayed under Central User Administration.
3. In the Delete section, choose the Complete CUA, and set the Test indicator. Then choose Execute. The system displays an overview of the data to be deleted. You can jump to transaction SE16 by double clicking.
4. If you are happy with the test result, choose Back and deselect the test indicator. Then choose Execute. The system displays an overview of the deleted data.
5. In transaction WE20, delete the data about the sending system (central system) and the receiving systems (child systems); that is, under Partner profile for Partner type LS, delete the message types CCLONE and USERCLONE (such as ADMCLNT324 and PRDCLNT324) for the central and child systems. If this means that only the default message type SYNCH remains, you can also delete the partner profiles completely.
6. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing Business Processes ® Maintain Distribution Model and Distribution Views (transaction BD64).
a. In change mode, select the model (in this example, CUA), and choose Delete.
b. Choose Save.
7. Change the system user (such as CUA_PRD) in transaction SU01 by removing the role Z_SAP_BC_USR_CUA_CENTRAL on the Roles tab page. If this means that the user is now assigned absolutely no authorizations, you can assume that it is not used for any other purpose, and can delete it.
Procedure in Child System
1. Delete the data for the sending system (central system) in transaction WE20.
If only the automatically created message type SYNCH remains, you can completely delete the partner profile. However, "empty" partner profiles of this type do not cause any disruption. If other message types are still entered, the partner profile is still being used in other ways, and may not be deleted.
2. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing Business Processes ® Maintain Distribution Model and Distribution Views (transaction BD64).
3. In change mode, select the model (in this example, CUA), and choose Delete.
If the system does not now display a dialog box asking: Model view CUA may not be changed in this system. Delete CUA?, perform the following steps:
a. Call the Edit model view dialog screen by double clicking the model.
b. Change the Maintenance system to the local system name (in this example, PRDCLNT324).
c. Choose Continue.
d. Choose Delete again.
e. Confirm the system query Model view CUA may not be changed in this system. Delete CUA? with Yes.
4. In the child system, change the system user (such as CUA_PRD_324) in transaction SU01 by removing the role Z_SAP_BC_USR_CUA_CLIENT on the Roles tab page. If this means that the user is no longer assigned any roles or any profiles, you can assume that it is not used for any other purpose, and can delete it.
As the RFC destinations that you created along with CUA may be used for other ALE connections, you should not delete the RFC destinations, but rather only remove the roles with CUA authorizations from the system user used for CUA.
Resources
http://help.sap.com/saphelp_nw2004s/helpdata/en/bf/0b13bb3acd607e10000000a11402f/content.htm
SAP Tutor Central User Administration under service.sap.com/security → Education and Workshops
Facebook
