Web Dynpro for ABAP Runtime Engine Enhancements.

Ramesh Vadamalayan Business Card

Company: AP !abs Posted on "an. #$% #&&' &#:() A* in ABAP% Application cripting !anguages% Web Dynpro

.ubscrib e Print Permalin k

er+er% "a+a cript%

In the computing world client systems are becoming more powerful in terms of CPU speed and memory. Workstations with 1-2 ! "#$ ha%e become common and they are ready to reduce the load on the application ser%ers. Web applications technologies like Web &ynpro could le%erage the hardware resource in the end user systems. 'his blog e(plains few ways of using the scripting languages to efficiently impro%e the performance of the Web &ynpro applications. 1. Web &ynpro 'able UI )lement - 'he selection of the row in the Web &ynpro 'able UI element in%ariably makes a hit to the application ser%er* presumably to mark the row for selection in the ob+ect in the application ser%er. If the network is slow then we see an hourglass which could be irritating for the user. 'he problem could be sol%ed by marking the selected rows in the front end script ,-a%a.cript/ and send the rows selected to the backend ser%er when a business action is performed on the screen. Web &ynpro runtime could achie%e this by including -a%a.cript code in the generated 0'$1. 2. 2ront end &ata caching 3 'he scroll in the 'able and P4W1 fetch the dataset from the application ser%er for each and e%ery click of the scroll button. 'he data once fetched need not be got from the ser%er again. It could be cached and when the user scrolls back the cached data in the -a%a.cript could be used. 'he application data could be cached in as 5$1 or -a%a.cript ob+ects. 'his will impro%e the performance of the web application and reduce the round trips to the ser%er. 6. 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 ser%er data repeatedly. 'hese enhancements re7uire including of pre-generated -a%a.cript by the Web &ynpro runtime engine which means that there are chances of code becomes browser dependent8 which in%ol%es testing in different browsers. 'he effort is worth because Web &ynpro application will ha%e better user e(perience. Ramesh Vadamalayan is a developer at SAP Labs. #dd to9 del.icio.us : &igg : "eddit Comment on this ,eblog .howing messages 1 through ; of ;.

'itles 4nly 0ard to implement

$ain 'opics

4ldest 2irst !usiness Card B"eplyC

2<<=-<1-2> <192;9?@ "oshan Aadaramandalagi A

0i "amesh* I agree with Aaushik on this one. In applications such as mail browsers we can ha%e client-side data caching and display. 0owe%er on business applications data integrity mightDwill be really important and cannot be compromised with caching. !esides* most of the EslowEness appears on de%elopment systems where de%elopers like us will be crawling our applicationsDtransactions all o%er the ser%er "#$ 9/ Contrarily I think the client systems will ha%e a decent speed. enerally* 0ardware capabilities and bus speeds are increasing a lotF If I remember right Win word was hanging and slow on Windows G>DG;. Hot anymore. )rgo for any other softwareDtechnology. I think the trade-off here is far greater because of data-integrity compromises.

A"A

Ho Page "eloads I 2<<=-<1-2? 2<9>=9>G Prasad . 0i !usiness Card B"eplyC

"amesh* this is an interesting post. In one of the Web&ynpro oals .lides* I read the following9 Impro%e User )(perience through a 0igh 2idelity Web UI by 1. screen updates wDo page reloads 2. client side dynamics 6. performance through caching Can these 6 points be elaborated in detail in conte(t of the weblog posted by "ameshI

Ho Page "eloads I 2<<=-<1-2= 1<9<<9<? "amesh Jadamalayan !usiness Card B"eplyC

0i Prasad* 1. screen updates wDo page reload9 When we do a refresh in the P4W1 instead of whole webpage being reloaded only the table is re-painted from the data from the ser%er. 'his impro%es the user e(perience for sure. In my blog I ha%e suggested not to reloaded from the ser%er if the data in already a%ailable in the client.

Point 2 and 6 I am not sure of. "egards "amesh.

Webdynpro "untime enhancments 2<<=-<1-26 1G91;9<2 Aaushik 0egde !usiness Card B"eplyC

