Ah. The beauty and agony of choice. As you may have heard, SAP NetWeaver 7.0 will support Web Dynpro (WD) development using ABAP - previously only a Java domain. As a SAP customer and developer you now have a choice to make: Do I use ABAP or Java to develop Web Dynpro applications? The correct answer is ...'neither' … .NET rules! Just kidding :-). I will attempt to help answer this question by discussing factors that could influence your decision. Before starting, I don't want this discussion to turn into a religious war or flamefest along the lines of 'Java is better than ABAP' or the vice versa. With that out of the way….
First and foremost, what is your or your organization's skill set? Have you been coding ABAP since R/3 3.1H or Java since the days of JDK 1.0? If you are fluent and productive in ABAP, why not leverage that skill to develop WD applications in ABAP? What would be the business justification for retooling besides wanting to learn something new? The converse, of course, holds true for Java as well. Unless there is an overriding business need, develop WD applications in the environment where you are most productive.
Developer skill set, however, is not the only variable in this equation. What is your IT staff comfortable supporting? Do you already have an extensive DEV/QA/PROD ABAP infrastructure in place? Consider the resources (training, servers, etc.) that would be required to set up the equivalent Java SAP NetWeaver Development Infrastructure (NWDI). How long would it take the IT staff to come up to speed and be good at installing and maintaining a Java development environment? Speaking of the entire development process (versioning, transport management, etc.) -- it will be easier to move your development project through the system landscape if both the UI and business logic are in the same development environment. Otherwise, you have to deal with NWDI for your WD for Java work and the correction and transport system for your ABAP business logic, or vice versa. (Update: This is is less of a concern now that CTS+ lets you bundle your WD Java UI developement with ABAP development objects into a single transport. )
Next, let's look at the location of your business logic. Is your core business logic contained in EJBs on your J2EE servers or ABAP based SAP systems? If the majority of your code base is in Java it makes more sense to use WD for Java to build the UI. Likewise, tons of custom ABAP business logic is easier to access via WD for ABAP…yes, yes I know you can use adaptive RFC to access that business logic, but it's simpler to make the native ABAP calls.
There are differences between the two WD environments. Currently, WD for Java supports more models (Javabeans, web services, adaptive RFC, and XMI) compared to the function module model in WD for ABAP, though additional model support is planned for ABAP. You can, of course, work around this limitation by wrapping a webservice call in ABAP with a function model. Furthermore, although WD for ABAP has a code wizard, some might find the code completion and syntax checking capabilities in Java more useful when working with the WD API.
Finally, this entire discussion is moot if you need a Web Dynpro application that executes on a mobile device. For now, Java is your only option but support for mobile is planned for ABAP. In the same vein, if you must absolutely have the SAP List Viewer (aka ALV, ABAP List Viewer) then WD for ABAP is your only choice. However, ALV functionality for Java is planned.
In the end, despite minor differences, both WD for Java and ABAP are powerful and complete development environments - the choice of which one to use in your organization should be based foremost on skill set and system landscape and not a 'feature and functions' comparison.
Updated on 5/2/2008.
