cancel
Showing results for 
Search instead for 
Did you mean: 

solution manager landscape

Former Member
0 Kudos

As understood, we can´t connect a backend system to "two" Solution Manager systems, just to one.

In this case, what is the landscape suitable for solution manager?

Currently I have 2 solution manager: 1 is dev/test, 1 is productive.

what is the best option:

Option 1:

1. is it OK if dev/test is just prepared for the purposes of testing patches and exploring solman functionality

2. productive solman- ALL satellite systems connected here. This is the main solman box that most users will access for project management, blueprinting, config, monitoring, and so forth.

Option 2:

1. dev/test solman - only satellite systems that are NOT production would be connected here (DEV, QTY, sandbox). This solman system would be used for configuration of solman itself example, solman admin would configure solman functionality here

2. productive solman - all productive satellite systems connected here, except DEV, QTY, sandbox which were connected to DSM. This system also serves as a target system for migrations that came from DSM for solman functionality itself. This is the main solman box that most users will access for project management, blueprint, config, monitoring, and so forth.

which one is encouraged & avised?

Please sharing if you have some expertise in this topic.

thank you in advance

Accepted Solutions (1)

Accepted Solutions (1)

nelis
Active Contributor
0 Kudos

As Solution Manager supports the software life cycle you should include the DEV and QAS systems as part of the system landscape as well as PRD. The whole project management interface in Solution Manager expects this and allows you to build various test cases(based on your Project) to be carried out in their respective environments. Same goes with Change Management. I don't think it makes sense for people to have to use a different system for a specific part of their project as projects generally span from DEV -> PRD. They would probably have to create two separate cases of the same project then in different systems!

I would go with your first option except I'd exclude the sandbox from the "productive solman" and use it for dev/testing on your dev/test solman system. You will need at least one satelite system to do certain integration testing with eg Service Desk

Regards,

Nelis

Answers (4)

Answers (4)

prakhar_saxena
Active Contributor
0 Kudos

Hi Lay,

I could not understand why Option 1 ?

Because if you go for this Option ,,,,,,then how you can explore any functionality of solman say

EWA/BPM/Servic Desk etc ..if no satellite is connected

But

Option 2 is always better if you are going for CHARMS,Service desk functionality/Project Management Test Management etc.

for e.g

Project creation

User can create a proj in Dev solman and later transport to prod solman which is always better so that you dont do anything directly in solman prod.

Its ur decision but if you want to utilize and explore Solman Capabilities as u said then go for Option 2.

Because solman as a standalone system cann't be explored.

Regards

Prakhar

Former Member
0 Kudos

Hi All,

We were also in the same discussion when we started to build our landscape.

Finally we went with option 2.

Solman1 is Connected to all DEV/QAS/Sandbox systems of Satellite Systems(Project Management is also maintained in this system only)

Solman2 is Connected to all PRD systems of Satellite Systems.

I agree with Prakhar;

Because Option 1 - The solman functionalities cannot be explored if no satellite system is connected.

Prakhar,

I have question: We are maintaining Project Management in Solman1(DEV/QAS).

Do we need really to transport this to Solman2(PRD)? If so what is the advantage?

We don't see any issues of maintaining Project Management only in one system(Solman1).

Regards,

Sanjai

Former Member
0 Kudos

Helllo Lay,

what more answers do you want.As Nelis said the first option is the best option

In my setup we have around 18 satellite systems,plus solution manager dev and prd and we have the same config.During implementation we have asked SAP advice on this and they have suggested us the same aproach.

Its been more than 2 years now .It works excellent for us

Former Member
0 Kudos

Any expert can help?

or maybe refer to me others source that i can seek for an answer.

thank you very much

Former Member
0 Kudos

Hi!

Interesting subject...in fact there is no clear answer from SAP (at least none that I am aware of). Connecting all your systems to one SolMan is definitely a valid option and will suit you fine during normal operation...BUT when you're patching or checking out new strategies this will be getting tricky, so to have a non-prod SolMan is quite useful as well. Connecting all non-prod systems to the non-prod SolMan seems to be the obvious choice, but as the solution landscapes would then only hold the prod servers it might not be the ideal solution. Maybe connecting a small number of individually chosen systems to the non-prod SolMan to test functionalities is better in the long run.

Nonetheless, it will be interesting to see what's in store for the future. SolMan is getting more and more important (including its availability), but on the other hand it should always have the latest patches...high availability and regular patching do not really go together very well...Let's see if SAP has a nice answer to that in store.

Regards,

Jörg