Changing parameters requires centrakl system login

[Former Member]

Hello,

In our ECC 6.0 system we've setup CUA. In tcode SCUM I've set the parameter option to local. When a user now wants to change his parameters using tcode SU3 in a child system a login screen for the central system appears when trying to save the new parameters.

I thoughed that the "local" setting in tcode scum would prevent this to happen....?

Please advise......

Kind rgds,

P. Keltjens

[WolfgangJanzen]

No, the reported phenomenum indicates a configuration problem: your CUA client system tries to notify the CUA central system about the changed user parameters - but this fails: the RFC destination used for this communication either lacks or contains invalid login data (notice: it is advised to use the RFC Trusted System mechanism instead of storing UID/PWD).

-> check on the CUA configuration (RFC destination)

[Bernhard_SAP]

Hi P.,

this is a typical phenomenon. Even if you have set 'parameters' to 'local', there could be another setting to 'backdistribution' for the data changeable in SU3. As soon it is so, the child system tries to send the information to the central system.

So to avoid the back distribution, you need to set all switches regarding the su3-tabs to another value than backdistribution.

Example:

parameters is set to local,

'language' (on the adress tab is set to backdistribution.

A parameter is changed locally-->effect. the whole set is distributed to cua master system (it is tried to distribute it back).

The other possibility is, as Wolfgang mentioned already, configure the rfc-connection from child to CUa master with a generic user with sufficient rights (sap proposal roles are available).

b.rgds, bernhard

[Former Member]

All parameters where already set to globally and some where set to local but I've still receive a central system logon screen. If I understand you're other solution well then I should set the "Trusted System" to "Yes" in the RFC destination on the tab "Logon & Security" ? That's the only change which should solve my issue?

[Bernhard_SAP]

Hi,

pls re check all tabs in SCUM again in the child system, if any is set to back-distribution.... I had alrady cases, where the settings in child differred to that of the CUA master.

If you change your rfc to truste/trusting, additional steps will be necessary to set up that relation ship. Please refer to the documentation.

If you use trusted for the back connection to CUA master, the users will have to exist on the cua master too (with system assignement and authorizations).

I still believe, that changing the SCUM settings will solve the problem....

b.rgds, Bernhard

[Former Member]

A lot of those parameters are set to global, that's the same as back-distribution isn't it? That would explain why it doesn't work....

[WolfgangJanzen]

>

> If you use trusted for the back connection to CUA master, the users will have to exist on the cua master too (with system assignement and authorizations).

Oh yeah - that's a valid point (I was not aware of when giving that advice).

In general it is not desired to have the superset of all landscape users being active at the CUA master ("active" means "being able to logon to the CUA master system" in this context).

[Bernhard_SAP]

Hi again,

no, not at all..... 'global' will not allow a local maintenance in the child system....

I checked the case now, there seems to be a call to CUA-central system in case parameters are changed: in SUSR_ZBV_CENTRALSYSTEM_GET:

CALL FUNCTION 'SCCR_GET_RELEASE_NR'

DESTINATION central_system_rfc_dest

IMPORTING

sysid = central_system_sysid

mandt = central_system_clnt

To avoid this call to the CUA central system, please implement the corrections of SAP note #1151790 .

After that it should work as expected without calling the CUA master....

b.rgds, Bernhard