Users created in CUA does not distribute to child systems

[Former Member]

Hi

I searched this forum and after pulling my hair for 2 days I am asking this question. I created a user in CUA and gave him child system access with the necessary roles.

I was under the impression that the user will get replicated / distributed automaticlaly to the child systems which i selected at the time of user creation in CUA

But it does not happen. I login the child system and search for the user. It says User does not exist. I saw SCUL in CUA and the log shows a grey icon next to the username and when I place my cursor on the icon, the tect comes " Distribution unconfirmed"

What am I missing? Everything looks ok to me

Why is the user or users not geting replicated or distributed to the child systems with the necessary roles / profiles?

[Former Member]

Hi Jack,

This could happen for several reasons. Check

1. communication user between CUA and child client is working, user locked or not.

2. communication user password is ok.

3. tRFC log.

4. IDOC log.

Try to distribute manually in SCUL log screen.

Thanks

RK

[Former Member]

Adding to RK's checks, I assume that you have set up a job in the target system to process the USERCLONE idocs

When you drill into the SCUL entry & double click on one of the line items, what is the error text?

[Former Member]

Hi Alex

It may be possible that there is a job in each of the the target( child) systems to process the USERCLONE Idocs. How do I find it? If the job exists, what should be done so that the user/s are distributed/replicated to the appropriate child systems with roles which are selected in the CUA during user creation?

Thanks

[Former Member]

Hi,

You are probably getting the unconfirmed status in SCUL because of a problem with the connection from the child system back to the CUA client.

Just to add to the list of checks above:

- If your child client has recently been copied from another client, there could be two CUA models assigned to it - check BD64 in the child client and if there is more than one entry that could be your problem.

- Have you assigned details such as output device or user group to the id? If these don't exist in your child client, then could also prevent it from replicating (depending on the settings for table PRGN_CUST)

Regards

[RainerKunert]

Hi,

you haven't marked the question as answered yet.

As already mentioned the user data is transferred with IDocs.

If you need further help give us some input:

Have a look into BD87. What is the status of userclone IDocs?

Are there any entries in SM58?

Call these transactions in both systems, central and target client.

[Former Member]

1. I think the IDocs are not processed automatically. I have to manually go in BD87 and process the idocs. Is there a way I can do this automatically?

2. Also the communication user from Client to CUA is getting locked very frequently. When I do a text comparison from CUA, it always pops the username and password login screen and then I have to enter it and the text comparison happens. I don't know what that happens

Any ideas for point 1 and 2 ?

[Former Member]

>

> 1. I think the IDocs are not processed automatically. I have to manually go in BD87 and process the idocs. Is there a way I can do this automatically?
> 
> 2. Also the communication user from Client to CUA is getting locked very frequently. When I do a text comparison from CUA, it always pops the username and password login screen and then I have to enter it and the text comparison happens. I don't know what that happens
> 
> Any ideas for point 1 and 2 ?

1. It should be process automatically after you trigger a change, like save a record in SU01.

In addition to the many great response, try running SCUA in the master CUA, click change and save, make sure everything is green. If not you need some clean up with BD64.

2. If I read your question correctly, you get prompted with a logon every time your run a user compare, this is due to the default login client, it is not a part of the CUA.

Good Luck!

[Former Member]

Hi John

How can I avoid Point 2. Is it normal to get prompted with a logon every time your run a user compare.

Thanks

[Former Member]

There is nothing wrong necessarily either if you have to logon (the prompt) to create the users in the child systems. It might be that your central system wants to determine who can create users in which system and whether human interaction is intended at that point?

If your config is setup for it, then this can go though automatically... normally... but it does not have to be.

It sounds to me as if you are attempting to do something which you are not intended to do, to be honest.

Please take this in a sporting way. No offense intended.

Cheers,

Julius

[Former Member]

>

> Hi John
> 
> How can I avoid Point 2. Is it normal to get prompted with a logon every time your run a user compare.
> 
> Thanks

Yes, if it is setup that way.

Example:

DEV CUA is clients 500, 501 & 502. Default logon is DEV 503 (Meaning in SAPGUI if you double click on the DEV, 503 will be the default client). So when you run user compare the default client will always come up like 503, just change it to 500 and it should work. The drawback is you need to keep doing this until 503 is a part of CUA or change the default logon to 500, 501 or 502.

I hope this makes sense.

[Former Member]

But clients are logical systems from the CUA perspective.

You can still map all the logical systems as clients, and anyway let the distribution fail if you want to (if the CUA Master system cannot restrict the authority for the children system within its own application).

That might also be why these user get stuck....

Cheers,

Julius

[Bernhard_SAP]

>

> 2. Also the communication user from Client to CUA is getting locked very frequently. When I do a text comparison from CUA, it always pops the username and password login screen and then I have to enter it and the text comparison happens. I don't know what that happens
> 
> Any ideas for point 1 and 2 ?

Hi,

that is an indication, that the RFC-connection is not defined properly. As soon it does not work, you will get the login screen (on the login screen the default client (503) is filled automatically, but that has nothing to do with the problem you have).

First check the password of the RFC-user you use. Simply change this user to type 'dialog' and try to log on with the password you know. If that works, reenter this password in SM59. Perform the authorization test in SM59 afterwards. Mind possible upper/lowercase problems with the password depending on the releases your systems are.

You can also try to perform a remote login through sm59 to make sure, tath you can log on with that RFC-user (as long he is of type dailog this will work). If the rfc-user gets locked frequently, then something is wrong with the rfc configuration. In most cases the entered password is simply wrong.

Check this first!

b.rgds, Bernhard