Copy of a Doublstack-System while keeping the original J2EE-Data

[Former Member]

Hi Forum,

we have an dev-qa-prod Systemlandscape based on NW04s.

All three systems have an ABAP+J2EE installation ( referred as doublestack-Installation)

We periodically need to copy our Prod to the Qa. Doing this with the Backup & Restore method, all the configurations in the J2EE have to be done again ( as described the Homogenous System Copy Guide). This leads to lot of work, particularly the application-related stuff like JCo-Destinations, HTTP-Destinations, SSO-Configurations, Webdynpro-JCos, PortalContent-Stuff etc.

To avoid this, we consider to export the Java-schema ( with DB-Export or alternatively with JLoad) of the qa-System and reimport this after the redirected restore of the p-database.

Had anybody faced the same issue and can give some hints wether our approach is definitly wrong or right ? Is ther any experience out there ?

Thanks in advance

Stefan

[Former Member · Accepted solution]

Hi Stefan,

You can refresh a dual stack system by following the steps below and also following the SAP guide for Homogenous System copy.

1) Take an Offline OR Online DB backup of both the source and target systems

2) Do the Java export on the source system

3) Start an Abap system install on the target system

4) Refresh the target system during the install (You can use Redirected DB restore)

5) Complete the install

6) Delete the Java DB schema and Import Java on the target system

Java import usually removes all the related java directories on the OS level and recreates them during Import. However in NW04 it was not clearing and recreating them cleanly, so a workaround was to set an environment variable (setenv LDR_CNTRL USERREGS) as <sid>adm user before running the import.

Regards,

Vince

SAP America

[Former Member]

We did several systemcopies this way with NW 7.0 , and all worked fine.

[markus_doehr2]

I understand your requirement but I doubt it will work.

"Some" of the configuration is stored in the database and "some" not. If you restore a system from a backup you will also restore the schema of the source system - and this will be then out of sync with your current data.

What I could think of would be an export of the Java stuff on the original system (means, the system to be refreshed) and then use the backup/restore method to recreate the ABAP part and do a system copy of just the Java part.with the export done before.

I did not test that but it would be interesting to see if that would work.

Markus

[Former Member]

Thank you all for the answers and you effort,

@Benny: we do have different components installed on the affected systems, mostly XSS. Also we still have different versions of NW yet - 7.0 as well as 6.40. But we wish to keep the procedure as independent as possible of the components installed and applications configured.

As we see, using SAPInst to make exports and imports has some disadvantages in our issue:

- additional downtime in the source-system (production) for the exports

- SAPInst destroys filesystem-data on the target-system

We aready considered those aspects and exactly therefor we want to do it the way Markus ( and also me in my initial posting) described - not using SAPInst.

So what i seeked for in this post, are hints & experience in exactly this method, as it is not described anywhere nor in sapnotes nor in How-To's and neither in the Homogenous System Copy Guide.

We will do the tests, and afterwards i'll post our experience here.

Meanwhile any hints on thet method are welcome.

regards

Stefan

[Benny]

Hi,

what is the reason why you need to do this?

Did you look into the adaptive capabilities for this? Maybe this can help solve your problem.

regards,

Benny

[Former Member]

Hi Benny,

thank you very much vor your quick response.

The reason we think to do this is to avoid a lot of manual adoptions as mentioned above. What adaptive capabilities do you mean ?

I have no notice about the possibilities to "virtualize" configuration data like for example the hostnames in JCo-Destinations or other connection data such as Systemids or so. Can you please point me to some docs regarding this. Keywords should be enough, so i can look for it. Thank you i. a.

Stefan

[Benny]

To find out about adaptive computing go here: [|].

As theses systems must do exactly what you want, they may offer such functionality. I'm not aware how they handle databases, so from my side it's only a guess...

Regards,

Benny

[Former Member]

Hi Benny,

after a short review of ACC , and based on my prev. knowledge about it i see that ACC mainly deals with relocating / moving systems by means of system configuration. But it doesn't deals with the aspect on copying a productive system to an existing testsystem which then sould connect to other testsystems rather instead of productiv systems.

Obviously TDMS should be an strategic option, but currently we wouldn't go this way for several reasons.

So my question remains: Is there any experience out there in copying doublestack-systems while keeping the ( application configurational data of) the J2EE-Part of the target system ?

We definitly will test this scenario, and i am interested in any hints / experience on this.

thanx a lot

regards

Stefan

[Henk]

Hi Stefan,

If I understand your question correctly, for you a system copy of only ABAP would suffice. In that case, you could use the System Copy option that SAPinst provides nowadays, and choose to have only the ABAP-database exported on the source system and imported on the target system. Thus you don't have the fuss with the Java post-copy actions.

Regards,

Henk.

[Former Member]

Hi Henk,

thank you for your reply. You did understand my question correctly.

Your hint with SAPInst may work technically, but in this case we need extra downtime of the production system for doing the export which may be about several hours and will not be acceptable.

Instead we will use any backup of the prod-db to restore.

The purpose of this posting is, to avoid pitfalls with our scenario if there are known.

regards stefan

[Benny]

Hi Stefan,

I checked a little bit more into this. I think this is solvable by going more into details. First of all you should check what of those many actions you really have to do, as most of them depend on what NetWeaver parts you really have. I don't believe you have all that stuff running like XSS, TREX, EP and so on.

Then there is a group of actions that should only be necessary to do once. That is everything depending on the SLD, as you can install the SLD on another system and would not change it for every time you copy.

Considering you are running at least NW 7.0 SR3 the effort should be not that big.

Be aware that many of the things listed are listed because those values are not in any database- so doing a manual copy of anything doesn't really help.

...Looking again into your question I found that you don't want the Java part copied at all. Just look to avoid the reconfiguration. I'm pretty sure now you should just go ahead, do the system copy once and afterwards you should be set. - Except you change something in the p-system, then of course you will have to do that change in the t-system also.

Regards,

Benny