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: 

Users in Gray in SCUL

Former Member
0 Kudos

After reconnecting two clients on the same system with SCUA, all users appear grey in SCUL. The Profile and ACTGRP are green. One of the affected users is CUA_ADM.

On the central system CUA_ADM has two roles and profiles SAP_ALL and SAP_NEW. All the assigned profiles and roles on the central system for these two clients show SAP_ALL and SAP_NEW as not being composite roles, but only for those two clients.

If we attempt delete or assign the roles to those clients, we get a message that the role or profile does not exist.

On the client systems, the CUA_ADM ID has those roles and profiles. Everything appears to be as we would expect.

The RFCs work and have the correct verified passwords.

Other clients on the same system are successfully working with CUA.

There are no short dumps indicating problems.

WE05 output looks the same as any other client.

We can successfully create a user on these clients using CUA, but cannot assign roles or profiles.

We have done user compares and text compares.

Does anyone have any ideas?

TIA,

Russ

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi

Did you try running Roles comparison from Child clients?

Regards

Hari

14 REPLIES 14

Former Member
0 Kudos

Hi

Did you try running Roles comparison from Child clients?

Regards

Hari

Former Member
0 Kudos

Thanks,

Yes, I tried role comparison between the master and client as well as user comparison and text comparison.

Russ

Former Member
0 Kudos

check scum settings for roles and refresh to local and back to global.

Former Member
0 Kudos

Yes, as previously stated I already did a text comparison. That did not fix the issue.

The suggestion to verify the SCUM settings was an interesting thought, and I will look into it. I am not, however, optimistic since I connected several other systems and clients at the same time without a similar problem.

I would expect the same SCUM settings would have been applied in each case, so I would be surprised if that were the problem.

Both the master and client systems are 7.01 EHP1.

Former Member
0 Kudos

Both the role and profile were initially set to global, which is what we've been using successfully for several years. Per the suggestion, I changed them both to local, removed and readded the client to CUA, ran SCUG, and found the problem is still there.

I have put the SCUM settings back to where they were and dropped and readded the client again. And yes, it is still showing the same problem.

0 Kudos

What are your prgn_cust settings in these local clients?

There is an option in CUA to use a simplified concept.

The object for it is new and might (posdibly) not be included in SAP_ALL or (more likely) copies of SAP_ALL.

You need to provide more information from your side (your initial post is not enough to even make a start...). For example the logical system mapping might point to a trusted rfc destination and you dont have an ID in the target. You will see that in BD87.

Etc..

Cheers,

Julius

Edited by: Julius Bussche on Sep 30, 2011 12:08 PM

Sorry, I mistook you for "Bobby Russel" who regularly irritates the forum.

Apologies and moved back to the Security Forum.

Julius

Former Member
0 Kudos

Hi Julius,

Thank you for your response.

Table prgn_cust is empty on this system, which contains clients that are working and the two that are not.

There is atrusted connection for SYSM, not CUA, set up to one client on this system which is working. Again, other clients on the same system without trusted connections are working as well.

The RFCs going both directions between the master and the target are not trusted and contain the same userID and password (verified, accounts not locked, system type user) that they have had for over a year.

Again, these CUA connections have been working fine. CUA was mistakenly deleted (don't even ask), and since I did the initial install and configuration, I have been tasked with getting it back in operation. All of the logical systems, RFCs, userIDs, profiles and roles were already there and working for several years. The only thing I see that was changed was all the SCUM settings were reinitialized. And yes, we redid the SCUM settings to what we think they were.

I need to stress that the SAP_ALL and SAP_NEW profiles are only an example. As far as I can tell, the master CUA doesn't recognize that the target client has any role or profile.

We can create a user on these clients via CUA, but cannot push any role or profile.

Best regards,

Russ

m_coenjaerts
Explorer
0 Kudos

Maybe you can look in the status of the IDOCS - the SCUL gives a the idoc no. and with the default idoc tcodes you (WE02, WE05) you can see in which status the idocs are. Perhaps you can trigger then processing on IDOC (RSEOUT00 in the central system, i do not know by memory the ABAP to process incomming IDOCS)

Former Member
0 Kudos

I looked at bd87 on both sides.

On the master side I have statuses as follows:

03

30

01

On the target side I have:

53

62

64

50

11 segments on both sides.

Still have the problem.

0 Kudos

Try tracing the RFC user with ST01 on both sides, see what turns up when you push a role update.

0 Kudos

If the logical system names are the same as the technical RFC destination names, is it possible that the problematic clients have different names? There was a note about this a few months back.

Otherwise you will have to compare the tables of SCUM to find the inconsistency.

Cheers,

Julius

Former Member
0 Kudos

I turned on a system trace on both sides and ran an update. I don't see any errors.

I hand compared the SCUM settings of a client with the problem and without the problem. They look identical.

WE05 and SM58 are clean on both sides.

I ran a check in WE20 for the ports. It looks good.

I confirmed that the company addresses are consistent.

I redistributed the distribution model.

I checked the partner profiles on both sides.

I checked the message type in we20 on both sides.

Still doesn't work.

Best regards,

Russ

0 Kudos

Here is a long shot in the dark...

SAP_NEW is contained within SAP_ALL if it is regenerated (SU21 and after-import events). So you do not actually need SAP_NEW if you have SAP_ALL and help.sap.com recommends to delete SAP_NEW after completion of upgrades. This also makes sense as the next upgrade then only contains the realy new objects, and not everything which ever was new...).

So... does SAP_NEW exist in those clients which you are wanting to distribute to and if so then does it have an active version in SU02?

Are those clients with problems still using manual profiles and is SAP_NEW (composite profile or singles of SAP_NEW* ) assigned to any of the users displaying this problem?

Also please verify the logical system vs. RFC dest mapping and whether these clients are assigned to logical systems (tcode SCC4 and BD97).

Cheers,

Julius

Former Member
0 Kudos

Solved.

The one thing I didn't check was the logical system in SCC4 in the target clients.

Thanks everyone for the help.