'hese ideas are good but hard to implement

1.'he first idea re7uires #+a(ing and #+a(ing recommened as 0ttp"esponse ob+ect might not be allowed by all browsers*therefore it hinders the webdynpro runtime to generate a uni%ersal +a%ascript for all browsers. 2.Caching of P4W1 data at client side will introduce comple(ities such rele%ance of cached data*introducing displacing of cached data*when data in ser%er side has changed. .toring of data in cookies will resurface problem face by old web technologies like C I. regards kaushik

Webdynpro "untime enhancments 2<<=-<1-2= <G9>69<2 "amesh Jadamalayan !usiness Card B"eplyC

0i. 1. 'he +a%ascript that is re7uired to be included in the first case is simple and it should be supported by all the browsers. 'here is no need of #-#5ing.

2. )%en now on scrolling of the P4W1 table reads the data webdynpro memory in the ser%er. In the sense if the record is changed in the application ser%er on scrolling the powl u will get to see only the old data.

"egards* "amesh.

Hot that simple... 2<<=-<1-26 <29>692@ Jalery .ilae% !usiness Card B"eplyC "amesh*

Kour ideas are good* howe%er implementing them is not that simple. 1. Kes* lead selection forces client-ser%er round trip. !ut imaging $aster 'able L &etails 2orm scenario. When you are selecting row in table form must be updated to reflect changes. In old good time of C." ,Client-.ide "endering/ this works like a charm with partial page update* but now with .." ,.er%er-.ide "endering/ its necessary to redraw whole page on ser%er. #ctually* #rmin MleaksM on W& -a%a forum that something #+a(-like will be implemented in ne(t ma+or release. .o possibly this will be not an issue anymore. 2or now* IEd like to suggest to HW W& team to not make client-ser%er call if no on1ead.elect action handler assigned. Nuite simple change* I belie%e. 2-6. Kou know* -. in I) is slow* -. L &0'$ is e%en more sluggish* and -. L &0'$1 L 'able is terrible. .o if we ha%e client-side caching this may introduce more problems then benefits. Instead of progress indicator user will see froOen I) screen. Worse of it* in I)= all browser tabs will be una%ailable. .o itEs necessary to apply this techni7ue with care. Probably some M%irtual windowM with pre-fetchedDcached data so scrolling se%eral pages upDdown does not cause client-ser%er round trip. #gain* this was a%ailable in C.". 'he ne(t great impro%ement would be usage of 5.1' on client side L inner0'$1 to populate data instead of -. L &4$ manipulations. 5.1' solutions works tens to hundreds times fasterFFF When I worked at )P#$ we submit this as proposal %ia C.H... 4%erall* not a bad ideas. I recommend you to take a look at MUI )lement )nhancement ProposalsM thread on W& -a%a forum ,sticky thread at top/. #lso itEs W& -a%a* many concepts are shared across both #!#P and -a%a %ersions. #nd* most pleasantly* .#P actually listens to these proposals. 'he set of new controls in HW<?s was acti%ely discussed in aforementioned thread. J.

.mall correction 2<<=-<1-26 <G9?;9>? #rmin "eichert !usiness Card B"eplyC

Jalery* I ne%er told something about #+a( in the Web &ynpro forum.

$aybe I MleakedM that in the coming release* the Web &ynpro Client ,aka. ser%er-side rendering/ will also ha%e incremental page updates like in the outdated C.2 ,client-side -a%ascript framework/. Concerning the addressed issues9 !e assured that the Web &ynpro team follows such proposals with great interest and that a lot of enhancements in the UI element area are already underway. #s these are still not officially released features* I cannot gi%e more details. #rmin

")9.mall correction 2<<=-<1-26 119??9>? Jalery .ilae% !usiness Card B"eplyC

#rmin*

$y pardons. #ctually* I said M#+a(-likeM. Probably I misunderstand the term #+a(* but itEs also about Mincremental page updatesM in certain sence 8/ J. .howing messages 1 through ; of ;.