CUA- Installation

IntroductionClients with very complex landscape with multiple landscape and multiple clients, maintaining the entire environment become very challenging. Using Central User Administration (CUA), you can maintain user mater 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.

Central User Administration (CUA) data is distributed asynchronously between the application systems in an ALE environment. This ensures that it still reaches the target system even if it was unreachable when the data was sent.

One system in the Central User Administration (CUA) ALE environment is defined as the central system. The central system is linked with every child system in both directions. The child systems are not linked to each other, with the exception of the central system, which is itself a child system, from the point of view of Central User Administration.

Setting Up Central User AdministrationTo set up Central User Administration (CUA), perform the procedures described below.

Steps to Set Up the CUA

• Specify Logical Systems• Assign Logical Systems to a Client• Create Communication Users (ADM_CUA)• Create RFC Destinations• Set Distribution Parameters for Fields• Synchronize• Company Addresses• Create CUA• Transfer Users

Setting Up Logical Systems

Systems of the Central User Administration (CUA) are referred to using logical

system IDs. A logical system is a client. Therefore you must first set up logical system names that you then assign to the clients in the SAP systems.

Communication Users and RFC Destinations

This section provides you with an overview of the interaction of communication users, RFCdestinations, and authorization roles of the communication users and the administration tasks that are connected with this. The exact procedure is described in the following sections. Communication users are required for the internal communication of the systems in an ALE group (the distribution of user data). These communication users, defined in the target systems, are entered in RFC destinations in the calling systems. To increase the security of your system landscape, when you are creating communication users, assign only greatly restricted authorizations, as described below to the communication users.

User ID used in all the system is ADM_CUA and this users is a communication user

Authorization for Central systemSAP_BC_USR_CUA_SETUP_CENTRAL andSAP_BC_USR_CUA_CENTRAL

Authorization for Client systemSAP_BC_USR_CUA_SETUP_CLIENT andSAP_BC_USR_CUA_CLIENT.

Setting Up Field Distribution Parameters

If you are using Central User Administration, you can use the distribution parameters intransaction SCUM to determine where individual parts of a user master record are maintained.

• In the central system• Locally in the child system• In the child system with automatic redistribution to the central system and the otherCUA child systems

Every input field of the user maintenance transaction SU01 has a field attribute that you setonce in the central system with transaction SCUM during Customizing. As far as

possible, youshould then not change the field maintenance indicator at all.

If you later change the distribution from Local or Proposal to Global or Redistribution, data inconsistencies can occur. When resolving these inconsistencies you must proceed with the utmost care. Otherwise data losses will occur.The only exception to this is the Locks tab page. You can change the indicatorson this tab page at any time without any risk.

Procedure

• Log on to the central system • In the Implementation Guide (IMG, transaction SALE), choose Modeling

and Implementing Business Processes → Predefined ALE Business Processes → Cross- Application Business Processes → Central User Administration → Set Distribution Parameters for Fields (transaction SCUM).

The system displays the User Distribution Field Selection screen, with tab pages of the fields whose distribution parameters you can set. To display additional fields, choose page down.

You can select the following options on the tab pages:

Global You can only maintain the data in the central system. The data is then automatically distributed to the child systems. These fields do not accept input in the child systems, but can only be displayed. All other fields that are not set to “global” accept input both in the central and in the child systems and are differentiated only by a different distribution after you have saved.

Proposal You maintain a default value in the central system that is automatically distributed to the child systems when a user is created. After the distribution, the data is only maintained locally, and is not distributed again, if you change it in the central or child system. RetVal You can maintain data both centrally and locally. After every local change to the data, the change is redistributed to the central system and distributed from there to the other child systems.

Local You can only maintain the data in the child system. Changes are notdistributed to other systems.

Everywhere You can maintain data both centrally and locally. However, only

changes made in the central system are distributed to other systems, local changes in the child systems are not distributed.

• To maintain the other parameters, too, switch to the other tab pages. The tab pages correspond to those of user maintenance.

• Save your entries.

The distribution parameters are automatically transferred to the child systems.

Address tabTitle, Language and Printer are setup for Retval, rest are setup to Global

Logon dataInitial password is set to Proposal, and rest is set to Global

Default All attributes set to RetVal Parameters All attributes set to RetVal

Profiles/ Roles All attributes set to Global

Lock Unlock incorrect logon is set to Local

Transferring Users from New SystemsIf you include a new system in the distribution model selected, you must make sure that the user master records in the new system are transferred to the central system.

PrerequisitesYou have synchronized the company addresses.

Procedure

• Log on to the central system• In the Implementation Guide (IMG, transaction SALE), choose Modeling

and Implementing → Predefined ALE Business Processes → Central User Administration → Transfer Users from New Systems (transaction

SCUG). The system displays the Central User Administration Structure Display screen with a tree structure of the systems of the distribution model. The systems with New indicators contain user master records that are not contained in the Central User Administration.

