Server round trips on table cell clicks cause poor performance

[Former Member]

Hello, we are running EP6 SP9 and have developed a WebDynpro component that is using a table which is bound to a value node context. I am noticing that each mouse-click within a table cell where a different row is clicked causes a server round-trip resulting in poor performance. If selecting a cell within the same row, no server round-trip is performed.

A closer look at the generated Javascript reveals the following:

"onclick="return me.h_e(event,window,this,'SapTableCell','SAPTABLECELLCLICK',{'ColIdx':'5','SapTableId':'MDFG.MTES_Timesheet_Entry_ScreenView.Table0','event':'event','RowIdx':'2','Id':''},'TimesheetTemp.2',true);"

The SSR (server side manager) is being called to set the table's Lead Selection via the js onclick function.

Is this really necessary? Case in point - if the user uses the up/down keys and moves to a different row in the table, the server round-trip is not performed.

Any solutions would be appreciated.

[former_member384931 · Accepted solution]

Hi,

unfortunatelly it was necessary but there is a way to avoid this problem from NW04 SP13 on:

1 The newly introduced table property “compatibilityMode”

1.1 Overview

There is a way to speed up the processing time of Web Dynpro applications significantly by using a newly introduced table property “compatibilityMode”. This property will be available from NW04 SP13 on. If you create new applications try to use Table.compatibilityMode=NW04PLUS.

1.2 Details

1.2.1 The old table selection behaviour

The Web Dynpro Phase Model allows processing one action per user interaction only. When there would be more than one action to handle, the order of them potentially wouldn’t be clear or (much worse) the first action invalidates the processing of the following actions.

Unfortunately we were not able to follow this paradigm in one particular case.

The Web Dynpro table UIElement is able to nest UIElements as TableCellEditors. Some of them have their own actions which can be processed by the application. Examples would be the Button, LinkToAction, Checkbox etc.

While runtime this TableCellEditor will be rendered for each NodeElement of the table’s collection. So there is just one UIElement in the UITree but several visualized instances on the rendered screen content. If an application uses e.g. a button in a Web Dynpro table and the user presses one of the visualized instances, the application has to determine which instance was pressed.

In NW04 the leadSelection of the table is set to the row element of the pressed button, before processing the action of the button itself. Now the application was able to get the row information of the pressed button by checking the collection and its leadSelection.

This leads potentially to two actions which have to be processed

a) the leadSelectionChange action of the table and

b) the action of the TableCellEditor itself

As already discussed such constellations could lead to big problems, especially if one action invalidates the following one. For instance the first action could navigate the screen to another view assembly and the UIElement of the second action maybe isn’t accessible any more.

So the described behaviour of the table has disadvantages in this subject.

To get a conform table behaviour, we decided to change the leadSelection whenever the user interacts with a table cell which isn’t already leadSelected.

While the introduction of the SSR approach we realized that such a behaviour could lead to many roundtrips and performance problems but we were forced to support this behaviour due to compatibility reasons.

1.2.2 The new table selection behaviour

The releases following NW04 (NW04s and newer) introduced some mechanisms, which made it possible to get rid of the old table selection behaviour and gave us the chance to introduce a new and a better table interaction model.

The NW04plus frameworks enrich every user triggered event by a new event parameter “nodeElement” which has to be mapped explicitly by parameter mapping if the application want to access it.

myButton.mappingOfOnAction().addSourceMapping("nodeElement","nodeElement");

The “nodeElement”-parameter references to the corresponding NodeElement of the interacted UIElement. So the application is able to get the information, which button in which row was pressed, without analysing the leadSelection of the corresponding collection.

Using this functionality we introduced the following table selection behaviour:

Table.readOnly==false

The selection is only changed by using the selection column (first column of the table).

Table.readOnly==true

The selection is changed whenever the user interacts with a table cell which is not already leadSelected, but if an user interaction would also lead to an action of a nested TableCellEditor, the selection is not changed. That means that if the user presses a button in a table, the button action would be triggered only.

1.2.3 How to activate the new behaviour

The standard behaviour of all NW04 applications is still the old NW04 table behaviour

The standard behaviour of all NW04s applications is the NW04 table behaviour as well

The standard behaviour of Web Dynpro versions released after NW04s is the new NW04plus table behaviour.

We introduced a table property named “compatibilityMode” which can be set to “AUTO” or “NW04PLUS”.

• AUTO will activate the standard table behaviour of the Web Dynpro release in which the application was originally created.

• NW04PLUS will activate the new table behaviour

For the first time this table property was introduced in the NW04s release but we were able to downport this feature to NW04 SP13 so that the new event parameter and the new table behaviour can be used from NW04 SP13 on.

I hope this helps.

[Former Member · Accepted solution]

Andreas,

I doubt it is available in SP13, but definitly exists in NW04s.

VS

[former_member384931 · Accepted solution]

Hi,

you cannot see it in the NW04 SP13 IDE View Designer, that's a bug ... but you have access to it via the IWDTable interface.

Andreas

[Former Member · Accepted solution]

2 Andreas: you was right -- this was due plugins in my DTR configuration. It works with default IDE plugins.

2 Ed: read updated table tutorial

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webas/webdynpro/tu... on creating tables in web dynpro - 11_0_.htm (part B)

2 SAP / SDN staff: are there any way to subscribe to notifications about tutorials updates?

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member]

Thanks to both Andreas and Valery for their insight and outstanding solutions. You really nailed it!

I am sure the technique you've provided will solve the issue. Between the email and tutorial PDF, it could not have been explained any better. Now we need to make plans to apply SP13 to our environment. I'll post a final result once that is done and we're using the new technique.

Thanks, Ed.