Skip to Content

The Trouble with Tutorials and a Simple Cure


Having only recently made the progression from „clueless newbie“ to „newbie“ in Java, I find tutorials, how-to documents and weblogs with step-by-step guides extremely helpful in making my way through the ever-growing, ever-changing capabilities of NetWeaver Java and the Composition Environment.

Alas, sometimes it’s hard to apply a tutorial. I will mention two causes and how they could be addressed.

Problem 1: Version differences can make it difficult to apply a tutorial

Obviously, version differences can be problematic because especially from release 7.0 to 7.1 huge changes have occurred, some of which are incompatible.

For example, some of the deployment descriptors used in a development for Java AS 7.0 will break a project in Java AS 7.1. Also, many configuration settings that were located in the Visual Administrator in 7.0 have moved to the NetWeaver Administrator or completely elsewhere in 7.1. What’s even nastier: Even if everything looks alike, the functioning of the tutorial may be version-dependent because a required feature is not stable in a particular release.

Given the current speed of NetWeaver development, I don’t expect this problem to go away by itself anytime soon.

Remedy: Add version information

To help remedy this situation, I suggest that tutorial authors state version information explicity. In which scenarios and versions does the tutorial definitely work? Release, Support Package Stack, and Enhancement Package should be the least.

This information could also be updated from time to time when new facts become known, such as when it has been found out that the tutorial works identically in a new release or when it becomes known that it doesn’t work with a new Enhancement Package.

Problem 2: Transferring project settings to DC properties is difficult

When programming Java for NetWeaver, you can choose whether or not to use the componentization features. (Unless you work with the NetWeaver Development Infrastructure, in which case you must use componentization.)

If you don’t use componentization, you just create Eclipse projects in the NetWeaver Development Studio. Dependencies are declared in the project properties tab or in deployment descriptors referencing Enterprise Archives in the server exactly like in non-SAP developments.

If you do use componentization, everything you program in NWDS is located in a development component and you get all the metadata and control over visibility and dependencies that come with the componentization feature in NetWeaver. (This should usually be your approach of choice unless you know from the start that deploying to non-SAP Java EE servers should be quicker and easier than deploying to SAP NetWeaver.)

Now when you have a tutorial which uses Eclipse projects but want to get it to work in an NWDI scenario, you need to transfer things such as bundled libraries, build path, referenced projects, declared run-time references from Eclipse project settings to NetWeaver Development Component properties.

This can be quite difficult, especially for SAP newbies (who constitute the target audience of many tutorials). Fiddling around with the project settings of a DC project can result in a terminally inconsistent state between the DC properties and the project settings, thus breaking the DC. I have seen expert J2EE developers both with SAP and non-SAP backgrounds give up on trying to repair such a broken DC.

Conversion of projects to DCs is theoretically possible, but doesn’t always work. This is why I’m always glad when a tutorial about Java programming for SAP uses Development Components.

Remedy: Develop samples as local DCs

The solution is simple: use local DCs from the start. They can be set up without any effort, don’t require an NWDI server, but allow easy migration to NWDI because you can simple drag and drop them into a DTR-controlled Software Component. 


In my own humble blogging efforts, I will try live up to these demands and give detailed version information whenever I can and use Development Components so that the programming examples can be easily transferred into NWDI scenarios.

You must be Logged on to comment or reply to a post.
  • Hi Thorsten
    While you mention some good points, the biggest problem I see with tutorials is the handling of objects that aren’t simple code. For example, most tutorials for Web Dynpro Java applications have all sorts of problems trying to describe a view without using lots of screen shots. Even a simple view with a few entry fields and a table are complicated to describe. The same applies to context structures.
    Unfortunately I don’t have a solution to these problems! Maybe there is a simple declarative language that can be used for non-code objects that could be use to copy and paste from a tutorial to NWDS?


    • Hi Michael,
      Thanks for the comment. It’s an interesting idea. If I understand you correctly, you’re suggesting a kind of Eclipse automation language, possibly XML-based and working within the Eclipse editors such as WD screen painting, context modelling, etc.
      I suppose that those editors would have to implement an interface of the suggested Eclipse Automation Framework. I guess whoever writes Eclipse editors would support the idea and put in the extra effort.
      Here’s my suggestion: Make a quick blog out of the idea, and we’ll see how the Eclipse gurus respond. 🙂