• If you are setting up a completely new Central User Administration, place the cursor on the central system and choose Transfer Users.

The system displays the following tab pages:

New users These users are not yet contained in Central User Administration. By choosing Transfer users, you can transfer the selected users into the central system. This transfers all user parameters such as address and logon data, as well as profiles and roles. In the future, the user will be maintained centrally.

Identical users These are users with identical user IDs (that is, theirname and user name is the same). The roles and profile data for this user can be transferred to the central system. The user is then distributed andtherefore appears as it is stored in the central system. Local data is overwritten.

Different users These user IDs are contained in both the central and the child systems, but with different data. If in a single case, the users are actually the same user, you can transfer the roles and profile data for the user to the central system. The user is then distributed as it exists in the central system. If these are two different users, create a new user ID for one user in the central system, and delete this user in the child system.

Already central users These users are already in the Central User Administration under the same name and are maintained centrally.

• Select all new and changed users and choose Transfer Users.• Perform steps 3 and 4 successively for all child systems from which you

want to transfer users. • After you have completed the user transfer, remove the roles

SAP_BC_CUA_SETUP_CENTRAL and SAP_BC_USR_CUA_SETUP_CLIENT from the communications users.

• These roles are only required to set up the CUA, but not for its operation. By restricting the authorizations of the communications users to the minimum level, you increase the security of your system landscape.

• Use transaction SCUL to check the distribution of the users after the transfer.

Operating Central User AdministrationThis section combines information that affect functions that have special features

when youare using Central User Administration (CUA)

User Maintenance with Active Central UserAdministration

With active Central User Administration, you still use transaction SU01 to maintain users,however user maintenance is somewhat different:

• Whether fields are ready for input or not depends on the distribution attributes that you assigned to the field in transaction SCUM. Only the fields that may be maintained in the system are ready for input. You can only change a field that is to be maintained globally in the central system. This field does not accept input in the child systems.

• In the central system, the user maintenance transaction also displays the tab page Systems. Here you enter the systems to which users are to be distributed. To display the systems for the corresponding distribution model, use the possible entries help. Each time you save, the system distributes the user data to these listed systems.

• The Roles and Profiles tab pages each contain an additional column for each entry, specifying the system for which the user is assigned the role and/or profile. With the Text comparison from child sys. Pushbutton on the Roles and Profiles tab pages, you can update the texts for roles/profiles that you have changed, for example, in the child systems. The texts in the child systems are stored temporarily so that they are available in the central system. As the comparison requires some time, it is performed asynchronously and the current texts may not be available immediately. You can only assign profiles to users for the systems in which they are distributed. If you enter a new system when you assign profiles to users, the system displays a warning that the user was assigned a new system. The entry is automatically transferred into the tab page Systems. After this, the user master record is also distributed in the new system.

All user master records are created in the user master records. Users can then only log ontothe central system if the central system itself is entered in Systems tab page of the

corresponding user master record.

Performing a Text Comparison with Target SystemSpecification

If you have created, deleted or imported roles and/or profiles in a child system of the CentralUser Administration (CUA), there is initially a different data status in the central and childsystems. You do not need to perform a text comparison for all child systems, but can clean upthe data specifically for the affected child system as follows:

• In the central system, you use transaction SU01 to execute the Text Comparison from Child System function and specify the changed child system as the target system.

• You send the changed role data from the child system in which you have made the role maintenance (transaction PFCG) changes, to the central system. To do this, choose Environment → Text Comparison for CUA Central System in transaction PFCG of the child system.

CUA- Tips

Access to the configuration of Central User Administration (CUA) transactions should be controlled. Consideration should be given to restricting access to only relevant user administration staff to the following CUA Maintenance transactions.

CUA Tcode Name and Description

SALE Display ALE Customizing Used to configure the ALE environment for CUA. This transaction also allows access other ALE and Remote Function Call (RFC) configuration.

SCUA Central User Administration Transaction used to maintain the CUA landscape.

SCUL Central User Management Log Transaction used to view CUA audit and error logs.

SCUM

Central User Administration Transaction used to define field distribution for CUA.

Removing Central User Client

Log on Central system and run report RSDELCUA to remove one or more child systems.

• Execute WE20 and select Partner Type LS. Delete message types CCLONE and USERCLONE for the selected child system.

• Delete the complete partner model.• Execute transaction BD64. In change mode, delete the methods for the

deleted child and save the entries.

Then log on to every child system to be deleted.

• Run report RSDELCUA on the child system.• In WE20 if there are any inbound parameters for the child client, delete

them.

• Once this is done the complete partner profile can be deleted. It is not recommended to delete the RFC destinations but rather remove CUA administrative access from the communication user’s role.

