辟谣 - SAP CRM WebClient UI的性能，一定不如ABAP Webdynpro吗？

Background of this Blog

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 concrete performance benchmark does not make too much senses.

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 UI 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 looks like below:

CRM webclient UI Search page:

ABAP webdynpro detail page:

Webclient UI detail page:

Test using STAD

Note: The aim to use STAD for comparison here is not to get the overhead caused by Additional Layer Overhead, but just give the end user a concrete impression that, the performance of the two different UI technology, ABAP Webdynpro and Webclient UI, resides in the same order of magnitude.

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.

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.

This performance data is for Edit button click. Again webclient ui is slower, total time less than 1 seconds.

This is for save button click:

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 ).

• 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

Post Search

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:

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

Total time in Post Modify: 55 Overhead in Additional Layer : 55 – 53 = 2 ( 3.6% )

Post Save

Total time in Save & Commit: 13 + 6 = 19 Overhead in Additional Layer : (13 – 12) + ( 6 – 3 ) = 4 ( 21.1% )

Product Search

Total execution time: 2348 milliseconds Overhead in Additional Layer : 896 – 348 = 548 ( 23.3% )

Total execution time: 58 Overhead in Additional Layer: 58 – 52 = 6 ( 10.3% )

Product Save

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

Total execution time: 1160 milliseconds Overhead in Additional Layer : 658 – 608 = 50 ( 4.3% in total time )

Sales Order modify

Total execution time: 105 Overhead in Additional Layer : 105 – 93 = 6 ( 11.4% )

Sales Order save

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:

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.

What we can benefit from BOL& GenIL

1. The benefit to use Webclient UI framework in CRM custom development is apparent:
2. The object oriented BOL API is simple, generic, uniform and easy to use.
3. Your UI components are decoupled from any interface changes in the underlying application specific APIs, it is even not necessary for you to know the detail of underlying API at all; Your application is easier to maintain and sustainable for future development
4. Development of WEBCUIF applications is made easy, since the BOL has been designed to work hand in hand with the UI parts of the framework
5. The built-in buffer accelerates your applications: Once data it is read, the Object is buffered and could be retrieved in nearly no time. Way faster than calling various function modules again and afterwards preparing the data for business use. Taken these benefits into consideration, in my opinion, the gain outweighs the minor performance overhead in additional BOL & Genil layer, if we always stick to Webclient UI in CRM custom development.

要获取更多Jerry的原创文章，请关注公众号"汪子熙":