zoukankan      html  css  js  c++  java
  • 引起SAP WebClient UI页面出现超时(time out)错误的另一个原因

    Sometimes you would see the following page if you are clicking anywhere in a page which is idle for quite a long time.

    However, there are definitely some other causes which would also lead to this timeout page – the session itself is not timeout, instead within the session, there are some exceptions raised in the backend and caught by the UI framework. As a result you could not see any dumps in ST22, and this timeout page would sometimes lead you to the wrong way of trouble shooting. For example in this thread, some friend is suggesting to enlarge the related timeout profile in RZ10. For sure that would definitely not work, since the issue in the thread is nothing to do with the real timeout issue, but instead the exception caused by a custom enhancement.

    I would share with you my example how to find the root cause of this kind of I call it “pseudo” time out issue in an efficient way:

    My example

    click the Service Order ID for the first time, nothing happened. Click it again( or any other clickable part in the UI), I get the above timeout page.

    How to figure out the root cause

    I have two different approaches. The first one will take several minutes to find the root cause via debugging.

    (1) Create a breakpoint based on exception class CX_ROOT( for detail see this blog )

    Launch UI and click hyperlink for the first time, the breakpoint is triggered and debugger stopped. In the status bar we get the hint that exception CX_BSP_WD_EXC_WRAPPER occurs. Set another breakpoint in its CONSTRUCTOR method.

    (2) Relaunch the UI, the breakpoint in exception class CONSTRUCTOR is triggered, telling us there is something wrong with a custom UI component ZCUSTOM/MainWindow. In line 51 we know the exception class CX_BSP_WD_INCORRECT_IMPLEMENT. Set the breakpoint in its CONSTRUCTOR again.

    (3) Relaunch the UI, now we find root cause: The overview page tries to display the view defined in ZCUSTOM/MainWindow, however it is not in the parsed component usage repository table ( me->usages in line 4)

    Double check it in UI workbench it is because the custom UI component is added as component usage based on enhancement set A, however currently enhancement set B is active in current client.

    The second approach is even more efficient. You could enable the UI framework to persist the exception which are raised and caught somewhere for example your own Z table with little effort so that it is convenient for you to check them afterwards. For detail steps please see my blog How to persist the UI exception so you can view them later.

    In my example, I could immediately know this issue is caused by incorrect component usage with the exact usage name without debugging.

    If you would like to know why timeout page is always displayed, although it is not a timeout issue at all, please find reason here.

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

  • 相关阅读:
    【LOJ6041】「雅礼集训 2017 Day7」事情的相似度(用LCT维护SAM的parent树)
    【BZOJ1171】大sz的游戏(线段树+单调队列)
    2019年4月训练记录(4.07~4.22)
    【BZOJ4766】文艺计算姬(prufer序列)
    【BZOJ4573】[ZJOI2016] 大森林(LCT)
    2019.03.19 ZJOI2019模拟赛 解题报告
    【牛客挑战赛30D】小A的昆特牌(组合问题抽象到二维平面)
    【洛谷2624】[HNOI2008] 明明的烦恼(Python+利用prufer序列结论求解)
    【洛谷2290】[HNOI2004] 树的计数(Python+利用prufer序列结论求解)
    初识prufer序列
  • 原文地址:https://www.cnblogs.com/sap-jerry/p/13619345.html
Copyright © 2011-2022 走看看