Skip to Content

Timeout page and WebUI freezing issue – Another cause

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.

You must be Logged on to comment or reply to a post.
  • Jerry, very interesting question you've raised. Thank you for the tip how to store the actual error for later analysis!

    But I wonder if you know the reason why an exception may cause this "timeout page" instead of the classical one (BSP error page like this We faced such an issue during one of the latest projects. The exception always led to "timeout" page. But it only occured in DEV and QA systems. And everything was fine in production system (if we can say "fine" talking about BSP errors in Prod 🙂 )

    • Hi Andrei,

      Yes your question is also quite interesting. I am not the expert on this area, I guess perhaps it is related to some configuration regarding error page in SICF? Or we can also debug the error handling code of UI framework to find out why, it will spend some time for investigation...

      Best regards,


      • Jerry, afaik there is no additional configuration done on SICF level. Which level to debug you suggest? Will CL_HTTP_EXT_BSP->REPORT_ERROR be a good place to start from?

        • Hi Andrei,

          I am not sure, recently I have headache with a performance issue from one Chinese customer, so have not more time to dig it further. Maybe you could figure it out soon and I am looking forward to another informative blog from you 🙂

          Best regards,


          • Hell Jerry.

            Late response from my side but anyway thank you! Your document is good, but it didn't answer my question: why the same error (exception) in one system displays standard BSP error page and in other system (quite similar from SP point of view) displays this erroneous timeout page? Your document answers different question. I can formulate it as "How the timeout page is built?".

            Anyway thank you for the try. I have no permanent access for that landscape where I can research the issue. But as soon as I can I will share a reason.