Parallelization in Web UI – Part 3
Parallelization in Web UI
AJAX (… continued)
Limits of a stateful application
Now let us place two samples from above onto the same page:
You will notice down that the response time is significantly higher than before. In the HTTPWatch trace you will see that both AJAX calls are triggered simultaneously, but the first is finished within about 3 seconds, and the second one took significantly longer.
This is caused by increased wait time. As long as our application is totally stateful, we are trying to access the same user context. In case of several requests, they have to wait till the context is unlocked with one work process, i.e. when the current task is finished.
On SAP instance level we see that our session is waiting for a certain work process to be released.
This is a main limitation of stateful SAP applications. Stateful requests cannot be processed in parallel, even if they operate with different objects. Whenever the request is processed by Dialog Work Process (DIA), the whole user context get’s locked. Considering this limitation, by implementing AJAX calls in stateful SAP applications, you can increase usability of your solution, but hardly performance (unless you are using just one call).
1. aRFC or Strength of Value Nodes
The last topic that I would like to review here is how asynchronous RFC can help you to speed up processing of requests from WebUI. You may wish to use this very old technique in order to speed up opening of the overview pages or customer fact sheets, or similar applications. In the standard, this technique is not used by intention and therefore you need to implement it on your own. Furthermore the standard, in most of the cases, is using Model Nodes, which provide a continuous processing from UI/BSP level down to GENIL/API level, and it’s not possible to break down this program execution flow easily.
From my prospective there are two ways how or where the parallelization through asynchronous RFC can be implemented:
The first way is to parallelize processing on GENIL/API level for each individual object. In this case you need to redefine GENIL implementation classes up to your needs. But even though it’s not always possible due to limitations of API functionality. So finally this approach does not look very attractive, however may still exist.
The second way is to make a parallelization through asynchronous RFC on WEBUI level, e.g. on the level of assignment blocks. However in this case we need to break down the standard processing flow mentioned above. This cannot be easily done for Model Nodes, but the Value Nodes do not have such limitation as they just need the data at certain time and certain place (e.g. ON_NEW_FOCUS), and they do not care how this data is retrieved.
Below we will review such a case, based on the partner overview page: BP_HEAD/BPHEADOverview.
Below two diagrams will help you to understand how the concept can be implemented and what is the difference comparing with the standard processing.
Standard program flow
Processing of the overview page stats from DO_REQUEST and is followed by processing of individual views sequentially in the loop (BIND_VIEW). When the context of the view gets initialized normally ON_NEW_FOCUS event is triggered and at this point the data will be read for each context node that is assigned.
Program flow implementing asynchronous RFC processing
One can see that the general timeline is shorter due to asynchronous RFC retrieving the data, executed in parallel. This of course requires more system resources, primarily work processes.
Processing of the overview page starts from DO_REQUEST, however at certain point, we split data extraction for our assignment blocks or context nodes. At this point you need to read the personalization to see which assignment blocks are opened and will be processed. It can be done in the method DO_CONFIG_DETERMINATION of your overview page. To get the assigned blocks, you can use the following coding.
” get configuration in xml language
” transform configuration xml into table definition
” get relevant data from config XML
Once you know the assignment blocks, you should launch respective functions asynchronously. It is worth to write a general helper class in order to manage this process. You can also develop some customizing tables for your needs.
data: lr_rfc_man type ref to zdmsh_ab_rfc_manager.
if lr_rfc_man is bound and
” Set Current Partner
” Register Necessary Blocks
” Start Function
After this the process continues as normal.
Later at each relevant ON_NEW_FOCUS event you need to get the results of the executed functions and provide it to the respective context nodes.
data: lr_rfc_man type ref to zdmsh_ab_rfc_manager.
” Get RFC Manager
” Wait Till Our Block Is Done
” Get Data
” Fill Context Node
if lr_wrapper is bound.
loop at lt_c_hist into ls_c_hist.
create data lr_table_line.
create object lr_valuenode
lr_valuenode->set_properties( ls_c_hist ).
In my sample I selected two most expensive assignment blocks: Interaction History and Change History, and executed a data retrieval for them in parallel.
Note that we are not changing the logic of WEBUI framework and therefore all your GET-methods, iterators, events and navigation links will work as usual.