Best practice: Webdynpro in a large system landscape

[Former Member]

Dear Sirs,

I have a few questions about using Webdynpro (WD) in a large system landscape. After doing some research I understand there are a few alternatives, and I would like to get your opinions on the issue and links to any relevant documentation. I know most of my questions do not have a single answer, but I hope we can get a disussion, which will highlight the pro/cons.

My landscape consists of a full set of ECC and portal servers (DEV, QA, P) , where using WD to fetch BABI’s from the backend and present them in the portal is a likely scenario.

<b><i>Deploy the WD components on portal servers or on separate servers?</i></b>

Would you deploy the WD components on the portal WAS or would you advice having a (or a number) of servers dedicated to running WD.

The way I see it, when you are having a large number of developers, giving away the SDM password to the portal server (DEV) in order for them to test WD applications is not advisable (or perhaps more true, not wanted by the basis). So perhaps a separate WAS for development of WD is advisable, and then let basis deploy them into the portal QA and PROD server. I do not think that each developer having its own local J2EE for testing is likely.

How about performance?, will any solution be preferable over an other. Will it be faster/slower to run WD on separate WAS.

<b><i>Transporting the WD components</i></b>

How should one transport the components and keep them pointing to the right JCO connections (as you have different JCO connections for (DEV, QA, P)), I have seen example with threads where you opt for a dynamic setting of the JCO connections through parameters. Is this the one to prefer?

Any documentation on this issue would be highly appreciated. (Already read: System Landscape Directory, SAP System Landscape Directory on SAP Web AS Java 6.40)

[Former Member]

Any news on this topic? We would also like to know the best practice for not giving the sdm password to the development portal server.

[Former Member]

Look into using NWDI as your source code control (DTR) and transport/migration from dev through to production. This also will handle the deployment to your dev system (check-in/activate).

For unit testing and debugging you should be running a local version (NWDW). This way once the code is ready to be shared with the team, you check it in (makes it visible to other team members) and activate it (deploys it to development server).

We are currently using a separate server for WD applications rather than running them on the portal server. However, this does not allow for the WD app to run in the new WD iView. So it depends on what the WD app needs to do an have access to. Of course there is always the Federated Portal Network as an option, but that is a whole other topic.

For JCo connections, WD uses a connection name and this connection can be set up to point to different locations depending on which server it is on. So on the development server the JCo connection can point to the dev back-end and in prod point to the prod back-end. The JCo connections are not migrated, but setup in each system.

I hope this helps. There is a lot of documentation available for NWDI to get you started. See: http://help.sap.com/saphelp_erp2005/helpdata/en/01/9c4940d1ba6913e10000000a1550b0/frameset.htm

-Cindy