Skip to Content
Web Dynpro is SAP’s solution for developing professional Web interfaces for business applications. The Dynpro part of the name comes from the ABAP world, which I personally am not very happy about. Dynpro means simply dynamic program (What program is not dynamic?). An ABAP specialist will not know (or like) Web Dynpro at first sight simply because the name ends with Dynpro. But let’s leave it at that, since that is its name.

What is so special about Web Dynpro?

From my point of view, there are several points that make Web Dynpro different from other known Web UI frameworks such as Struts(CX) or JSF (I am open to correction). I will discuss the most important of these below.

Web Dynpro supports model-driven software development

Model-driven software development is not really new, but is gaining in importance through the Model Driven Architecture Initiative of the OMG (Object Management Group). The aim is to generate executable code from abstract models (usually UML or XML). Parts that occur repeatedly are extracted from the applications so that they can be formed into a model, saving the developers Copy&Paste orgies. By generating code from a metadata model, it is (theoretically) sufficient to exchange the generators in order to use the applications in other runtime environments (such as .NET). Of course this is not true for runtime-specific code implemented by developers within the protected regions (everything between the //@begin .. //@end commands in case of classes generated by Web Dynpro). The „runtime support“ for the development process in the NetWeaver Developer Studio is most impressive. The implementations are synchronized on the fly with declarative changes to the model. There is even a kind of code recycling; for example if a method is removed with a declaration, the implementation is not discarded, but sort of made inactive and copied back to the method when it is needed again!

Web Dynpro creates (reusable) „real“ components

Well, at least it offers the prerequisites so that a WD component can be re-used. Of course it cannot guarantee that a component will really be re-usable. A well thought through design is required here. A tool(set) can only be as good as the person using it. Here, too, the developer is supported throughout the entire development process. A WD component is a special form of a development component. This makes it possible for related components to be built to be cascading if necessary, and in the „correct“ order in the build process. You can imagine how much time is saved during this process, which you would have to use to create your own build scripts.

By definition, Web Dynpro applications can be integrated into SAP Enterprise Portal without changes

This could seem unimportant to those who do not currently access SAP EP. I, however, am glad to know that it works when needed. And: A WD application can use the available portal services without a single line of code being written.

Web Dynpro would not be what it is without the toolset

Definitely. The toolset is one of the greatest strengths of the framework. I estimate that at least as much effort went into implementing the toolset as into implementing the WD runtime environment. The effort invested in equaling or surpassing the broad functionality provided in the ABAP Workbench pays off for each developer, even if at the moment some developments may not appear to be completely mature.

After so much (well-earned) praise, a little criticism is also allowed:

Web Dynpro is still suffering from some childhood diseases

SAP shipped first pilot versions of the Web Application Server for Java at a very early date. Oh, when I look back at the first version of Web Dynpro! A lot of things did not work right. The situation has improved immensely in the meantime, but there are still a lot of problems, as you can see from the postings in the Web Dynpro forum.

Therefore my final request. With your criticism and suggestions, you can help to improve Web Dynpro. The SDN is the ideal platform for this purpose. Over the years, SAP has given up its mushroom policy; never before was such direct contact to SAP product managers and developers possible. Please take advantage of this opportunity.

To report this post you need to login first.


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

    1. Former Member Post author
      Hi Jens,

      mushroom policy or better -management is a software development anti-pattern. Avoid any end-user contact for your developers, keep them in the dark and feed them fertilizers 😉
      I don’t want to state, that SAP really practiced this so far, but after opening SDN a much more direct communication flow between the “outer world” and SAP developers and product managers is possible now.

      Regards, Stefan

  1. Former Member
    The people asking the question “What is Web Dynpro?” would be even more confused after this article. It should maybe be a bit more high level focused and ease into very technical details later. I started skipping over it at the second paragraph and abandoned reading it alltogether.
  2. I still was unable to glean the differences between wd and jsf and struts.  Borland and others are providing better toolsets to utilize these frameworks.  (Although, I like the looks of what you can create with WD much better in the SAP world.)

    Maybe you didn’t intend a point by point evaluation, but that is what I expected in the article.  (as an experienced j2ee person, I didn’t find the article too complex, actually it was over simplified imho).

    1. Former Member Post author
      although i don’t share your opinion concerning the quality of the different toolsets you are right that the article title could be a little bit misleading on the first sight. On the other hand there’s simply not enough room for a point by point comparison in a single blog without even more over-simplifying it. This is enough content for a series of articles, i’ll think about starting one.
      Regards, Stefan

Leave a Reply