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.