For several CRM projects in China which I am involved, I found the partner have chosen ABAP webdynpro when custom development is necessary. When asked why they do not consider webclient UI as the first choice, they argued that "Webclient ui is slower than ABAP webdynpro." or "the performance of Webclient UI is bad compared with ABAP webdynpro, since it has additional layers as BOL and Genil". From my point of view, such conclusion without concreate performance benchmark does not make too much senses.
![clipboard1.png]()
Let's do not consider what we can benefit from webclient ui framework( for example better achitecture, cleaner code, better Maintainability, consistent session magement, consistent navigation management etc ) for the moment. I would like to figure out what is the percent of performance loss caused by additional layers introduced in webclient UI framework - the BOL and Genil. So I made the following performance testings.
Test Preparation
I have created one webclient UI component and one ABAP webdynpro component. Both have the exactly the same functionality:
1. Click search button to get several BO instance ( Social post) in result table. I choose the new Genil model named CRMSM delivered in CRM7.0 EHP3, as the structure of it is quite simple.
2. Click post ID hyperlink of one search request row, then we can navigate to detail page.
3. Click Edit button in detail page to switch to change mode, make some changes on post content, click save button to persist the change.
In the webclient UI component, I ensure that the view controller only calls methods defined in BOL interface, like cl_crm_bol_core~query and modify, cl_crm_bol_entity~set_property and get_property, and if_bol_transaction_context~save. In ABAP webdynpro component, I directly call the lower layer function modules SOC_POST_SEARCH, SOC_POST_MODIFY and SOC_POST_SAVE in view controller method.
The ABAP webdynpro search page:
![clipboard2.png]()
CRM webclient UI Search page:
![clipboard3.png]()
ABAP webdynpro detail page:
![clipboardd.png]()
Webclient UI detail page:
![clipboard5.png]()
Test using STAD
Then I compare the response time of both application via STAD. Below is the performance data of Search button click. We observed the memory consumption of webclient UI component is almost twice than ABAP webdynpro. This makes sense since webclient UI framework needs additional memory to store the model metadata in the runtime and also for objects necessary for BOL / Genil framework processing.
![clipboard6.png]()
And this is the performance data of post ID hyperlink click. Here webclient UI is slower than ABAP webdynpro, however the absolute time is less than 1 seconds, which does not make too much difference from end user point of view.
![clipboard7.png]()
This performance data is for Edit button click. Again webclient ui is slower, total time less than 1 seconds.
![clipboard8.png]()
This is for save button click:
![clipboard9.png]()
Test using SAT
From this rough test, we are still not clear about what is the exact performance loss caused by the additional layers in webclient UI compared to ABAP webdynpro. So I plan to SAT to do more accurate performance testing using the following categories. I choose three Genil Models in CRM, the technical name of the model is CRMSM, PROD and BT accordingly. I want to know the percent of execution time spent in BOL & Genil layer compared with the total execution time of Search, Modify and Save. ( Category Modify means the property of a Genil model node is only changed in buffer. The change will not persisted into database until save call is performed ).
![clipboard10.png]()
o(x): Additional Layer overhead of a given BOL model x
f(x): absolute execution time spent in BOL and GenIL layer
a(x): absolute execution time of application API
I have written the following report to perform Social post search via cl_crm_bol_core~query. Then I can get the exact time spent on a(x)|x=CRMSM and calculate the o(x)|x=CRMSM.
REPORT ZSAT_POST_SEARCH.
PARAMETERS: po_id type socialdata-internal_id,
maxhit type i.
DATA: lo_core TYPE REF TO cl_crm_bol_core,
lo_collection TYPE REF TO if_bol_entity_col,
lo_root_entity TYPE REF TO cl_crm_bol_entity,
lv_view_name TYPE crmt_view_name,
lv_query_name TYPE crmt_ext_obj_name VALUE 'PostSearch',
lt_query_parameter TYPE crmt_name_value_pair_tab.
START-OF-SELECTION.
SHIFT po_id RIGHT DELETING TRAILING space.
IF po_id NE space.
DATA(ls_query_parameter) = VALUE crmt_name_value_pair( name = 'INTERNAL_ID' value = po_id ).
APPEND ls_query_parameter TO lt_query_parameter.
ENDIF.
IF maxhit EQ space.
maxhit = 100.
ENDIF.
ls_query_parameter = VALUE #( name = 'MAX_ROWS' value = maxhit ).
APPEND ls_query_parameter TO lt_query_parameter.
lo_core = cl_crm_bol_core=>get_instance( ).
lo_core->load_component_set( 'CRMSMT' ).
lo_collection = lo_core->query(
iv_query_name = lv_query_name
it_query_params = lt_query_parameter
iv_view_name = lv_view_name ).
DATA(lv_size) = lo_collection->IF_BOL_BO_COL~SIZE( ).
WRITE:/ 'Number of ' , lv_size, ' Posts has been found!'.
Here is the result for Social post search:
![clipboard12.png]()
![clipboard13.png]()
Total execution time of post search: 934 milliseconds
Overhead in Additional Layer: 218( spent on component set loading) + ( 634 – 234 – 289 ) = 329 ( 35% in total time ).
Considering that the component set load will only be performed once in the application lifetime, and it would be further improved by using share memory to store model metadata, so I do not regard the time spent on component set loading as overhead. As a result, the final overhead is 329 - 218 = 111 milliseconds, that is 12% of total time.
Post Modify test:
![clipboard14.png]()
Total time in Post Modify: 55
Overhead in Additional Layer : 55 – 53 = 2 ( 3.6% )
Post save:
![clipboard15.png]()
Total time in Save & Commit: 13 + 6 = 19Overhead in Additional Layer : (13 – 12) + ( 6 – 3 ) = 4 ( 21.1% )
Product Search:
![clipboard16.png]()
![clipboard17.png]()
Total execution time: 2348 milliseconds
Overhead in Additional Layer : 896 – 348 = 548 ( 23.3% )
Product Modify:
![clipboard18.png]()
Total execution time: 58
Overhead in Additional Layer: 58 – 52 = 6 ( 10.3% )
Product Save:
![clipboard19.png]()
Total time in Save & Commit: 282 + 263 = 545
Overhead in Additional Layer : (282 – 280) + ( 263 – 41 – 97 ) = 127 ( 23.3% )
Note: 97 milliseconds spent on program SAPMSSY4 should be deducted since it contains the execution of routines registered on COMMIT, such as middleware logic, the workflow event, update function module etc. Those are nothing to do with BOL & Genil framework processing.
Sales Order search:
![clipboard20.png]()
![clipboard21.png]()
Total execution time: 1160 millisecondsOverhead in Additional Layer : 658 – 608 = 50 ( 4.3% in total time )
Sales Order modify:
![clipboard22.png]()
![clipboard23.png]()
Total execution time: 105
Overhead in Additional Layer : 105 – 93 = 6 ( 11.4% )
Sales Order save:
![clipboard24.png]()
![clipboard25.png]()
![clipboard26.png]()
Total time in Save & Commit: 6202 + 354 = 6556
Overhead in Additional Layer: (6202 – 6199) + ( 354 – 24 – 175 ) = 158 ( 2.4% )
Conclusion
The testing result about overhead percent for the three Genil Model could be found in below graph:
![clipboard27.png]()
![clipboard28.png]()
![clipboard29.png]()
According to the formula, the more complex the application API is, the less performance loss caused by additional layer overhead in Web client UI. Also in reality, the performance bottleneck resides in application API, not in the call stack of BOL & GenIL delegation. So in my opinion, performance reason should NEVER be used as the excuse when you do not use Webclient UI as the first choice for custom development in CRM.
Please kindly let me know your opinion on this topic. Thank you very much!
