All modern web-browser applications support parallelization or asynchronous processing of the requests from the user. Nowadays, the backend systems are scalable and therefore the processing of several requests will not consume more system power (system time) than one big request which contains the logic of four requests. Of course, the load must be properly distributed across the processing units (servers) and in time, so that we never come to the system resources border. Implementation of the parallel request processing can significantly improve the performance and usably without a need in new hardware.
Initially, when SAP WebUI was designed, it did not implement this concept and it was done by intention. Also by intention, it is implemented as a stateful application. Only after some time several asynchronous features like Asynchronous Value Fetch (AVF), asynchronous table rendering (fake rendering), drag-and-drop were introduced.
You would like to implement parallel processing in your SAP WebUI and you are looking for more information regarding possible solutions.
In this document, we will review some options, which can be implemented in SAP WebUI. Particularly we will review the use of HTML iframes, AJAX calls and asynchronous RFCs and their implementations in stateful and stateless applications. Later you will understand all possible options and choose the most appropriate one or the combination.
One of the oldest concept of enabling the parallelization of the requests in the browser-based applications is based on HTML iframes.
You can also implement this concept in WebUI. The following diagram explains how you can do it.
This approach can work with stateless applications or stateless frames only, and therefore the typical use case for this would be a customer fact sheet or similar applications. In our case, I created a Main Window, a main View Set and several views containing iframes. You can see that each iframe contains an independent HTML (in our case BSP) application. The parameters can be transported via URL, and it does not have to be static.
Most of the time the information in WebUI is shown in tables and you can do it as well with iframes.
In our example opportunity frame PartnerOpportunity.htm looks as below.
*** Check the partner for existance select single partner from but000 into (partner) where partner = partner. if sy-subrc <> 0. clear partner. exit. endif.
*** Read the data into collection data: lr_core type ref to cl_crm_bol_core. data: lr_entity type ref to cl_crm_bol_entity. data: lr_collection type ref to if_bol_bo_col. data: lv_obj_guid type crmt_genil_object_guid. data: lv_partner_guid type bu_partner_guid.
*** Fill the data table data: ls_data like line of data_tab.
lr_entity ?= lr_collection->get_first( ).
while lr_entity is bound.
lr_entity->get_properties( importing es_attributes = ls_data ). append ls_data to data_tab.
lr_entity ?= lr_collection->get_next( ). endwhile.
*** Create Iterator if iterator is not bound. create object iterator. iterator->data_tab = data_tab. iterator->runtime = runtime. endif.
Take the HTTPWatch trace to see how the parallelization works.
One can see that all our three main requests were triggered at the same time and were processed in parallel.
3.2.Limits of a iframes in WebUI
However, using this concept has one very big constraint. The WEBUI framework does not know tables visible on the screen and therefore you cannot easily jump into the object, e.g. opportunity, as it has no navigation link and cannot have it by definition. You can easily show static information, as plain text, pictures, external links etc., but navigation within WEBUI is almost impossible.
Why almost, because you can still use your own iterator (IF_HTMLB_TABLEVIEW_ITERATOR) and build a link to launch a certain object in WEBUI, e.g. incident; however this looks too brutal to me.