CUA- Tips

Troubleshooting CUA

• Check the logs. - SCUL Central User Management Log

Except for the logs for distributing users and company addresses, you can also display the logs for terminated tRFC calls (transaction SM58). With transaction SCUL.

• WE20 Change Partner Profiles

• WE21 Port definition• WE09 iDoc search for contents (database)• WE10 iDoc search for contents (archive)

You can call this in the central system and in the child systems. Filter for Basis type USERCLONE*

• WE02 or WE05 IDOC display and update status display call in the central system as well as in the subsystems. Select the CCLONE message type and transaction USERCLONE. The transaction must be called in the source and target system. Caution: The number of outbound IDOCs and inbound IDOCs are not identical.

• BDM2 IDOC tracing

Call this in the central system. Transaction BDM2 produces a link between the outbound IDOC number and the inbound IDOC number and can also start the IDOC display in both systems.

• BDM5 Technical Consistency Check

You can call this in the central system and in the child systems.With transaction BDM5, check the technical consistency of the partner profiles (also cross-system).

• BD87 manual processing of IDOCs

For example, you resend IDOCs that remain in status 03.The correction instructions contain the report ZCUA_DELETE_IDOC that you can use to delete IDOCs without checking by the database. (You must therefore delete this report after use.This transaction can also be used for updating with debugging. Incoming IDocs are then stopped and can be updated manually with BD87 (debugging breakpoint on function module BAPI_USER_CLONE).

• SM58 Transactional RFC

Shows the BD87 error message for the tRFC (for example, IDoc entries in the tRFC queue) so you can analyze with SM58 which error occurs with the RFC (for example, for missing authorizations of the service user with which the IDocs are received in the target system): 'User CUAADMIN has no RFC authorization function group ERFC')

Authorizations of the communication users

The minimum authorizations for the communication users of the CUA are

described in note 492589.If a communication user in a subsystem is missing authorizations for the S_RFC authorization object (or S_RFCACL if using Trusted RFC), the tRFC call terminates. You can display logs for this as well as other tRFC errors using transaction SCUL or SM58. CALL_FUNCTION_SINGLE_LOGIN_REJ dumps (and CALL_FUNCTION_SYSCALL_ONLY dumps if using Trusted RFC) occur in this case in the daughter system, which you can display using transaction ST22.The authorization check on S_RFC is activated with the auth/rfc_authority_check profile parameter.Generating dumps with RFC logons that fail is defined with the rfc/signon_error_log profile parameter.

User groups for the authorization check

Transaction SCMP allows you to compare the table contents of different systems. For the user groups, these are tables USGRP and USGRPT (texts). Unfortunately a comparison is not possible. Use transaction SUGR to implement missing user groups in the central system.

Consistency check for role assignments

With the report ZCHECK_USLA04, which is contained in the correction instructions, you receive a list of all role assignments whose roles do not exist in the target system. The users affected must be revised with SU01.(See also table EDIDC messages to 01 49)

Counting profile assignments

A maximum of 312 profile assignments may exist for one user, while you may have several profile assignments for one role assignment.You cannot check this limit in the central system.You can only count profile assignments in the child system.Alternatives in the child system:

1. SE16 for table USR04For the NRPRO field, the following is valid: NRPRO = 2 + 12 * n with n=number of profiles. With the selection NRPRO > 3000, you get all users with at least 250 profiles (max. number that can be assigned is 312).2. Report RSUSR002 of the user information system SUIM displays the profile assignments.3. After report RSUSR002 has run at least once with some sort of selection, shadow table UST04 is up to date and can be evaluated with transaction SE16.

ST05 Enqueue and RFC trace

With the enqueue and RFC trace, you can analyse the flow of IDOC updates.To do this, log on to the application server specified in the RFC destination of the central system for the child system (the workload distribution should not be active).Optional filtering criteria for the ST05 trace output:User: Logged on users in the central system;RFC users of the RFC destination; Background user Object name: ES_EDIDOCE E_USR04

Unfortunately, the last character of the lock argument is sometimes truncated for the enqueue trace output.This is particularly impractical for IDOC numbers because you cannot identify the IDOC that has just been processed.

Transaction PFUD = Report PFCG_TIME_DEPENDENCY -> Start report RHAUTUPD_NEW

During updating of IDOCs, the user master comparison is started automatically. Nevertheless, the PFUD should run at night because this is when the static profile assignments are determined from the time-dependent role assignments.Enhanced consistency checks and corrections are also carried out (Remove the profile assignments of deleted roles, delete generated profiles and authorizations that are no longer used).You can search for the message "No authorization profiles for activity group.......available" in the job log. These roles must be checked.

Company address

Maintain with transaction SUCOMPThe company address is distributed through Change+Save.