Dual Stack Split for existing CRM system

[Former Member]

Hello fellow Administrators,

We currently have a dual stack CRM system on NW 7.02 / CRM 7.0 EHP1.  It is a dual-stack that we've had since CRM 2007 (CRM 6.0).

We plan on moving to CRM 7.0 EHP2 this year to go along with ECC 6.0 EHP6. 

Now, I see that SAP recommends splitting off the ABAP / JAVA stack of CRM.  I was wondering if anyone out there has done this for a CRM system yet.  Also, I found plenty of notes / instguides for splitting but none of them deal with the post steps for a CRM based system. 

Does anyone have anything to add or has done this?

--NICK

[former_member189725]

Technically dual stack split tool would behave the same way  for CRM ABAP+JAVA system as for any other system . Before you split  you will have to check the business scenarios(get inputs from the functional team) which were implemented on the CRM landscape and which are one which require integration between the JAVA and ABAP stacks . For the ones which require integration , check the way is has been integrated . After you split you will have to change the JCo definitions on the JAVA stack.

Please refer to the Master guide for CRM 7.0 EHP1

https://websmp101.sap-ag.de/~sapdownload/011000358700001413642010E/crm_70_ehp1_mg_SUM-Update.pdf

This has information on the CRM business scenarios .

Also check the planning guide for CRM 7.0 EHP1

https://websmp101.sap-ag.de/~sapdownload/011000358700001397742010E/bslsg131en_1.pdf

Hope this helps you with integration post split.

Also post upgrade , refer to the similar guides for CRM 7.0 EHP2.

Regards

Ratnajit

[Former Member]

Ratnajit,

I have all the guides and I've read the documentation.  I don't need someone to point out documentation that obviously exists on the service marketplace.  I really looking for someone who has actually done it and not just read about it.

I don't think SCN is much help these days.

NICK

[Former Member]

Nick,

I've done abap+java "splits" before and Ratnajit makes a great point regarding the business scenarios.  Also, keep in mind CRM is an extremely open ended application that can take many different forms so providing a general solution would'nt encapsulate all of your specific needs. 

Therefore, I'll speak to your question technically.  You would be performing a system copy export of the java instance to write the application data off to flat files like the export media for a clean installation. This process will remove all of the java related instance data and remove the java schema from the DB.  Depending on whether you need to put the java instance on new hardware, you would then run the system copy import on the same system or your target host fora java only instance.  After the import completes, you would want to to verify that all of your connections to the associated abap system are intact.  Things like RFC's, Jco's and other connectivity options generally accessed through SPRO would have to be validated.

Does this hit at what you're asking?

-Josh

[Former Member]

Yeah, I guess.  We just have CRM ICweb talking to back-end ECC system.  that by itself doesn't really use the java stack of CRM.  But we also have screen pops using a 3rd party tool sitting between the SAP CRM and the IVR.  I know that uses the BCB/ICI interface via a HTTP RFC. 

I looked through the CRM documentation.  I get that we would have one stand alone CRM abap system and a separate CRM java system.  I just don't get how they know about each other in terms of things like BCB/ICI.  We are thinking about doing BCM (business communications management) and really, I wonder if it is best to separate the stacks now or later (assuming we further upgrade to a point that requires we break it up into separate stacks.  The CRM version we are on now doesn't require separate stacks, it is only recommended.  I created a different question in the BCM thread specifically for that though. 

It is also interesting to me what order you would bring these stacks down when needing a restart?  abap, then stop java?  I don't see a clear explanation anywhere.

But thanks anyway.  I'll close this out.

NICK