Register Login

Setting up Central User Administration (CUA)

Updated May 18, 2018

Setting Up Central User Administration

An ALE environment is necessary to distribute the data. It can exchange data and keep it consistent. An ALE system group is used by the central user administration to distribute user data between a central system and systems linked by ALE.

Central user administration data is exchanged 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 ALE environment is defined as the central system. The links to the subsidiary systems emanate from the central system. The subsidiary systems are not linked to each other.

Perform the following steps to setup the central user administration:

Create system users

Create a system user. A user account is required for the internal communication between the systems in an ALE group. It is only used internally for this communication and not in dialog. This user must be created in all systems in the ALE environment with the same user name and password. Assign the type System and appropriate authorizations (e.g. SAP_ALL) to the user.

Name logical systems

  1. Call the transaction SALE.
  2. Choose Prepare sender and target systems -> Create logical systems -> Name logical system.
  3. To put new logical systems in the list, choose New entries.

As the logical system table is cross-client, settings made here apply to all clients in an R/3 System. If the ALE environment only comprises the logical systems of an R/3 System, you only need to define the logical systems once. For several R/3 Systems, you must setup all logical systems in each instance completely.

  1. Enter the short name under by which the system is to be known in the ALE group, in upper-case letters under Log.system. Enter a meaningful text name for the logical systems under Name.

We recommend a combination of system name and client number for the short name. For example BIZCLNT008 was chosen for the system BIZ and client 008.

Note that you must also enter any logical systems which are not in the current R/3 System. All logical systems must be defined in each R/3 System in the ALE environment.

  1. Choose Save when you have entered all logical systems.

Naming the logical systems does not assign these logical system names to existing clients in your R/3 Systems.

Assign logical systems to clients

  1. Assign logical systems to clients in the transaction SALE under Prepare sender and target systems -> Create logical systems -> Assign logical system to a client. Mark the client to which you want to assign a logical system and choose Detail. The system displays the detail screen. In the field Logical System, enter the name of the logical system you want to assign to the client. Then save your settings. This is case-sensitive.
  2. Assign all central user administration logical systems to a client.

Define target systems for RFC calls

Define the RFC destinations for the logical systems under Prepare sender and target systems -> Configure systems in network. The remote function call is controlled by the RFC destination parameters. An RFC destination is always created from the client to which you are logged on. To define an RFC link from client 008 to client 322, you must be logged on to client 008. Central user administration RFC links must always be two-way. To define the RFC link completely, you must also logon to client 322 and define client 008 as RFC destination.

  1. Enter the RFC destination name. The name of the RFC destination should match the name of the corresponding logical system (e.g:B20CLNT323). This is case-sensitive.
  2. Specify link type 3 for links to another R/3 System.
  3. Enter the target client number under Client and the system user created at the beginning for internal system communication in the ALE environment, under User and Password. Save your entries.
  4. The top of the screen changes when you save. You can specify whether you want to use load-sharing. This is recommended but not obligatory. Choose Load-sharing ® Yes and enter the message server under Target machine and the message server system number under System number.
  5. Use the transaction RZ03 in the target system to get the target system message server name. Several servers are usually listed. The message server is the one which offers the service M. The message server name is the part of the server name before the first underline. The two-digit number at the end of the server name is the system number.

Create distribution model

When you have created the ALE environment, create the distribution model. The distribution model describes the ALE message flow between logical systems.

  1. Logon to the system which is to be the central system, and call the transaction SCUA.
  2. Create a distribution model. Enter a name and choose Create. Enter the target system in the next screen.
  3. Save your entries.

The following actions are performed automatically when you save:

  • The message flow is defined for each recipient system by specifying sender and recipient systems and the Business objects USER (create user from models in other systems) or USERCOMPANY (maintain company address) and the method CLONE.
  • The partner profiles are generated for the subsidiary systems and the central system.
  • The distribution model is sent to the subsidiary systems.

Several partner profile generation logs appear. Check whether the partner profiles were created successfully.

Save the model view again in the Maintain system environment screen to confirm the distribution model as the basis for the central user administration.

The complete distribution model is distributed automatically to all subsidiary systems when you save the model assignment for the central user administration. You cannot create any more users after distribution to the subsidiary systems. A system is now defined as central system and the other systems are subsidiary systems for the central user administration.

If the central user administration is to use another already existing distribution model, delete the model view name with the icon. Enter another name and save. The distribution model is not deleted, it is no longer the basis for the Central user Administration.

You can delete a distribution model with Distribution model ® Delete all data.

