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.
