cancel
Showing results for 
Search instead for 
Did you mean: 

Copying a Solution Manager 7.1 SPS5 - Pros and Cons

former_member184682
Participant
0 Kudos

Hello

We have a Solution Manager 7.1 SPS5 system where we have already configured the following features

A lot of SAP notes were applied +

System Monitoring based on the new MAI infrastructure(diagnostic agents etc etc) +

CHARM (with a lot of customizing enhancements to meet our requirements) +

Other miscellaneous features like DVM, EEM, Dashboards etc +

Now we interested to build a landscape for our solution manager with a D system in place so that future changes can be tested before being done directly on production (the above is already being used productively)

My understanding is that though the system copy tools allow copying Solution Manager based on the existing system copy guides for NW 7.02, its still not clear how my target would be usable?

Does anyone have experience with copying a Solution Manager system 7.1 > SPS5 and were successful in using the target operationally without any big difficulties? I was wondering would it be a more clean approach to install again a new Solution Manager SPS5 ? and then again configure these ffeatures (trying to "copy" wherever possible?)

I have seen sap note 1797014 which tells that system copy of solution manager is in general possible, but wanted to hear some experiences

Appreciate if you could answer in details

Many thanks in advance

Chandrakanth

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

hi

we recently done so, i prefer system copy, the reason very simple, solman_Setup is the only thing you need to execute again, but tat also most of the steps automatically pops with green (like DB, RFC connection). other big advantage is your custom modifications are safe, no need to do it again.  your logical components, bpmon and other monitoring stuffs are safe, no need to do again, just verify back after solman_setup

its regular system copy approach, align with the proper post system copy activity.

Thanks

Jansi

former_member184682
Participant
0 Kudos

Hello Jansi

Thanks for your answer. Helps to some extent

but what if i tell you that the only stuff on the source system which want to copy (or we are interested in) is the charm config. Because the source system has a complete different set of systems/solutions/ and hence logical components. It basically belongs to a different landscape

considering this, i am assuming after the copy, i would need to run LMDB to bring my own systems into this target solution manager, configure the initial and basiic setup , configure my own managed systems and hence rfc's /logical components/solutions . i am NOT interested to keep any of the managed systems there were on the source .

so, you still think copy is the quick and right option?

In other words, do you think there is a clean way to copy only the charm config from one solution mnager to the other. The workbench is easily copyable by package export/import. but how about customizing and master data.

Thanks

Chandrakanth

former_member184682
Participant
0 Kudos

Hello Jansi

Thanks for your answer. Helps to some extent

but what if i tell you that the only stuff on the source system which want to copy (or we are interested in) is the charm config. Because the source system has a complete different set of systems/solutions/ and hence logical components. It basically belongs to a different landscape

considering this, i am assuming after the copy, i would need to run LMDB to bring my own systems into this target solution manager, configure the initial and basiic setup , configure my own managed systems and hence rfc's /logical components/solutions . i am NOT interested to keep any of the managed systems there were on the source .

so, you still think copy is the quick and right option?

In other words, do you think there is a clean way to copy only the charm config from one solution mnager to the other. The workbench is easily copyable by package export/import. but how about customizing and master data.

Thanks

Chandrakanth

Answers (3)

Answers (3)

prakhar_saxena
Active Contributor
0 Kudos

Hi Chandrakanth

As already suggested it is better if you go ahead with System copy option so that all your config will remain intact and it reduces time

further if you install a new system you have to transport all the config and create master data again which is a cumbersome process of duplicating efforts

in addition if you are making a copy of solman as a dev make sure the about the landscape strategy not all systems must be connect with solman dev like you connected with solman production.

check this maintenance guide for the landscape strategy as well because it is better to plan now itself

https://service.sap.com/~sapdownload/011000358700000639422012E/MaintPlan_Guide_71_SP05.pdf

hope this helps

Regards

Prakhar

Former Member
0 Kudos

Hi Chandrakanth

This scenario is full supported by SAP, the only thing is you should know all the task that need post-processing once is the system is up, like put on hold all jobs, Adjust the profiles, etc

and for the specific Solman Configuration all the checks you need to do ( check all functionality you have) remember that you already have some scenarios in place that are working on productive mode with DA in production, with the copy of the systems it will has another SID, and change the hostname, you can consider to connect some developtment of qa system with this system to be useful your validation before it goes to production ( this is the objective of this copy)

even you can considere this copy as developtment as part of your landscape for solution manager

to do that you can follow the standar guide for system copy in a dual stack.

put focus in the validation of the scenarios you already have cause im pretty sure it will need ajustments on each ones

Regards

Ernesto

bxiv
Active Contributor
0 Kudos

I did a database refresh for 7.01, to allow for a validation testing of SolmanUP to 7.1; while the upgrade failed I did refresh the Dev solman with what Prod was.

That being said, the ABAP portion was the easy part...the Java side of things however is difficult to accomplish.  Even by using the sap_inst to export the Prod Java information and import it into the Dev system, I spent the better part of a week with the offline config tool changing old values of the Java stack to the new values (SIDs, Instance numbers, etc).

I also did not have much in functionality of 7.01 (Charm, monitoring, other services) working, so there was no validation done to know if that will break when or if you do a refresh.

former_member184682
Participant
0 Kudos

Thanks Billy

I think (yes .. with some pain 🙂 ) , we shoudl be able to copy the dual stack

but i was interested more in the area of solman specific stuff.  How usable would it be after the copy.

i assume things like solman_setup / initial/ basic/ managed system setup etc needs to be done again on the target after the copy. Having said this , would it really make any sense to copy a solution manager or just install a new one and start configuring it from scratch

The one aspect though in our case is that the source has a lot of 7.1 CHARM customization and workbench developments. So the efforts to install a new SM and copy the charm specific stuff  is being evaluated against the efforts of copying the SM and removing unecessary stuff

Thx

Chandrakanth