Parallelization in Web UI – Part 1
Parallelization in Web UI
1. General Idea
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.
2. Possible variants
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.
For more information, please refer to W3Schools’ web site: http://www.w3schools.com/tags/tag_iframe.asp
3.1.iFrames in WebUI
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.
<%@page language=”abap” %>
To get the data I am using event OnInitializationwith the following coding.
* event handler for data retrieval
*** Get the partner from the URL
check partner is not initial.
call function ‘CONVERSION_EXIT_ALPHA_INPUT’
*** Check the partner for existance
*** Read the data into collection
lr_core->start_up( ‘BP_APPL ‘ ).
call function ‘BUPA_NUMBERS_GET’
lv_obj_guid = lv_partner_guid.
lr_entity = lr_core->get_root_entity( iv_object_name = ‘BuilHeader’
check lr_entity is bound.
lr_collection = lr_entity->get_related_entities( iv_relation_name = ‘BuilOpportunityRel’ ).
check lr_collection is bound.
*** Fill the data table
lr_entity ?= lr_collection->get_first( ).
while lr_entity is bound.
*** Create Iterator
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.
call method cl_thtmlb_link=>factory