Portal Development – Why Web Dynpro Java is replaceable
Note: 1st published at SCN on 28.12.2011
You don’t need Web Dynpro Java for portal development. There are easier and more valuable alternatives available.
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: Should Web Dynpro Java be preferred over portal and Visual Composer development because it is enterprise ready? No.
Of course there are some very specific scenarios where WDJ makes sense, but until today all of 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:
- Portal development, including J2EE applications running directly on top of NetWeaver AS Java
- 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.
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 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 application is up and running with Visual Composer. 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. It is not meant for highly customizable applications, but for normal applications where you want to expose backend data and write back. 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 also 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. https://cw.sdn.sap.com/cw/ideas/7510
A problem for JSP and VC is that SAP didn’t really paid intention 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.