日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 编程资源 > 编程问答 >内容正文

编程问答

SAP Fiori应用发生超时错误的一个可能原因

發(fā)布時間:2023/12/19 编程问答 27 豆豆
生活随笔 收集整理的這篇文章主要介紹了 SAP Fiori应用发生超时错误的一个可能原因 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

Yesterday I spent almost the whole day to resolve a timeout issue in one CRM Fiori application “My Lead”. Finally the root cause makes me not know whether to launch or to cry. I share with you this story, in case you might meet with similar issue, you do not need to spend much time to debug as I did yesterday.

In CRM “My lead” application, end user can insert several products to a lead at the same time.

User can click “+” button to open product value help, then select the products they need to add to the lead.

The issue is, when the testing colleague uses the test user ( we say user A ) to insert the products to the lead, they will meet with time out error below, when the amount of selected products exceeds 15.


Much to my surprise, when I use my own user ( user B ) to test, the issue could not be reproduced, it only took 1 seconds to finish the insertion with 20 products selected. Why?!

My analysis process

(1) I debugged the insertion with test user A. The product insertion to lead is done by CRM function module CRM_ORDER_MAINTAIN. The product insertion within this FM is done via a LOOP internally, which means each product is inserted separately. For totally 20 product insertions, I trace the execution time, it took around 40 seconds to finish, which is definitely not acceptable.

(2) I use transaction code SAT to trace the single product insertion with test user A, it took around 2 seconds. It seems the execution time increases linearly with the number of product to be inserted. Also the 2 seconds for a single product insertion is not acceptable – too slow!!

(3) Unfortunately, through the SAT record, I cannot find a bottleneck of the execution. The complete execution, each stack, is very slow. But when I debug with my own user, each stack is very very fast.

What are possible elements which causes the difference

(1) I had made assumption that the two users are testing on different Lead transaction type. Different transaction type could have different callback registered, so when the lead is saved, different program could be executed. This element is eliminated after my check – both user are working on exactly the same transaction type.

(2) The backend implementation has some code like

CALL FUNCTION 'XXXXX'EXPORTINGiv_user_name = sy-uname

The reason I made this assumption is since the execution differs based on user, so there must be some handling in code which is based on user name.

I did spend much time to go through the code and the answer is no.

Final answer

I felt frustrated and almost gave up. Suddenly I am thinking about the possibility of user setting difference??

Bingo! The testing user has switched on One order framework event trace via the user parameter CRM_EVENT_TRACE.

This trace functionality is expensive which leads to the overhead of the whole program execution. And since it is done centrally in the one order framework, it is the reason why I didn’t find any hint in my application code.

Lessons learnt

So here is lessons learnt:

Next time if I meet with the similar issue that the performance on the same application with different users varies greatly, besides the two mentioned checkpoints in chapter “What are possible elements which causes the difference“, there is last but not least one: check whether there are different users settings between the two users( for example tcode SU01, or any other customizing in your specific area ).

要獲取更多Jerry的原創(chuàng)文章,請關注公眾號"汪子熙":

總結(jié)

以上是生活随笔為你收集整理的SAP Fiori应用发生超时错误的一个可能原因的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯,歡迎將生活随笔推薦給好友。