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 on SolMan box

Former Member
0 Kudos

Hello,

I've seen this question been raised before. But I am looking into finding a new home for our CUA systems (one prod and one non-prod). We have about 5,000 users in production. Has anyone installed CUA on the same box as SolMan? I would like to know what issues you've encountered.

Best regards,

Matthias Hessler

1 ACCEPTED SOLUTION

Former Member
0 Kudos

One aspect worth considering is that if you want more than one CUA located on the SolMan, then you will need more than one Solman. This might not be the strategy which the SolMan and SLD folks are hoping for.

What I have used successfully is an own CUA system landscape, one for each environment (DEV, QAs, PRD, etc). These systems, like the others, were administrated / monitored by the central SolMan with one central SLD for all.

Cheers,

Julius

14 REPLIES 14

sdipanjan
Active Contributor
0 Kudos

I am using CUA set up in Solman... and as per My opinion this is the best option to set up CUA till date (considering other available systems) in a Client of Solman system.

You will find out documents in SDN as well as SMP on this topic (as I can remember)...... please try with search functions..

Regards,

Dipanjan

Former Member
0 Kudos

Any performance issues or sizing difficulties? How many users do you have in CUA?

Regards, Matthias

Former Member
0 Kudos

Hi,

We did the same with the Solman box : one client for Solman it self and a second client dedicated for CUA.

We manage about 1600 users.

Only problem : we have to be careful with support packages. An SP correcting a solman problem may impact CUA.

Some careful testing is needed.

Regards,

Olivier

Former Member
0 Kudos

One aspect worth considering is that if you want more than one CUA located on the SolMan, then you will need more than one Solman. This might not be the strategy which the SolMan and SLD folks are hoping for.

What I have used successfully is an own CUA system landscape, one for each environment (DEV, QAs, PRD, etc). These systems, like the others, were administrated / monitored by the central SolMan with one central SLD for all.

Cheers,

Julius

0 Kudos

Hi Julius,

>What I have used successfully is an own CUA system landscape, one for each environment (DEV, QAs, PRD, etc). These >systems, like the others, were administrated / monitored by the central SolMan with one central SLD for all.

I don't doubt that this way is successfull but it multiply the number of (non productive utility) systems and this means a big bill at the end of the year...

Regards,

Olivier

0 Kudos

>

>

> I don't doubt that this way is successfull but it multiply the number of (non productive utility) systems and this means a big bill at the end of the year...

>

> Regards,

> Olivier

Surely that depends on what you have negotiated. I don't recall any of my recent clients being charged for their non-prod systems or users.

0 Kudos

>Surely that depends on what you have negotiated. I don't recall any of my recent clients being charged for their non-prod >systems or users.

I was not talking about the SAP costs but the internal costs to buy and maintain new hardware/OS/database/backup and so on...

We already maintain something like 1 hundred servers (hardware and virtual) for our SAP landscapes. That is already a lot too much !

Regards,

Olivier

0 Kudos

>

> One aspect worth considering is that if you want more than one CUA located on the SolMan, then you will need more than one Solman. This might not be the strategy which the SolMan and SLD folks are hoping for.

>

> What I have used successfully is an own CUA system landscape, one for each environment (DEV, QAs, PRD, etc). These systems, like the others, were administrated / monitored by the central SolMan with one central SLD for all.

>

> Cheers,

> Julius

I have the same exact setup, having 3 separate CUA for each system landscape (DEV, QA & PROD). Our security access is tied to HR positions so the master CUA has to be on the ECC 6.0 system where the HR data is maintained. It also makes testing easier, you know all security changes are tested in CUA from DEV to QA then to PROD.

0 Kudos

Ah, that makes a lot more sense. Sorry, I misunderstood you

Former Member
0 Kudos

I've used SolMan as CUA master before & it was absolutely fine.

Personally I prefer my main prod instance (e.g. R/3) to be the master and linking the less-used production systems to it as the child systems. This way, the system with highest volume of changes gets updates in standard way without idocs etc.

Whatever you use for CUA master for Prod, ensure that it has high availability.

0 Kudos

Sounds like I can put my Prod CUA on SolMan Prod as long as it is HA.

As far as non-Prod CUA I still have my doubts on consolidating it onto a DEV or QA since they would naturally not be HA. Any ideas. Btw: Every box that we run comes with a price tag regardless of licensing with SAP. It's the hardware and maintenance.

Regards,

Matthias

0 Kudos

For the non-prod stuff it makes sense to keep it on the most stable box, often R/3. Again, our of preference I tend to use the the R/3 dev client for this but there are no hard and fast rules. HA isn't a huge problem as long as you have a process in place to manage the expected downtime. Even unexpected downtime isn't a problem as you can always remove a client from CUA (and therefore manage users in client system) in a worse case scenario. For me, dealing with refreshes are the biggest pain. Not a problem as long as a structured process is followed before & after a refresh.

I agree about the price tag for hardware & support etc, but I hope you don't have the licence overhead on non-prod too.

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

We do in fact have a Dev, QA and Prod SolMan. But as I stated above the non-Prods are by nature subject to downtimes and refreshes.

Thank you all for your insights. I think I have enough material to wrap-up my study.

Reagards, Matthias