You can also send the distribution model to the subsidiary systems with the icon.

You can edit distribution models completely in the transaction BD64. You must partially perform the actions which are performed internally when you save the distribution model in the transaction SCUA manually in Releases before 4.6C, i.e., if you want to create an ALE environment for systems with different Releases, see: Setting up CUA for systems with different Releases. This contains background information if you have problems setting up the Central User Administration with transaction SCUA.

Testing Central User Administration

  1. Create a test user in user maintenance (SU01).
  2. Choose the System tab. Enter the logical name of the central system and all subsidiary systems.
  3. Choose the Roles tab.
  4. Choose Compare text from subsidiary systems. The text comparison is necessary to tell the central system the names of the roles in the subsidiary systems. You can only display and select roles from subsidiary systems in the central system from the possible entries help after this step. You cannot assign roles from subsidiary systems manually without a text comparison.
  5. Assign a role to the test user in each logical system in the system group. (Enter all logical systems in the System column and the role to be assigned to the test user in the Role column. One role per system is sufficient for testing).
  6. The distribution procedure runs automatically when you save. The user is created with its roles in all defined systems.
  7. You can check the result in the transaction SCUL.

Setting-up CUA for Systems with different Releases 

As setting up the distribution model in the simplified form with transaction SCUA is only suitable for Release 4.6C systems, the complete Central User Administration setup procedure is described below.

Perform the following activities:

  • Create system users
  • Name logical systems
  • Assign logical systems to clients
  • Define target systems for RFC calls

See Setting up Central User Administration.

Proceed as follows:

  1. Define the system environment in the SAP Reference IMG under Basis ® Distribution (ALE) ® Model and implement Business processes ® Maintain Distribution Model (Transaction BD64).

The distribution model is used to specify which applications communicate with each other in your distributed systems. The distribution model contains all of your company’s cross–system message flow information. The distribution model consists of several model views. In each model view, you can define related message flows. Each model view is maintained in a central system and distributed from there to the other systems.

For each model view, you can specify a descriptive short text, the validity period of the message flows in the view, as well as the view maintenance system. When a model view is created, the system in which the view is created is automatically specified as the maintenance system. If possible, designate one system as the central maintenance system for all model views. The names of the model views must be unique in the entire distributed environment within your company.

Do the following:

  • Choose Create Model view and enter a name and a short description.
  • Create a BAPI for the object User and the method Clone (Create user with reference from other systems). Use F4 help for possible objects and methods. Also specify which system is the sending system and which is the target system.
  • Create a second BAPI for the object UserCompany and the method Clone. This method is used for company address distribution.
  1. Distribute the system landscape by choosing Edit ® Model view ® Distribute. The system displays a dialog box in which the systems relevant for you are already selected. Normally, you can just confirm the selections.
  1. In Transaction BD64, generate the partner profiles for all dependent systems (choose Goto ® Partner profile Generate).  For information about partner profiles, see the IMG documentation (Cross-Application Components ® Distribution (ALE) ® Communication)
  2. Generate the partner profiles in all dependent systems for the central system.
  3. Define the system landscape for central user administration in the Reference IMG under Basis ® Distribution (ALE) ® Configure predefined ALE Business Processes ® Cross-application Business Processes ® Central User Administration® Select Model View for Central User Administration (transaction SCUA). Use the F4 help (possible entries) to choose the distribution model you require and then choose Save. When you save the distribution landscape, the information is automatically distributed to the dependent systems.
  4. The Central user Administration is only completely available in from Release 4.6A. Some functions are restricted in previous Releases.

After installing Central User Administration, you must check another system setting with the transaction WE20 as follows, if you use the Workplace Server:

  1. Go to transaction WE20.
  2. Display the subnodes of Partner type LS in the tree structure.
  3. Choose a system in the tree structure.
  4. Double-click on the entry USERCLONE in the table Export parameter.
  5. Change the entry basis type to USERCLONE01 in the IDOC type group.
  6. Save your changes.
  7. Do the same for the other R/3 components in the Workplace.

Setup field distribution parameters 

With a central user administration system, certain fields must be maintained centrally. It may be useful to maintain additional fields locally. If you maintain fields locally, you can decide whether these fields should be automatically redistributed.

The transaction SCUM under Basis ® Distribution (ALE) ® Model and implement business processes ® Configure predefined ALE business processes ® Cross-application business processes ® Create central user administration ® Setup field distribution parameters displays a list of fields whose distribution parameters you can set. Select a distribution model in the initial screen and save it. You go to the following screen.

By choosing Next page, you can display any additional fields.

