which is a huge effort if you don't have them in place. To develop WD Java you need to set up the NWDI envrionment, like SLD, CMS, CBS, DTR, etc. Most of the SAP customer have ABAP stack, but not everyone has the Java stack. Based on my four years WebDynpro Java and ABAP experience I would input some feedback:ġ) The biggest thing is the NWDI. 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.
However, ALV functionality for Java is planned. 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. For now, Java is your only option but support for mobile is planned for ABAP.
#WEB DYNPRO JAVA CODE#
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.įinally, this entire discussion is moot if you need a Web Dynpro application that executes on a mobile device. You can, of course, work around this limitation by wrapping a webservice call in ABAP with a function model. 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. There are differences between the two WD environments.
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. 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. Next, let’s look at the location of your business logic. (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. 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. 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. 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). Unless there is an overriding business need, develop WD applications in the environment where you are most productive.ĭeveloper skill set, however, is not the only variable in this equation. With that out of the way….įirst 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. 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.
I will attempt to help answer this question by discussing factors that could influence your decision. 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’ …. As you may have heard, SAP NetWeaver 7.0 will support Web Dynpro (WD) development using ABAP – previously only a Java domain.
0 kommentar(er)
