In my previous blog Dropdown list issue in CRM Webclient UI – a very funny trouble shooting process I have shared with you how I deal with an drop-down list issue and how I finally find root cause.
In this blog I will share with you another example how I struggle with another issue which is drop down list relevant and how I decide which place in the code to set breakpoint to start my trouble shooting.
Issue description
Today I received one incident from customer, complaining that they could not successfully create an ERP order. They meet with out of memory issue in UI. How could a creation of ERP order ask for more than 700MB memory???
When I check in ST22, there are lots of SYSTEM_NO_ROLL errors.
Checking Active Calls/Events, I have only two findings:
(1) according to callstack 62, this error occurs when UI framework tries to populate native html source code to be rendered for the end user.
(2) callstack 51 shows the overview page is to be rendered. According to the reproduce steps provided by customer, to be more exact, the issue occurs when ERP order overview page is to be rendered.
Click tab “Source Code Extract”, and I know the system fails to allocate necessary memory for this CONCATENATE operation.
I can not imagine how big the m_content or value could be.
The information in “Chosen variables” could not help me too much:
I realize I have to use debugging once again. But where do I set breakpoint?
My issue analysis process
Since all call-stacks displayed in ST22 are webclient ui framework stuff, if I set breakpoints there, they will no doubt be triggered again and again, do nothing helpful for my analysis.
I just set two breakpoints in DO_PREPARE_OUTPUT of ERP Order header view and item view.
Both methods are executed successfully in debugger, nothing strange.
What kinds of UI element would lead to a large response stream to browser
Since this issue is caused by the huge memory allocation for the to-be-rendered html page, we can think about what kinds of UI element would lead to a huge response stream?
As far as I know, there are following candidates:
(1) A long long web page with lots of text content.
When talking about webclient UI, the possible scenario is that a text-area has lots of characters. However this is not the case for this incident.
In ERP creation page it is impossible to have a long text which needs 700MB to display.
(2) A table with so many entries.
In ERP_IT/ItemTab there is indeed a table element, however since currently we are in ERP order creation page, there is no item record at the creation phase.
(3) A drop down list with so many entries.
If you have gone through my previous blog, you can know that the keys and descriptions for each entry in a drop down list will be included in the html source code. So in theory, if a drop down list has a hug number of entries, it is also possible to generate a large response stream.
So now all context node attributes which has implemented method GET_V_XXX are suspects. So I have set breakpoint on all of them.
And soon I have found the one who makes troubles, the GET_V_SPART. Totally 408089 entries are returned by method cl_crm_uiu_erp_order_vh=>get_values_for_spart.
When this big drop down list is finally being rendered, the handler class CL_THTMLB_SELECTION_BOX has to populate the final html source code for these 408090 entries, and run out of memory.
Since root cause is found, I asked responsible colleague to have a look why such huge numbers of entries are returned, as this absolutely does not make sense for end users.
Hope this tip of mine to choose where to set breakpoint could help for your trouble shooting. Of course in this case memory inspector s_memory_inspector could also help you identify code which generates high memory demand.
要获取更多Jerry的原创文章，请关注公众号"汪子熙":