Skip to Content
In the computing world client systems are becoming more powerful in terms of CPU speed and memory. Workstations with 1-2 GB RAM have become common and they are ready to reduce the load on the application servers. Web applications technologies like Web Dynpro could leverage the hardware resource in the end user systems. This blog explains few ways of using the scripting languages to efficiently improve the performance of the Web Dynpro applications.  1.     Web Dynpro Table UI Element – The selection of the row in the Web Dynpro Table UI element invariably makes a hit to the application server, presumably to mark the row for selection in the object in the application server. If the network is slow then we see an hourglass which could be irritating for the user.  The problem could be solved by marking the selected rows in the front end script (JavaScript) and send the rows selected to the backend server when a business action is performed on the screen. Web Dynpro runtime could achieve this by including JavaScript code in the generated HTML.  2.     Front end Data caching – The scroll in the Table and POWL fetch the dataset from the application server for each and every click of the scroll button. The data once fetched need not be got from the server again. It could be cached and when the user scrolls back the cached data in the JavaScript could be used. The application data could be cached in as XML or JavaScript objects. This will improve the performance of the web application and reduce the round trips to the server.  3.     In case of large result set, considerable amount of data could be brought to the front-end in one shot instead of reading the application server data repeatedly.  These enhancements require including of pre-generated JavaScript by the Web Dynpro runtime engine which means that there are chances of code becomes browser dependent; which involves testing in different browsers. The effort is worth because Web Dynpro application will have better user experience.
To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Valery Silaev
    Ramesh,

    Your ideas are good, however implementing them is not that simple.

    1. Yes, lead selection forces client-server round trip. But imaging Master Table + Details Form scenario. When you are selecting row in table form must be updated to reflect changes. In old good time of CSR (Client-Side Rendering) this works like a charm with partial page update, but now with SSR (Server-Side Rendering) its necessary to redraw whole page on server. Actually, Armin “leaks” on WD Java forum that something Ajax-like will be implemented in next major release. So possibly this will be not an issue anymore. For now, I’d like to suggest to NW WD team to not make client-server call if no onLeadSelect action handler assigned. Quite simple change, I believe.

    2-3. You know, JS in IE is slow, JS + DHTM is even more sluggish, and JS + DHTML + Table is terrible. So if we have client-side caching this may introduce more problems then benefits. Instead of progress indicator user will see frozen IE screen. Worse of it, in IE7 all browser tabs will be unavailable. So it’s necessary to apply this technique with care. Probably some “virtual window” with pre-fetched/cached data so scrolling several pages up/down does not cause client-server round trip. Again, this was available in CSR. The next great improvement would be usage of XSLT on client side + innerHTML to populate data instead of JS + DOM manipulations. XSLT solutions works tens to hundreds times faster!!! When I worked at EPAM we submit this as proposal via CSN…

    Overall, not a bad ideas. I recommend you to take a look at “UI Element Enhancement Proposals” thread on WD Java forum (sticky thread at top). Also it’s WD Java, many concepts are shared across both ABAP and Java versions. And, most pleasantly, SAP actually listens to these proposals. The set of new controls in NW04s was actively discussed in aforementioned thread.

    VS

    (0) 
    1. Armin Reichert
      Valery, I never told something about Ajax in the Web Dynpro forum.

      Maybe I “leaked” that in the coming release, the Web Dynpro Client (aka. server-side rendering) will also have incremental page updates like in the outdated CSF (client-side Javascript framework).

      Concerning the addressed issues: Be assured that the Web Dynpro team follows such proposals with great interest and that a lot of enhancements in the UI element area are already underway.

      As these are still not officially released features, I cannot give more details.

      Armin

      (0) 
      1. Valery Silaev
        Armin,

        My pardons. Actually, I said “Ajax-like”. Probably I misunderstand the term Ajax, but it’s also about “incremental page updates” in certain sence 😉

        VS

        (0) 
  2. These ideas are good but hard to implement

    1.The first idea requires Ajaxing and Ajaxing recommened as HttpResponse object might not be allowed by all browsers,therefore it hinders the webdynpro runtime to generate a universal javascript
    for all browsers.
    2.Caching of POWL data at client side will introduce complexities such relevance of cached data,introducing displacing of cached data,when data in server side has changed.
    Storing of data in cookies will resurface problem face by old web technologies like CGI.
    regards
    kaushik

    (0) 
    1. Hi.
      1. The javascript that is required to be included in the first case is simple and it should be supported by all the browsers. There is no need of AJAXing.

      2. Even now on scrolling of the POWL table reads the data webdynpro memory in the server. In the sense if the record is changed in the application server on scrolling the powl u will get to see only the old data.

      Regards,
      Ramesh.

      (0) 
  3. Prasad Sundara Raghavan
    Hi

    Ramesh, this is an interesting post.
    In one of the WebDynpro Goals Slides, I read the following:

    Improve User Experience through a High Fidelity Web UI by
    1. screen updates w/o page reloads
    2. client side dynamics
    3. performance through caching

    Can these 3 points be elaborated in detail in context of the weblog posted by Ramesh?

    (0) 
    1. Hi Prasad,
      1. screen updates w/o page reload: When we do a refresh in the POWL instead of whole webpage being reloaded only the table is re-painted from the data from the server. This improves the user experience for sure. In my blog I have suggested not to reloaded from the server if the data in already available in the client.

      Point 2 and 3 I am not sure of.
      Regards
      Ramesh.

      (0) 
  4. Roshan Kadaramandalagi K
    Hi Ramesh,
    I agree with Kaushik on this one. In applications such as mail browsers we can have client-side data caching and display. However on business applications data integrity might/will be really important and cannot be compromised with caching. Besides, most of the ‘slow’ness appears on development systems where developers like us will be crawling our applications/transactions all over the server RAM 🙂 Contrarily I think the client systems will have a decent speed.
    Generally, Hardware capabilities and bus speeds are increasing a lot! If I remember right Win word was hanging and slow on Windows 95/98. Not anymore. Ergo for any other software/technology. I think the trade-off here is far greater because of data-integrity compromises.

    KRK

    (0) 

Leave a Reply