Skip to Content

In theses days NetWeaver 2004s goes to final stage, so I thought this is a good time to give you some enhancements that did not make it into the product. This stuff will be documented, but currently isn’t and blogging was the fastest way for me to inform you.


Big companies release big things. That’s the way SAP does too.  Unfortunately those “big Things” are not welcome everywhere and such a case became the Developer Workplace, SAP’s Java Development environment. Let me explain what we have here. As usual the Developer Workplace comes with an IDE, the SAP Developer Studio (Eclipse based for those new to the environment) and a local server.

As the latest generation of the NetWeaver Java Server includes design tools that run in a portal, the server logically comes with that. The whole environment runs nicely on 2GB of RAM, but if you add a Developer Studio to that, the going gets tough.

And here the tough get going: manipulating the configuration is the way to go. Additionally it is possible to install your system in an alternative architecture, that was not documented that well. Let’s start with that one.

Alternative Architecture

As I said before, Developer Workplace comes with a studio and a local server, as usual for java development environments. As an alternative the Master guide is talking about the installation of the SAP Developer Studio only (in a single part sentence only, I admit). Unfortunately it does not discuss in detail what this means for the server side. “Great!” you might think, “now all of my developers have to work with two computers”.


Well, that’s not quite right. Of course, if you develop with a distributed system, you need a machine to host the application server. Not very helpful for a single developer (except that you can extend your MS Windows capabilities to usually work with a max of 2GB RAM to two computers). But for a group this looks different. If you have several developers work against one server this becomes more useful.  
Yes, I know what you’re thinking.  
Yes, I know that debugging of a Java Virtual Machine stops all threads on that VM.  
Yes, I know that deploying your project overwrites the existing version regardless whether it’s in use or not.  
But read on.

First of all, we’ll talk about debugging. Skip this subchapter if you already know the trick.


If you have ever debugged a NetWeaver Java Server with Developer Workplace, you might remember that you have to switch the debug mode on and then have to restart the server. Approaching breakpoints stops the complete process and that means the whole server. The consequences for a single process server are clear: no debugging in a productive server, as this will stop execution on all running sessions.  And of course it is impossible to work with a group of developers against such a server (as long as they ever need to debug their code…)  

If you ever have tried this on a standalone server, you might have found out something interesting. A standalone server can have more then one server process. The debugging mode can be set for those processes each individually.

On top of that, server processes in debug mode are taken out of the dispatching of requests. That means such a process will not accept any standard user request sent to this server environment. The request only is accepted if marked with a specific sign, that is known by your SAP Developer Studio.

This means, if there are as many server processes as developers in the group, there is always a debug session available for everybody. As debug sessions are none responsive to browser calls I’d suggest always having another non debugging process. This means ideally n+1 processes if n equals the number of developers. Of course this again is a matter of memory and you might reduce the number to anything that fits your needs.

By the way: in this environment you even can run heterogeneous, thus run your server in a UNIX environment, which nowadays opens the door in any case to 64 bit memory space.

 The Drawbacks

There is a reason why people started to do development with a local server. Two of them you have to handle in one or the other way to run in a distributed development environment.

The Software Deployment Manager (SDM) is single threaded (there was a reason for that, but I forgot). Because of that only one developer can deploy at a given time. This means if you try to deploy during another session is running you get a nice error message that looks like this:


 As you can see there is a correct message appearing. Of course this will happen the more often, the more developers do work against this server. If it happens too often, you can also avoid this by using the NetWeaver Development Infrastructure. If you never heard this term before, then please learn more about it at NetWeaver Development Infrastructure  

Second, this environment introduces the risk of overwriting each other. This means, if I deploy a project that is used by another developer and change anything of his or her preconditions this may have fatal consequences for this developer. On the other hand, these consequences reach us sooner or later, though it might be a philosophical question when this is best (and isn’t it better soon anyways?).

Yes, there are other thinkable situations where this effect is more crucial. But there are two facts that convince me: it somewhat forces developers to think more about the consequences of their work (and who would deny that *some* discipline is useful) and we got a large community next door who is living with such effects for over twenty years now and still going strong: our ABAP colleagues.

Again, the effect of overwriting is reduced by using the NetWeaver Development Infrastructure, which I can’t stop praising and really would like you to learn more about as it opens new perspectives to Java developers you never even though about 😉

 Install the Studio Only  

 To do this there is a little trick you have to know. Usually you have to start the installation from the Developer Workplace DVD as sapinst installation. Once in that the sapinst program will start the appropriate installation program for you. To directly install the Developer Studio you just go to the /IDE directory and start the program IDE70setup.exe. Oh, and the DVD is named “SAP NetWeaver 2004s, Developer Workplace” to be precise. I checked with my package I ordered for my desk – something pretty unusual these days.


In the next blog I’ll talk about setting profiles to more usfull  values.




To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Markus Klein
    Nice blog,

    you have written:

    “A standalone server can have more then one server process. The debugging mode can be set for those processes each individually.”

    Can you give me more infos on that?

       Id Webdynpro application deployment available in the local server possible. I am referring to the local server  which is provided with the developer workplace.



Leave a Reply