Choose additional tab indexes so that you can also maintain the parameters of the other groups. To save your settings, choose Save. The settings are then automatically distributed to the dependent systems.

When setting up central user administration, you should try and set the individual field options you choose in this transaction only once. You should not frequently change the field maintenance flags.

Under the individual tabs, you can choose from among the following options (some options may not make sense for all tabs):

Global

Data can only be maintained in the central system and is completely distributed.

Proposal

A default value is maintained in the central system. This value is distributed when a user is created and is then maintained locally.

Redistribution

Data is maintained both centrally and locally. Each time data is changed locally, this change is redistributed to the central system and from there distributed to the other dependent systems.

Local

Data can only be maintained in the dependent system. Data changes are not distributed to other systems.

Everywhere

Data is maintained both centrally and locally. However, data changes are not redistributed to other systems.

The last tab Lock contains the following options for locking a user: you can specify that the user can only be locked/unlocked either locally or globally. For local/global unlocking, you can also choose the option Everywhere. You can also specify where a user can be unlocked following an incorrect logon.

If you make the settings for locking/unlocking users as above, a user can e.g. be unlocked globally. If the user is not unlocked in the local system, the lock still applies in the local system.

Migration of Existing Users into the Central System

If 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.

Proceed as follows:

  1. In the Implementation Guide (IMG), execute Transfer Users from New Systems (Transaction SCUG) under Central User Administration. The system displays a tree structure containing the systems in the distribution model. The systems flagged with New may contain user master records not yet included in central user administration.
  2. Position the cursor on one of these systems and choose Transfer users are:

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, their name and user name is the same). You can transfer these users into the central system. Local data is overwritten.

Different users

These users are already in central user administration but under different user IDs. Rename these users in the dependent system to the correct user name that is centrally maintained, or correct the name of the user in the user address, so the user can be transferred in the next step.

Already central users

These users are already in the central user administration under the same name. This user is already maintained centrally.

 

Central User Distribution 

You maintain users within central user administration using the user maintenance transaction (Transaction SU01). If central user administration is activated, you maintain users in the transaction differently:

  • Whether fields are ready for input or not depends on the distribution attributes that were assigned to the field in Transaction SCUM. Only the fields that may be maintained in the system are ready for input.
  • In the central system, you can only change a field that is to be maintained globally. This field is not ready for input in the dependent systems.
  • In the central system, the user maintenance transaction also displays the tab Systems. Here you enter the systems to which users are to be distributed. Use the possible entries help. The systems selected in the distribution model are displayed. Each time you save, the system distributes the user data to these listed systems.
  • The Roles and Profiles tabs each contain an additional column, specifying the system for which the user is assigned the role or profile.
  • By choosing Compare text from dependent systems in the Roles and Profiles tabs, you can update the texts for roles and profiles that were changed in the dependent systems, for example. The texts in the dependent systems are stored temporarily so that they are available in the central system. Since the comparison requires some time, it is executed asynchronously. The current texts may not be immediately available.
  • 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 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 onto the central system if the central system itself is entered in Systems tab of the corresponding user master record.

You can display global user data from a dependent system in the Infosystem.

As well as the authorizations already mentioned, you also need another authorization in the central system for object S_USER_SYS. You can only assign new systems to a new user with this authorization.

If you make any incorrect entries when you maintain roles and profiles, you can only see this in the log (Transaction SCUL).

When a user is deleted in the central system, the system entry for the user is retained until the deletion is confirmed. If an error occurs, the deletion can be repeated by withdrawing the systems (in the subsidiary system).

In the dependent systems, the RFC user is output as the last person to make changes. Choose an appropriate name when you set up the RFC user.

Distribution Logs

To display the distribution logs, choose Environment ® Distribution log (transaction SCUL) in the user maintenance (transaction SU01).

The system displays a selection of pushbuttons you can use to display the logs. The pushbutton texts form the evaluation criteria for the logs displayed.

For example, if you choose Systems, the system displays the status of the users, sorted by subsystem. You display the users in the subsystem by expanding the tree. The color of a node corresponds to the worst error within a node.

To display the color legend, choose Utilities ® Color legend.

If you display the incorrect user master records, the system displays a short text that explains the cause of the error. If this short text is insufficient, you can display a long text by clicking on the field User.

By choosing Transport, you can execute the transport again at this level and trigger data distribution.

The system also offers you a summary of errors, warnings, successful and unconfirmed distributions. The system logs unconfirmed distributions, for example, if the data could not be distributed due to an incorrect RFC connection.


×