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

/wp-content/uploads/2014/01/clipboard1_354659.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:

  • 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.
  • Click post ID hyperlink of one search request row, then we can navigate to detail page.
  • 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:

/wp-content/uploads/2014/01/clipboard2_354660.png

CRM webclient UI Search page:

/wp-content/uploads/2014/01/clipboard3_354661.png

ABAP webdynpro detail page:

/wp-content/uploads/2014/01/clipboardd_354666.png

Webclient UI detail page:

/wp-content/uploads/2014/01/clipboard5_354667.png

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.

1search time.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.

/wp-content/uploads/2014/01/clipboard7_354672.png

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:

/wp-content/uploads/2014/01/clipboard9_354677.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 ).

/wp-content/uploads/2014/01/clipboard10_354678.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

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:

/wp-content/uploads/2014/01/clipboard12_354679.png

/wp-content/uploads/2014/01/clipboard13_354686.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

/wp-content/uploads/2014/01/clipboard14_354687.png

Total time in Post Modify: 55

Overhead in Additional Layer : 55 – 53 = 2 ( 3.6% )

Post Save

/wp-content/uploads/2014/01/clipboard15_354688.png

Total time in Save & Commit: 13 + 6 = 19

Overhead in Additional Layer : (13 – 12) + ( 6 – 3 ) = 4 ( 21.1% )

/wp-content/uploads/2014/01/clipboard16_354692.png

/wp-content/uploads/2014/01/clipboard17_354693.png

Total execution time: 2348 milliseconds

Overhead in Additional Layer : 896 – 348  = 548 ( 23.3% )

Product Modify

/wp-content/uploads/2014/01/clipboard18_354694.png

Total execution time: 58

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

Product Save

/wp-content/uploads/2014/01/clipboard19_354695.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.

/wp-content/uploads/2014/01/clipboard20_354696.png

/wp-content/uploads/2014/01/clipboard21_354701.png

Total execution time: 1160 milliseconds

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

Sales Order modify

/wp-content/uploads/2014/01/clipboard22_354703.png

/wp-content/uploads/2014/01/clipboard23_354707.png

Total execution time: 105

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

Sales Order save

/wp-content/uploads/2014/01/clipboard24_354708.png

/wp-content/uploads/2014/01/clipboard25_354709.png

/wp-content/uploads/2014/01/clipboard26_354710.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:

/wp-content/uploads/2014/01/clipboard27_354713.png

/wp-content/uploads/2014/01/clipboard28_354714.png

/wp-content/uploads/2014/01/clipboard29_354715.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.

What we can benefit from BOL& GenIL

  • The benefit to use Webclient UI framework in CRM custom development is apparent:
  • The object oriented BOL API is simple, generic, uniform and easy to use.
  • 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
  • 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
  • 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.

