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: 

Solution Manager + CUA Upgrade

JMorozowski
Active Participant
0 Kudos

Hello,

I currently have my production Solution Manager at 3.2. I have new hardware on which I am planning to isntall Solution Manager 4.0. I would like to have both systems online while doing this. What must I need to do to transfer users to the new CUA? Can I have the clients attached to CUA instances at the same time?

Jon

1 ACCEPTED SOLUTION

JMorozowski
Active Participant
0 Kudos

Bernhard,

One more question for you. Will my systems be affected in the time it takes me to remove the old CUA and and add them to the new one? If I understand it correctly, the users are stored locally on each of the clients so that user access to the systems should not be affected. Is that a correct way of understanding CUA?

4 REPLIES 4

Bernhard_SAP
Employee
Employee
0 Kudos

Hi Jon,

having 2 CUA-central systems in parallel is too dangerous....

I suppose, that there exist not too many local users in your Solamn/CUA-central system (just the solman users and the cua-useradministrators....?).

I strongly recommend, after you have finished the installation fo your new Solman to delete the old CUA (completely, so not only SCU->delete, resp. report RSDELCUA, but also delete modeldefinition in BD64 and we20-settings for partnertype LS).

Then update rfc-connections to and from the new CUA-central and

(re)build the new CUA. After running SCUG you will have all the users of the CUA-client systems again in the new CUA-central system.

that would be a clean procedure....

Another possibility would be to use clientcopy (but you know between different releases that is not allowed (has Solman 3.2 the same basis as 4.0 (=7.00)?). The procedure is described in [SAP Note 399917|https://service.sap.com/sap/support/notes/399917] .

But still I would prefer the 'clean' way to be on the save side....

b.rgds, Bernhard

JMorozowski
Active Participant
0 Kudos

Bernhard,

One more question for you. Will my systems be affected in the time it takes me to remove the old CUA and and add them to the new one? If I understand it correctly, the users are stored locally on each of the clients so that user access to the systems should not be affected. Is that a correct way of understanding CUA?

0 Kudos

Hi Jon,

sorry for late response...

Yes you are right. CUA works as follows:

User records are still stored in the same (local) tables as without CUA,

mainly that is table USR02. When building up a cua-landscape, this

local USR02-information is pusshed to the CUA-master (TX SCUG).

In the CUA master the information is stored(USR02), and also in which local (child) systems the user exists (table USZBVSYS) and which roles and profiles he has there (t. USL04, USLA04).

So also if CUA is active, the same tables are used in the child systems, the only difference is of how date is maintained in this systems: w/o CUA directly ihn dialog with SU01/SU10, with CUA-active in background by the various BAPIs by the user maintained in the RFC-connection form CUA-master to this client.

If you delete the CUA landscape, the child system status is returned to standalone system without data change of the users existing there. So the users will not be aware of if CUA is active or not.-->no impact!

In the cua-master the local child-users still exist after deletion of CUA in table USR02, but they will get locked. So the status of the cua-master is not the same after deletion of cua (there exist now also the local users in USR02, also still after CUA-deletion...)

b.rgds, Bernhard

0 Kudos

Bernhard,

Thanks for your reply. I awarded you the full points. You answered all of my questions. Thank you.