Justifying using Web Dynpro over traditional SAPGUI dynpro

[Former Member]

.

We are in the process of upgrading to ECC 6.0/Netweaver 7.0. Web Dynpro for ABAP will soon be available to our development staff. I can invision a couple of new projects that "might" benefit for a web type frontend, but not really sure. However, management is asking the question "What's so great about Web Dynpro vs. traditional SAPGUI dynpro?" There would be a lot of developer training needed, both in Web Dynpro, and in OO for our traditional ABAP developers (me for instance) to be able to develop these type of applications. The idea of learning something new seems great to me, (in a gee wiz, look what this can do! sort of way), but that doesn't impress management as the reason to do something. The want business advantages, before spending time and money on stuff.

There is another thread asking this same question that was just closed due to not being answered

I am not sure I could ask it any clearer so I am reposting his question:.

"Hi,

I am new to web dynpro ABAP and therefore have a very basic question.

Assume that a customer wants to implement SAP EEC 6.0.

What is the advantage for the customer and developer to develop and display all custom objects using web dynpro abap and displaying on the web as against developing and displaying in the SAP GUI?

Cheers,

MIck"

I (along with many others I'm sure) would really like to see this question answered.

Thanks

[Former Member · Accepted solution]

Hi Larry,

To put it in simple word or to state the CRUX as we call it

WebDynpro Mean :

Client independence or Zero client installation for using application,

Improved UserInterface, with added functionality over features of SAPGUI,

application finally is available as service accessible by simply calling the URL,

better adaptability to SOA, the future architecture.

Greetings

Prashant

[Former Member · Accepted solution]

Are there issues with performance using web dynpro? In other words, would the same application written using web dynpro run slower than if written using standard dynpro given that everything else was the same? Or might it be faster? BTW my measurment of time would mean from the time the user hits execute until control is returned to the user.

If I had an application that I knew would never need to be run outside of sapgui and would not need any of the new features, would it make since to write it in web dynpro anyway?

These are the type of questions that will be asked of me before I will be allowed to proceed learnig about web dynpro. I am afraid that "it's the platform of the future" is not going to carry much weight with the powers that be, given our current economic situation.

[thomas_jung · Accepted solution]

>

> Are there issues with performance using web dynpro?  In other words, would the same application written using web dynpro run slower than if written using standard dynpro given that everything else was the same?  Or might it be faster? BTW my measurment of time would mean from the time the user hits execute until control is returned to the user.

Difficult to say. Often Classic Dynpro transactions are not 1:1 matches to Web Dynpro. With Web Dynpro we often design the application with more modern concepts for flow. Multiple screen navigations are redesigned as tab strips and popin areas. Also there are technologies and UI elements in Web Dynpro that have no equilvelant in classic dynpro.

That said, HTML executing in a browser is probably never going to be as efficient as the propriatery bit level, dedicated rednering of the SAPGUI for Windows. Open standards usually have more overhead (and HTML certainly has its share of overhead) and we can't totally control the rendering performance of the browser.

There is a compromise however with the Smart Client renderer for NetWeaver Business Client. Becuase of the client rendering abstraction of Web Dynpro, the same applicaiton can run without any changes in this other client. When running in the NWBC, web dynpro instead renders a much lighter weight XML output and then renders on the desktop using a .Net/WPF based rendering engine written by SAP. These factors produce a runtime and network load very comparable to the SAPGUI for Windows. So you will have your choice of zero client installation browser runtime (with the performance and network overhead you would expect - although still highly optimized in the LIGHTSPEED version) or the small client installation (about 40Mb) of a desktop client, but with the performance you would expect for a dedicated client.

>

> If I had an application that I knew would never need to be run outside of sapgui and would not need any of the new features, would it make since to write it in web dynpro anyway?

I say yes, for many of the reasons I listed in my first posting - personalization, MVC, better design tools, matching up to SAP's new UI design and capabilites, etc.

[Former Member · Accepted solution]

Thomas,

THANK YOU....THANK YOU!!!!! THANK YOU!!!!

You are a rock star!!!!

This is exactly what I was looking for! Aparently I have been looking in all the wrong places for answers to these questions.

I really do want to expand my development skills into OO and Web Dynpro. Our basis team has managed to get a test box setup with ECC 6.0/Netweaver 7.0 (not sure which EP we are going to though) However, I discovered that not all the pieces are in place to develop a web dynpro application. I was trying to follow a very basic tutorial and could just barely get started when it died trying to connect to some sort of server. When I asked about it, I was told that it was not completely configured just yet, and to be patient. Something about getting current functionality working 1st. Oh well, guess I just have to read about it for now.

[thomas_jung · Accepted solution]

There is very little configuration to setting up Web Dynpro. Mostly you need to activate the HTTP service of the ICM - which should be done regardless of if you are using Web Dynpro or not. The same capabilities are needed for BSP, ITS, and Web Services.

As far as Web Dynpro specific configuration, you only need to activate some service nodes in transaction SICF. If you know what you are doing, the whole configuration process takes maybe 5-10 minutes. You shouldn't need a connection to any external servers unless you want to use Adobe Forms inside your Web Dynpro. Then you need to configure a connection to your Adobe Document Services. Otherwise everything pretty much runs directly off your ABAP application server.

The necessarily configuration steps are all documented in this help guide:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/43/e86de5008b4d9ae10000000a155369/frameset.htm

But if you don't want to wait for your basis team to configure your system, you can always use the SDN Trial Download. This download is a complete NetWeaver 7.01 ABAP System that is designed to install and run for an average developers desktop or laptop. This way you have access to the latest release and you can control and setup the system yourself. However it comes with Web Dynpro ABAP already configured and ready to use, so you shouldn't have any problems. It looks like we have an even newer version of 7.01 that now includes SP3 as well (which I would recommend for a some important bug fixes). You can download it here:

https://www.sdn.sap.com/irj/scn/downloads?rid=/library/uuid/c0d7422b-4ee9-2b10-0baf-af588a2126f4

[Former Member · Accepted solution]

Mostly you need to activate the HTTP service of the ICM - which should be done regardless of if you are using Web Dynpro or not. The same capabilities are needed for BSP, ITS, and Web Services. 

I have a strong suspicion that this is the problem. I think I remember being told that this was turned off on purpose (burt not sure). I will forward this to them in hopes they will do something about it.

Thanks again!

[thomas_jung]

When SAP gives presentations on WDA, we spend about 15 minutes talking about the value proposition to the runtime and design time aspects of Web Dynpro. Not sure it is efficient to capture all of that here; but I will try and provide some summary. First is a listing of key points taken directly from help.sap.com:

Web Dynpro ABAP is the SAP standard UI technology for developing Web applications in the ABAP environment. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench (SE80).

Web Dynpro offers the following advantages for application developers:

● The use of declarative and graphical tools significantly reduces the implementation effort

● Web Dynpro supports a structured design process

● Strict separation between layout and business data

● Reuse and better maintainability by using components

● The layout and navigation is easily changed using the Web Dynpro tools

● Stateful applications are supported u2013 that is, if the page is changed and the required data remains intact so that you can access it at any time throughout the entire application context.

Note that stateless applications are not possible.

● Automatic data transport using data binding

● Automatic input check

● User interface accessibility is supported

● Full integration in the reliable ABAP development environment

Lets start with some of the most important points. First SAP has said that Web Dynpro is its primary UI technology moving forward. It is the primary UI technology that SAP will continue to invest in. SAP does not have plans to significantly invest further in classic dynpro or core BSP. For the Business Suite, with the exception of CRM which still uses CRMUI/BSP, all the new User Interfaces screens will be developed in Web Dynpro ABAP. So right there you have a fairly compelling reason to learn Web Dynpro ABAP. If you want to be able to continue to modify, enhance or reuse standard SAP screens you have to at least be familiar with Web Dynpro ABAP.

Second, with Web Dynpro ABAP SAP has designed in a layer of user interface customization and personalization that never existed in BSP or Classic Dynpro. This allows easy manipulation and reconfiguration of the user interface without programming.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/b1693856293c5ce10000000a421937/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/ac6c53fd5b3020e10000000a42189d/frameset.htm

Also althought the enhancement framework has limited capabilities for classic dynpro and BSP, it has very full, rich support for Web Dynpro ABAP.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/c5/f4b9422e0fb911e10000000a1550b0/frameset.htm

Web Dynpro is also based upon newer technology based - making it the most compatible option to run within all the GUI choices. It can run within the SAPGUI (via HTML Control or in a new browser window - with SSO - have a look at transaction WDYID), in a standalone browser, within the NetWeaver Portal (with support for portal navigation and eventing), within a Adobe Flex Client (just like Visual Composer does), or within the Smart Client Renderer of the NetWeaver Business Client. This client technology abstraction is strong point for the long term usage of WD. It allows SAP over time to adapt Web Dynpro to new technology without having to change the applications. This was seen recently in NetWeaver 7.01 when SAP rewrote the HTML/JavaScript rendering engine of Web Dynpro. The new version, called LIGHTSPEED, now includes support for AJAX - enabling UI elements like sliders, drag and drop, resizing of columns etc. Changes to the framework, however, don't require you to recode or rebuild your applications. Any table UI element gained the column resize and rearrangement without changes. We will continue to expand the AJAX and UI capabilites over time. Also although we have AJAX and Asychronous calls in WDA now, they don't require the application developer to learn any AJAX or JavaScript. That is all generated by the framework.

On the design side, Web Dynpro really tried to learn from problems of the past tools. There is a clear, enforced separation of the different layers - commonly known as MVC Model View Controller. This makes your applications easier to maintain and test over time. This has the effect that once you become good at Web Dynpro you can produce applications faster and with less cost. Web Dynpro also uses many wizards and visual design tools to help with the modeling and coding of the application. It will continue to receive the focus of our investment for enhanced developer productivity.

The OO requirement may mean that you have invest in learning OO - but that is a very good thing. ABAP OO will make you a better ABAP developer overall and will have similar benefits to making your code more modular. This results in projects being more flexiblity, easier to maintain over time and easier to test. Of course there is a learning curve to all of these things, but there are real, tangible benefits down the road.

These are just a few of the big items that I had time to jot down. I think you will also find that Web Dynpro has a wide array of UI elements and that we will continue to add more UI elements over time. Also technology like Adobe FlashIslands, Microsoft Silverlight Islands, Floorplan Manager, POWL, Page Builder, etc are all begin built with a focus on Web Dynpro. It all comes back to the fact that this is where SAP is going to be building our applications and this is where we are putting our technology investment.