Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

CUA

Former Member
0 Kudos

Hi,

here my questions regarding the CUA.

Once we have activated the CUA

1. Where should we create the users (user master records)

2. Where should we create the Roles i mean in centrol system or child system ?

3. where should we maintain the roles i mean in centrol system or child system ?

4. where should we assign the roles to users ? Is it in central system or child system ?

give me reply as detailed as possible

your response highly appriciated

Thanks NAG

9 REPLIES 9

Former Member
0 Kudos

Hi Nag, I have included some answers to your questions below.

Q1. Where should we create the users (user master records)

A1. For all the systems including CUA should be managed and maintained through the CUA client

Q2. Where should we create the Roles i mean in centrol system or child system ?

A2. Roles should be created in the delivery system and not in the CUA system. However you will have to remember to do a text comparision in the CUA client for any new role you create in the child.

Q3. where should we maintain the roles i mean in centrol system or child system ?

A3. Child system

Q4. where should we assign the roles to users ? Is it in central system or child system ?

A4. Central system

So baiscally user mainteance should be done in CUA and any role maintenace in the child development systems.

Hope this helps.

Thanks Sam

0 Kudos

Hi Parmar,

Thank you for your reply.

i need clarification from your answers.

Q1. Where should we create the users (user master records)

A1. For all the systems including CUA should be managed and maintained through the CUA client

5. Is it possible to create user in CUA child system ?

6. I think all user maintanance including creation of user should exist in CUA central system. Is it right ?

Q2. Where should we create the Roles i mean in centrol system or child system ?

A2. Roles should be created in the delivery system and not in the CUA system. However you will have to remember to do a text comparision in the CUA client for any new role you create in the child.

7. You mean create roles in Development system and transport them to required CUA child system ?

8. In this case development system under CUA or out of CUA setup ?

Thanks NAG

0 Kudos

In order to be able to maintain a userid in the CUA, it should be created in the CUA.

In transaction SCUM (see this [PDF file|http://static.scribd.com/docs/w0wb2xp0v98u.pdf]) you can specify for each field whithin SU01 how it can be maintained:

You can set the fields to be maintained as:

1. Global: You can only maintain the data in the central

system. It is fully distributed.

2. Local: You can only maintain the

data in the dependent system.

It is not distributed.

3. Default: The system maintains a default value in the

central system. This is distributed when a

user is created and is then

maintained locally.

4. Redistribute: You can maintain the data both centrally and

locally. Each time you change data locally,

it is redistributed to the central system and

from there to the dependent systems.

5. Everywhere: You can maintain the data both centrally

and locally, but the data is not redistributed.

Kind regards,

Lodewijk Borsboom

0 Kudos

Hi Nag, As Lodewijk rightly mentioned you can change these setting - however on the Projects I have worked on its better to mantain users from CUA - which includes creating users and assigning roles to user accounts in systems.

Answering you questions below :

7. You mean create roles in Development system and transport them to required CUA child system ?

Answer - Role should be created in the development systems of the child systems not CUA. CUA is a Central User Administation, you should not be (I dont think this is possible to) creating/maintaining roles for child systems in CUA. Only assigning roles to the users

Thanks,

Sam

Former Member
0 Kudos

Hi Nag,

once you have configured the CUA, all the modification to the user including user creation, role creation/addition/deletion/ modifications, assignment of roles to the users are done in the central system. only passwords for the user ids can be reset in the child systems.

for your reference, check the below site, which is very good for your reference. This site has solved problems for many of us.

http://sapbasisnotes.blogspot.com/search/label/CUA%20CONFIGURATION

Former Member
0 Kudos

Hi Nag,

There are many posts in SDN on CUA. just refer to them.

these might help you solve your queries.

Former Member
0 Kudos

Is it possible to redistribute role assignment through the CUA?

I tried to select the (Redist) under the roles tab - SCUM transaction, but it only has two options Global or Local. Is there something I am missing or is there another way around this?

Richard

0 Kudos

Hi Richard,

We are exploring the same situation in Solution Manager 4.0. At our installation some roles are assigned by Workflow. While our Production box will not be included in our CUA there is a need to test this process in our development boxes which will be in our CUA. If Role assignment is set to global the Workflow process cannot be tested because you no longer can assign roles in the child system.

We found SAP note 161347. It mentions table USRFLDVAL which controls whether the options for SCUM Roles Tab Role assignment are grayed out. The activity group, which is an old name for role, is the entry we changed.

We set the role assignment to Redist but it did not have the desired effect of sending the information back to the central system.

0 Kudos

Hi David,

Thank you for your advice. I enabled the redistribution setting and could not get to work either. I think when you make a role change in the client system it does not send back the information to CUA. I have decided to stay with the factor settings of global distribution as it is easiler to manage in the long term.

Cheers,

Richard