Skip to Content
Author's profile photo Tobias Hofmann

Portal Development – Why Web Dynpro Java is replaceable

In the blog SAP NetWeaver Portal: Development Options the different alternatives for developing SAP Portal applications where outlined, including a small guidance when to use what and why. One thing that stands out it the fact that Web Dynpro Java (WDJ) is part of the Portal Developer training and certification. Why? You don’t need WDJ for portal development, and WDJ standalone rarely makes sense. So: why WDJ at all?

For those saying: Web Dynpro Java should be preferred over JSP and Visual Composer development because it is enterprise ready. Short answer: No.

Of course there are some very specific scenarios where WDJ makes sense, but until today these scenarios stamped the proof of their existence in the comparison of WDJ against WDA; like: when you have a really high number of users. The problems you get with WDJ are endless and feared in IT organizations. Just the problems with transporting the application led companies to prefer WDA over WDJ.

The alternatives to WDJ SAP gives you are:

a)    Portal development, including J2EE applications running directly on top of NetWeaver AS Java

b)    Visual Composer (see the blog Modeling is the next generation of programming languages.

I won’t consider BSP or WDJ or anything other ABAP based here. If you want to run your (maybe even public) web applications on your productive ABAP instance is your decision.

J2EE applications or portal applications are made for small to big projects. Java standards were designed with this in mind. NW AS Java development allows you to use JCo and Web Services ootb to integrated backend systems. The portal offers SSO and a system landscape, the portlet response can be fully controlled, making it possible to create JSON / AJAX applications while JSP gives you control over the layout. Applications can be created using the SAP design or your own using taglibs. It’s up to you how you want your application to look and behave. You can have the same SAP UI restrictions WDJ has or be free of them. No need to wait for new Service Packs to get a new functionality regarding the layout or the Javascript as with WDJ: You can insert your own Javascript and layout.

Finding developers with the needed skill set is easy: JSP and web applications are standard, developers from Open Source and other venders like Oracle can reuse their skills.

Visual Composer (VC) on the other side allows easy and fast creation of web forms and to display backend data. At the same time when a WDJ developer is still creating the HTML table where the information retrieved from a BAPI will be shown the VC application is up and running. You can easily create mockup services and start modeling the application without waiting for the backend system to be ready. Just enter some dummy data and you can start developing your application. VC is not meant for highly customizable applications, but for normal applications where you want to expose and write data from a backend. Sure, the first versions of VC (specially 7.0x) are not really what you expect, but starting with VC 7.2 it is a very powerful tool.

The skills? VC is a modeling language. Every developer and even business users that have a basic understanding of NetWeaver and UI controls can develop their own applications. Training is easy and fast: in just a few hours people can already start using their first application.

A central web based access to information and application makes sense. J2EE and JSP applications can run on every device, something that WDJ cannot and never will. Visual Composer is more complicated. When you use the flash runtime, you get an application using flash – nothing someone really wants. But the application will work on Android devices with flash installed. When you use Web Dynpro as the runtime, you get the limitations of WDJ. What’s missing is a new runtime, one that enables the easy consumption of VC applications on every device. Like the new SAP UI5. With a HTML5 runtime VC applications can run on every device. This will close the gap for Portal on Device (PoD) and the missing mobile compatible applications. If you agree with this, here is an Idea Place where you can vote for a HTML5 runtime for Visual Composer.

A problem for JSP and VC is that SAP didn’t really paid attention or invested in the tools like they did for WDJ. Creating a JSP page using the SAP taglib for HTMLB UI elements means that there is no wizard available. You’ll have to create the layout manually. VC comes with a graphic modeling tool that helps you to not only create the model but also the UI of the application.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Mahesh Chandra VVNS
      Mahesh Chandra VVNS
      Dear Tobias,
      Thanks for making a clear point on choosing a new path for a WDJ developer, recent notifications from SAP(EhP5 ESS) making WDJ developers to think of other options.
      i am not much familiar with VC, as suggested in blog, I'll try to concentrate more on VC and J2EE applications.

      Thanks ,

      Author's profile photo Hüseyin Bilgen
      Hüseyin Bilgen
      H Tobias,

      I've been working with NetWeaver portal since 2004 and I know every single steps they enhanced the AS Java itself and development tools.
      We did more then 50 projects in Turkey with NetWeaver Portal. And proudly the best one is the IDO Ferrybus Company's Ticket Sales and Reservation System which has over 700K named users. In high season (may-2-sept) daily 200K queries and 52K ticket sales are processed over NetWeaver Portal. AFAIK this is the 2nd largest Portal implementation but of course it is a B2C portal.
      With this project we were able to compare the development alternatives with a NW Portal.
      In most of our projects (Dealer, supplier, customer, intranet portals) we used WDJ for standart backend reports. But for the rich interface required applications (homepage apps such as news & announcements) we first tried JSP, then tried PortalApplications (JSP with HTMLB) and then we decided to use JSF with RichFaces FWs.
      But the problem with tools other than WDJ is, maintenance costs. Because, even for customer, it is easy to maintain WDJ apps with a limited Development Language, but you can't say same for the others.
      For PortalApplication development (JSP & HTMLB), we decided to stop as we couldn't get help from SAP and lack of documentation.
      For JSP, it is worst than JSF, because developers says re-writing is better than trying to modify an existing app.
      Our customers always asks us the re-maintenance costs of applications to make a decision on selecting the platform. And my example is most "Think about how long it takes to change order of a column in a output table with development alternatives.". Because most business applications are possibly can be created with WDJ without problem.

      For mobile or other access?
      Everyone is writing native apps to get most from device.

      So, when IDO go-live on 1st Jan 2009, they started their life with WDJ apps, now we ported the same apps to JSF and it runs on CE 7.2. For this kind of huge system, we preferred to use JSF, but rest still uses WDJ in most of apps (%95).

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      It is good that you don't agree 100%, discussions are always good and a lively discussion is what I want to have with this blog.

      WDJ was pushed heavily by SAP in the last years. No wonder that the toolset you have available at WDJ is more complete compared to the ones available for JSP and VC. You are right: it isn't easy to find documentation about JSP development. There SAP is to blame, but any developer knowing JSP from another J2EE / Portal product can reuse his skills. This isn't a real issue.

      Costs is what you have to consider when choosing a language: WDJ has high costs in terms of training as it is SAP-only. Developing complex application comes with high costs too: setup (NWDI, JCO), reusing other WDJ apps, creating the UI (not able to differentiate between developer and designer, bound to SAP limits, themes). And maintenance: also not cheap. I cannot even count anymore the number of projects where it was considered a success when the transport of a WDJ application to PRD worked. That is: the application was deployed, making it working is another story (JCO errors that only will go away with a server restart, wrong language showing up because the JCo language was changed depending where the JCO was created / altered (system vs SLD)).

      And finding a developers that have the WDJ skills is hard and when they are good (or they believe they are) they also cost some substantial amount of money.

      Of course you can implement all your business applications with WDJ. WDJ was meant to do that. But you can also do it with JSP, sometimes even easier and more adjusted to business needs and for the simpler applications VC is perfect. Compare the costs of a form that shows the user information together with some BAPI data done in WDJ and VC. VC wins.

      Author's profile photo Hüseyin Bilgen
      Hüseyin Bilgen
      Hi again,

      The problem with JSP is not JSP's itself. Because, customers are always love to change the theme on portal. So, for a JSP, JSF projects, you've to consider changing the portal theme also causes to change apps theme. If you didn't make a central configuration for them, it will be painful. But this can't be said about WDJ and VC.
      For developing Portal Apps with HTMLB tags provided by SAP (to make application as portal standart applications in 7.0) you've to find a suitable source of docs. This is valid for 7.0 version. As we see, SAP migrated all JSP based apps on Portal to WDJ.
      NWDI and Jco are not big deals and even the developer trainings. When we did our first project in 2005, we followed the tutorials on SDN to do the project and it was a success.
      I'm not defending WDJ FW as it has lots of overheads on server, browser and client. But is is a standart based framework.
      But it is a framework that any developer with any development knowledge can be easily adapted to use it.
      Lets think about the upgrade for example. When you write your apps in JSx lang, you've to be sure when upgrading your underlying portal. Because they are very sensitive with the JSDK and J2EE versions.
      But on WDJ side, you're guided during upgrade/migration to new release.
      For me, it is easier to train one for WDJ and VC than training for other Java langs.
      For JCO and other problems, you're right, the ABAP developers must be avare of these problems and must provide a solution on both sides. Our developers are preparing RFCs for Portal in a different way, but transferring this knowledge is not a very big deal. Because even our JSx developers requires these JCo's.
      So, bottom line from my side is,
      - yes WDJ and VC has lots of overheads and non-flexible points, but still provide a framework with a version roadmap you're sure
      - For non-business apps I prefer to use JSF other than WDJ. But for reports, and standart business transactions the speed and UI elements are mostly enough.

      Author's profile photo Tamas Szirtes
      Tamas Szirtes
      Dear Tobias,

      I think you are very right with this. Great proposal!


      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      Author's profile photo L. van Hengel
      L. van Hengel
      Hi Tobias,

      Nice blog and really challenging and definitely worth some discussion. When i read the title of your blog as a Web Dynpro Java Developer i couldn't stop thinking about another title: Why Leo is replaceable 😉 No, just kidding, but with this title you really got my attention!

      I think it's too easy to say that Web Dynpro Java is replacaeable, because there is also JSP/JSF or Visual Composer technology available. I agree that with J2EE and JSP you are more flexible because you control the HTML/Javascript for the UI, but what are the costs of creating your own UI in JSP and retrieving the backend data with JCO manually? Where with Web Dynpro you have the tool (NWDS) to create simple to complex screens by declarative programming and connect it easily to BAPI's or WebServices.
      For as Visual Composer (not seen the VC7.2 version yet) i think it's great tool for quickly building simple screens with easy integration of backend services. Very fast with just modeling, but i always have the feeling that when i just want different behaviaour in my user interface I am stuck, because i cannot add or code my own actions/events, but maybe thats the real developer in me talking 😉
      The main benefits for using Web Dynpro Java or ABAP (also nice topic for discussions) for me is that it is a great toolset for building business applications which run inside the Portal. I have worked on many Web Dynpro Java projects and i am still glad i had a toolset like Web Dynpro to build all these apps. I still have not seen another framework which can offer me the same results for building screens and connecting backend data that easily and in a structured way and in the same developer time. Regardless the limitations of the sometimes less intuitive interface.

      I agree that with the new demand for mobile apps Web Dynpro falls short. But most Web Dynpro apps i build are not suitable for mobile anyway without redesiging the UI. So i think it's better to create seperate apps for that with different technology. Just for Portal Development and create business applications i still believe Web Dynpro is a very good way to go. Are you by the way also thinking the same about WDA? Should that also be replaced or are your bad experiences mainly caused by Web Dynpro Java?


      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author

      WDJ is replaceable because we do have powerful alternatives with portlets and VC.

      Yes, SAP invested heavily in WDJ and create wizards and a infrastructure around it (guided procedures, CAF, flash islands, etc), focused lonely on WDJ. If SAP also had paid more attention to the Java developers out there we won't really have this discussion were WDJ is defended pointing out to the tool set SAP created over the years.
      IMO SAP should focus more on the Java developer and give them the tools to be more productive to create complex applications and focus on the simple application designer: Visual Composer.

      SAP gives you the SAP UI as a taglib, so you get the same buttons and UI WDJ offers in the portal too, in addition to having more flexibility. Same for JCo: the portal comes with JCA, giving the developer easy access to ABAP backends by using JCo (portal system landscape and aliases). You even can connect your portlet to 4, 6 or even more SAP backends, the logon will be done depending on the configuration of the corresponding system: SSO or UIDPW (incl. User Mapping). Since 7.2, VC gives you the ability to create complex UIs as well as integrate these into WDJ and vice versa.

      Creating a whole WDJ project just for showing some tables filled with backend data and be able to change the values? That is just an overhead: time, resources, money.
      Try it: create a WDJ application that shows a table and create a VC application that does the same. And that VC application does not have to be simple: Wizards, popups, ALV tables, views, show / hide fields, input verification, etc. What is easier and faster?

      Companies and users need access to information, applications give that kind of access. The more information, the better. Combine information from several sources: even better. Visual Composer allows "normal" users to create applications. Not the fancy ones, but the ones the end-users need to do their job.

      Visual Composer that allows easy, fast creation of applications that not only run on a desktop browser but also on a mobile device ... that will push the mobile usage adoption at companies.

      It is possible to write applications - even complex ones - that run on every device. If your UI is too complex for a mobile device ... try to redesign it. OK, not always possible, but magic can happen.

      And for the real complex business applications: other companies develop and run that kind of apps in J2EE servers using servlets, taglibs, beans, JSP/JSF, struts, etc.

      WDA? Not talking about WDA here as WDA is SAP strategic UI platform it is still actively developed and contains more and more features compared to WDJ. Replacing WDA means using BSP or switching completely to a frontend like the portal. And WDA never forced me to use NWDI 🙂

      Author's profile photo Hüseyin Bilgen
      Hüseyin Bilgen
      Don't forget the API integration requirements and also export to Excel and PDF. Before NW 7.01 you weren't able to export to excel from VC.
      Also, what about writing a new KM UI?
      Of course JSP and JSF are more flexible than others, but mostly it is not required.
      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      "more flexible than others, but mostly it is not required"

      This is very often required. After WDJ developers coded the application, a significant amount of work is spent in fitting the application into the corporate design and guidelines. Rarely the customers succeed. Too often consultants say: you can, but don't, justified with the "killer" feature: it works, so adjust your users to the UI.

      Author's profile photo L. van Hengel
      L. van Hengel
      Offcourse WDJ is replaceable. I am not arguing that. "Everything is replaceable" I meant to say that Web Dynpro framework still provides good tools for creating Portal applications. Okay with Visual Composer its definitely faster and easier. (I will surely check out the features of VC 7.3) But building from scratch or with other open source frameworks and the options you mention (SAP taglib/JCO/SSO). No, not yet, sure there are lots of examples of business applications running (JSP/Servlets/Spring/etc) on other J2EE servers but they all require way more coding that Web Dynpro.

      I still see Web Dynpro fit in just between your alternatives and the Visual Composer. Exactly where SAP positioned it i guess. Offcourse i also know that eventually Web Dynpro Java will be replaced. We all see the ongoing move to Web Dynpro ABAP happening in our daily business. In the HR domain where i have the most experience with Web Dynpro Java we saw the shift to Web Dynpro ABAP when SAP announced the new version ESS/MSS is developed in Web Dynpro ABAP.

      Portlets sounds very good but having experience with developing portlets on NetWeaver. I have to say, that's really complex especially with NetWeaver 7.0. For the new releases i hope SAP invests in WSRP 2.0 support.

      I am also very curious what the NetWeaver Neo platform will bring to all of this. If i am correct the developer can choose his own familiair open-source frameworks. So development for this platform will be more familiair to non-SAP Java developers. Maybe this initiative will also lead to a better and more open SAP Portal 8.0 😉

      To conclude for now. You will be surprised with my next blog. I will replace BPM Web Dynpro Java screens with an alternative UI 🙂

      Author's profile photo Daniel Ruiz
      Daniel Ruiz
      hi Tobias, nice topic;

      i don't have extended experience with visual composer (7.0, 7.3) - but as far I worked with it on 7.0 was 'only' to use flex components where in the same patch level WDJ did not offer flash/flex.

      one thing i've seen is going anywhere beyong 'totally trivial' activities using visual composer is usually painful, very painful - but so is WDJ in certain way - there are some use cases for visual composer, not many.

      in my three years working with SAP it seems to me that 'JAVA' in SAP is totally different from JAVA anywhere else - why would WDJ be any different?

      btw, if you want flex why don't you go flex directly and use proper development tools? - do you really think 'visual composer' would offer you more? - not in speed, not in flexibility, not in performance - to be honest, ABAP does not have a framework or classes to work with AMF3, which is already a big con - unless you have a team that implemented the spec.

      you would be surprised what you could deliver and how fast you could deliver if you can offer the right things to your client - which is not usually possible when working with SAP because of culture mostly.

      and greetings, nice to meet other ppl from motherland working with SAP. (not many around here!)