Thanks a lot for your reading so far. You may also be interested with this blog as well: BOL or Function Modules – Which API to use in CRM Development? from Christian Drumm

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Bjorn-Henrik Zink

    Great blog post. I am sure there are many opinions on how you did the testing, but fact is that it provides a very valuable performance benchmark indication.

    I have experienced many vague performance arguments in various contexts too many times (often to cover that developers opt for what they know the best). Hopefully these types of blog posts will help bury bad performance arguments.

    Thanks for sharing!

    (0) 
  2. Carsten Kasper

    Hey Jerry, I was very excited to read your blog post when I saw the topic. Good news is I was not disappointed! You put very much effort into your research and in my opinion provide interesting insights.

    Nevertheless there are some things I would like to add:

    • You are comparing a single function module call with a BOL Object. Always keep in mind that a GenIL Object is meant as an abstraction of a real world “Business Object”. It includes additional logic. In many cases it is calling additional APIs and/or function modules to enrich the returned data: Descriptions, Links, etc.
    • The first test you did comparing WebClient UI and WebDynpro included so many variables that it might not really reflect how BOL/GenIL compare to each other. The overhead is just to big especially UI.

    The second comparions you did, calling directly from an ABAP report, is much better. It focusses on the data model technology. Though I am not sure if one can speak of “data model” considering a function module…

    As I do not have access to CRM7 EHP3 yet, I can not take a look at the component CRMSM. Thus I can not judge how much additional logic is coded inside the GenIL classes. One additional function module call in GenIL would make the whole comparison kind of unfair.

    It would be really interesting to do this shoot out with a clean and comparable GenIL model! (Maybe CRMSM is already a good one?)

    Three more huge benefits I would like to add for BOL/GenIL:

    1. Already mentioned above: BOL/GenIL is a real data model with abstraction of the technical data to a business representation. A BOL Objects provides aggregated data that is enhanced for ease of use.
    2. Once data it is read, this Object is buffered and you can retrieve it in nearly no time. Way faster than calling various function modules again and afterwards preparing the data for business use.
    3. BOL is a unified programming interface. Every applicaiton runs the same. For function modules everything is different every time.

    Coming back to the performance issue your customer had. To be honest I can completely understand why he thinkgs that BOL is slow. Considering many WebClient applications this is completely correct. Anyway I do not see the fault in the BOL/GenIL overhead. In my eyes it is more an issue of bad design on the UI logic:

    • WebClient and BSP views take long to render. For every server roundtrip the whole HTML of each and every view shown is re-rendered. True, only the changed part is send to the client, but the processing of all Views takes up loads of runtime. Wish SAP would invest some effort there.
    • There is one method that really impacts performance in a negative way ON_NEW_FOCUS. Originally it is meant to keep the context/model of all active views in sync. In large WebClient Components, especially the badly designed ones, it causes loads of unnecessary runtime. Just think of REREAD(), PUBLISH_CURRENT(), … that trigger all event handlers over and over again.

    Sorry for this lengthy comment, but I felt it would add to the discussion. Just feel flattered that your blog post inspired me so much 😉

    cheers Carsten

    (0) 
    1. Jerry Wang Post author

      Hello Carsten,

      Thank you very much for your reading, and so helpful comment! Please kindly see my reply below:

      “You are comparing a single function module call with a BOL Object. Always keep in mind that a GenIL Object is meant as an abstraction of a real world “Business Object”. It includes additional logic. In many cases it is calling additional APIs and/or function modules to enrich the returned data: Descriptions, Links, etc.”

      Reply by Jerry: Yes, I agree. So I call the “additionaly logic / API” as “Additional Layer Overhead” in this blog.

      “The first test you did comparing WebClient UI and WebDynpro included so many variables that it might not really reflect how BOL/GenIL compare to each other. The overhead is just to big especially UI.”


      Reply by Jerry: Yes, I completely agree. My 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.

      “As I do not have access to CRM7 EHP3 yet, I can not take a look at the component CRMSM. Thus I can not judge how much additional logic is coded inside the GenIL classes. One additional function module call in GenIL would make the whole comparison kind of unfair.”.

      Reply by Jerry: Yes, take product search for example, before FM CRM_PRODUCT_GETLIST2 is called, there is lots of logics done in Genil layer like search scenario determination and parameter formatation and conversion. I regard the execution time of all these logics again as Additionaly Layer Overhead. In my next blog, I will try to discussion whether we can get some benefit at the cost of these overheads.

      “As I do not have access to CRM7 EHP3 yet, I can not take a look at the component CRMSM. Thus I can not judge how much additional logic is coded inside the GenIL classes. One additional function module call in GenIL would make the whole comparison kind of unfair.It would be really interesting to do this shoot out with a clean and comparable GenIL model! (Maybe CRMSM is already a good one?)”

      Reply by Jerry: Well from my point of view, I think component CRMSM is very clean, there is almost no other additionaly FM calls in its Genil implementation( our team developed it in EHP3 so I know very much the detail about it)

      “Three more huge benefits I would like to add for BOL/GenIL:”

      Reply by Jerry: Thanks a lot, that is really good summary! I will add it into my workshop for our local partners.

      “WebClient and BSP views take long to render. For every server roundtrip the whole HTML of each and every view shown is re-rendered. True, only the changed part is send to the client, but the processing of all Views takes up loads of runtime. “

      Reply by Jerry: That’s really very interesting topic. When I write this blog the overhead caused by the view rendering in every server roundtrip never comes to my mind. I have added this to my TODO list, maybe I can dig it in more detail if I have time.

      “There is one method that really impacts performance in a negative way ON_NEW_FOCUS. Originally it is meant to keep the context/model of all active views in sync.”

      Reply by Jerry: I never thought of the incorrect usage of ON_NEW_FOCUS. Thank you for drawing it to my attention.

      (0) 
    2. Jerry Wang Post author

      Hello Carsten,

      and I have added your comment on benefit regarding BOL & Genil layer into the conclusion part, combined with some keyword which I extract from internal wiki 🙂

      Best regards,

      Jerry

      (0) 
  3. Stephen Johannes

    This is an awesome blog and is a perfect example of a technical blog on SCN.  Thank you so much for your contribution and this is the type of content that many of need/crave 🙂 .

    Take care,

    Stephen

    (0) 

Leave a Reply