This seems like the hottest debate in SAP shops these days. There has been a slow and steady build up towards SAP’s move to Java based development in the last few years with Netweaver. And that seemed to be culminating in SAP’s WEBDYNPRO framework which optimizes the MVC paradigm into something most suitable for business application development. Traditional Java developers hitherto using JSPDynpPage or DynPage development for Portal development seem to be smitten by Webdynpro for Java and swear by ease of development of common business applications using Webdynpro for Java. It is apparently robust and high performance. It brings to the Java world the basic tenets of SAP’s traditional dynpro programming where the developer strictly works in a module pool framework for PBO and PAI, does simplified coding, and scaling, performance and best practices are implicit in the framework itself. So far so good.
And then, last year SAP came out with the same framework for ABAP language. Which suddenly seems like natural progression for SAP’s ABAP development community – to develop web based business applications within the familiar SE80 environment which also brings to the table all the goodies associated with the Webdynpro framework.
So as SAP development shops were gearing for significant changes in their skill mix (trying to bring on a mix of Java skills inhouse), suddenly there is a new found hope that afterall, after all the scare and uncertainity of the move towards Java, finally there was a Knight in form of Webdynpro for ABAP that can bring back the glory and stability to ABAP developers career.
But the question is how to fairly decide how to go about preferring one language to another with the Webdynpro paradigm.
Why is WEBDYNPRO good for Java development?
Relatively easy and fast application development as compared to other usual J2EE options via use of visual models/code-editors. Comparable with Java Server Faces (JSF).
Generated applications independent of different UIs – like Web, Rich-clients, Mobile devices.
Scalability, robustness and performance are handled by the framework to a large extend
Code available for reuse and modification
What is SAP’s own take on Webdynpro for Java?
SAP’s is using Webdynpro for Java as a strategic tool to produces robust and highly scalable J2EE architecture applications. SAP is in the process of rewriting Employee Self Service (ESS) and Manager Self Service (MSS) applications using Webdynpro for Java. CRM 5.0 uses this functionality. Important SAP Portal applications like User and Role management transaction, Universal Work List (UWL) use Webdynpro for Java.
What are the downsides of Webdynpro?
Framework proprietary to SAP – as opposed to any standard J2EE framework (like Java Server Faces)
Not complete freedom to design user interface elements as only specific objects and their properties can be manipulated
Not possible to include application data ‘scriplets’ into HTML markup
Cannot use Javascript, DHTML, etc. – so limited freedom to do frontend screen design (as familiar to web developers)
Custom Style-sheet integration
Training implications?
For Webdynpro for Java – there is a learning curve for Java developers, not to mention a very steep one for ABAP developers
For Webdynpro for ABAP – its other way around – easier for ABAP developers (especially if they are experts in Object Oriented (OO) ABAP). A Java developer would be wasting time learning Webdynpro for ABAP.
How about promote to Production?
Webdynpro for Java uses NWDI – which is new in SAP shops, but nevertheless nothing but a version control system. If NWDI is already setup well and working well, its not such a big deal doing sensible promote to production of Webdynpro for Java code.
Webdynpro for ABAP uses SE80 and Promote to Production is integrated with SAP’s transport management system. Which is especially good for projects and organizations which are already familiar with TMS and use it to control project and release builds. Really a big plus on the side of Webdynpro for ABAP!
Performance, scalability and robustness?
While there is no comparison to these parameters when it comes to standard ABAP based development based on Basis kernel, when it comes to handling http based applications, large scale applications are not proven on the web server of the ABAP stack. So there are bound to be issues with that. Some of these weaknesses could be manifesting themselves in SAP’s own decision to use Java application server (using Webdynpro for Java) in products like ESS, MSS, SAP Portal admin apps, CRM, etc.
So while it may be viable to use Webdynpro for ABAP as a platform for low use internal web applications in a company, for truely robust and scalable applications, perhaps Webdynpro for Java is a better choice. In the end, these apps are hosted on a standard J2EE server that is compliant with standards of the J2EE world. It is relatively easy for SAP to leverage or adapt the advancements made to the technology by the likes of companies like SUN, Oracle or IBM for the Java stack, when compared to its own investments that SAP needs to make for any improvements to the ABAP stack (especially the web side of it). And of course, there are not many people who would doubt the J2EE architecture on the parameters of scalability and robustness.
Which skill set is more expensive and how to set up the Netweaver development team?
Easy availability of Java skills is an important reason for SAP to have gone into the Java direction as such. Having said that, there are still a plenty of ABAP developers out there and they are still going to be very relevant to SAP’s development world. Leave aside a handful of the new web based applications, and the core of SAP’s revered ERP app is still based in the ABAP kernel. To elaborate ECC x.0 is still nothing but a R/3 application suite at the core of it (actually a 4.6c based). So, have no mistakes – ABAP is still going to be very very core to any SAP implementation or upgrade (remember, Web apps of any kind typically use RFCs that are still written in ABAP). The jury is out there only for the (so far) perepheral applications – but that is kind of where the actual growth is. At that end of it, its perhaps the low cost of Java skill set that will come to have a role to play at that end.
So if you have an army of ABAP developers, would you rather have them do the core ECC related work, and have a handful of them move into the Webdynpro world with some additional tooling in Webdynpro for ABAP? Or, its move prudent to start injecting in skills in Java and build a parallel but complimentary team that is expert in Webdynpro for Java? Perhaps there is no getting away from latter if ESS, MSS and Portal are in scope of your applications. Given that, it may not be a bad idea to start building the Java skills. Get them from outside or have some of the ABAPers retool themselves (which by the way, is the best place to live in if you are a developer in the SAP world). In fact re-tooling as a Webdynpro for Java developer is easier for an ABAPer than retooling into JSPDynPage or JSP.
Companies would like to dabble with webservices, especially if Duet, xApps or Adobe integration is out there on the horizon. Reality is all this new world is really based on Webservices and SAP’s bet at that point is on the J2EE enabled webservices. So perhaps there is no escape from having Java skills in your backpocket. Given that is the future direction, why take a stand against it – which means its time to be open about Java skills. And that being true, it becomes easier to give a verdict on the side of Webdynpro for Java (as a corollary).
11/29/2007 – SAP’s latest Enhancement Package 2 for ERP 6.0 has ESS 1.2 in which a handful of ESS modules, like Travel and Expense, have been rewritten in Wedynpro for ABAP. Functionality is almost same. But does speak to the direction in which SAP may possibly be going. That is use Wedynpro for ABAP for functions that are only dependent on backend SAP.
