ĭata : lr_valuenode type ref to cl_bsp_wd_value_node. ĭata : lr_wrapper type ref to cl_bsp_wd_collection_wrapper. ĭata : lr_table_line type ref to crmt_bupa_il_changedoc. ĭata : ls_c_hist type crmt_bupa_il_changedoc. 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.ĭata : lt_c_hist type crmt_bupa_il_changedoc_t. Lr_rfc_man -> process_viewarea ( it_viewarea = lt_view_area ).Īfter this the process continues as normal. Lr_rfc_man -> set_partner ( lr_partner ). Lr_rfc_man = zdmsh_ab_rfc_manager => get_instance ( ). You can also develop some customizing tables for your needs.ĭata : lr_rfc_man type ref to zdmsh_ab_rfc_manager. It is worth to write a general helper class in order to manage this process. Once you know the assignment blocks, you should launch respective functions asynchronously. " transform configuration xml into table definitionĬall method cl_bsp_dlc_config_ovw => conv_xml_to_data ( Me -> configuration_descr -> get_config_data ( To get the assigned blocks, you can use the following coding. It can be done in the method DO_CONFIG_DETERMINATION of your overview page. At this point you need to read the personalization to see which assignment blocks are opened and will be processed.
![sap crm web ui browser compatibility sap crm web ui browser compatibility](https://docplayer.net/docs-images/40/13180734/images/page_6.jpg)
Processing of the overview page starts from DO_REQUEST, however at certain point, we split data extraction for our assignment blocks or context nodes. This of course requires more system resources, primarily work processes. One can see that the general timeline is shorter due to asynchronous RFC retrieving the data, executed in parallel. Program flow implementing asynchronous RFC processing 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. Processing of the overview page stats from DO_REQUEST and is followed by processing of individual views sequentially in the loop (BIND_VIEW). ON_NEW_FOCUS), and they do not care how this data is retrieved.īelow we will review such a case, based on the partner overview page: BP_HEAD/ BPHEADOverview.īelow two diagrams will help you to understand how the concept can be implemented and what is the difference comparing with the standard processing. 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. However in this case we need to break down the standard processing flow mentioned above. The second way is to make a parallelization through asynchronous RFC on WEBUI level, e.g. So finally this approach does not look very attractive, however may still exist. But even though it’s not always possible due to limitations of API functionality. In this case you need to redefine GENIL implementation classes up to your needs. The first way is to parallelize processing on GENIL/API level for each individual object. 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.įrom my prospective there are two ways how or where the parallelization through asynchronous RFC can be implemented: In the standard, this technique is not used by intention and therefore you need to implement it on your own. 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. 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. 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). Whenever the request is processed by Dialog Work Process (DIA), the whole user context get’s locked. Stateful requests cannot be processed in parallel, even if they operate with different objects. This is a main limitation of stateful SAP applications. On SAP instance level we see that our session is waiting for a certain work process to be released. In case of several requests, they have to wait till the context is unlocked with one work process, i.e. As long as our application is totally stateful, we are trying to access the same user context. 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.
![sap crm web ui browser compatibility sap crm web ui browser compatibility](https://ucc.alicdn.com/pic/developer-ecology/e8de64f55be7448fa837898750ddaecf.png)
You will notice down that the response time is significantly higher than before. Now let us place two samples from above onto the same page: