cancel
Showing results for 
Search instead for 
Did you mean: 

Performance of webdynpro abap table UI element

Former Member
0 Kudos

Hello guys, we face one problem on performance of table ui element in our SRM project . In our scenario, the SOCO application use one table ui element to display results for some search conditions. The talbe ui have 24 columns. When we set visible rows of table ui element to 100 rows, if user select one row in table, server take about 3 seconds to return response to show the row was selected. I also use Firebug to trace the request between client and server where user select one row. Server return 120KB data.

I only select one row in table, Why the server return so large data and take so long time.

Accepted Solutions (0)

Answers (1)

Answers (1)

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

>I only select one row in table, Why the server return so large data and take so long time.

That's because of the large number of visible rows. Do you really need 100 visible rows? That seems like more can reasonably be displayed in the browser without scrolling anyway. Consider a much small number of visible rows. You generally see 10-15 rows visible maximum. The number of visible rows has a huge impact on performance any time the table UI element must be redrawn (including change of selection, especially before 7.02).

Former Member
0 Kudos

Thomas, Tks for your quick reply.

When user select only one row in table, why the webdynpro redraw all the visible rows of Table. In classic dynpro application, user select one row in table control very quicklly.

BRs.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

Well classic dynpro was a desktop application and this is a web page - world of difference!

Former Member
0 Kudos

Yes, Web and Destop application are different world. But I dont think their performance should be so different. User only select one row in table, and I donot think it must send back data to server immediately .

If each operation of user will trigger the data transfer between client and server, it may cost a lot time and make performance issue.

BRs.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

But the point is that desktop and web are very different worlds and therefore you must design differenetly if you want the same performance.

> I donot think it must send back data to server immediately .

If you change the lead selection in one table, this can impact the data displayed in other areas. WDA is a server side environment - meaning that the impact of lead selection can only be evaluated on the server side via the context. So of course you must go back to the server immediately when you change lead selection.

Far more of a problem for your application is the fact that you have such a large number of visible rows.

Former Member
0 Kudos

Tks for your detail description. Maybe we should change the visible rows to adapt to the performance of WDA.

Best Regards.