Register Login

Web Dynpro Error page, Error situations and Error codes

Updated May 18, 2018

It describes how a user should analyze the Web Dynpro error page that is shown during the occurrence of an error while procesing a Web Dynpro application. It also discusses about the well-known error codes and error situations which are not related to funtional correctness of the UI runtime. 

Analyzing error page information:

An error page is shown, when an error occurs while processing a request to a Web Dynpro application. 

System runs in development mode:

The error page contains following details about the related error, if the system runs in development mode.

•    Exception text and error code
•    System information, like version of the used Web Dynpro runtime, Web AS version, etc.
•    Correction hints are shown if a well-known error situation has occured that is not related to a bug in the Web Dynpro runtime.

The stacktrace of the exception is shown in a short version and additional in a full version at the bottom of the error page, if the error page is shown due to an unexpected error situation. Usually, causing exceptions are nested in such stacktraces. Nested Exceptions can be identified by 'Caused by' prefix. For finding the root cause of the problem, the last nested exception of the stacktrace is relevant. This is the exception after the last 'Caused by'.

The complete error page should be saved as HTML file and attached to the CSN message, if the shown error page results in a CSN. 

System runs in productive mode:

The error page only shows a log ID which references to the detailed exception stacktrace in the trace or log file, if the system runs in productive mode. For further analysis the related defaultTrace.trc and log file should be checked. This can be done by the system administrator. For disabling the reduced error page, the administrator can be connected to the Java EE telnet console and following command should be typed:

> setsp -p DetailedErrorResponse true http
If the shown error page results in a CSN, the related defaultTrace.trc, and log file should be attached to the CSN message. In addition, the system information page should be saved as HTML file and attached to the message (-> Web AS start page -> System Information). 

One can look 742674 for more information on how to get the defaultTrace.trc and System Information. For more information on how to switch between productive and development mode see 962319.

Description of well-known error situations, their reasons and solutions:

In the Web Dynpro runtime, there are some well-known error situations which are not related to a bug or functional incorrectness. The following list shows such error situations, grouped by exceptions and error codes, and explains their causes and possible solutions.

SessionLimitExceededException:

What is the indication for SessionLimitExceededException to occur?

The error page is shown with either a com.sap.tc.webdynpro.services.SessionLimitExceededException

•    Error code: 403 – Forbidden

Why does this error occur?

By a single user in one user session, there is configurable maximum number of sessions which can be started. The error page comes up, if this maximum limit is exceeded. There is an extra user session per browser process (respectively per browser login). Web Dynpro counts following sessions within a user session:

Web Dynpro applications running without the portal

When running within the portal, portal pages containing embedded Web Dynpro applications are counted. It guarantees that in the portal a portal page that contains Web Dynpro applications is either shown completely or not at all.

How to get this error resolved?

One should close external browser windows or browser tabs to reduce the number of active sessions.

The administrator can configure maximum number of allowed sessions per user session, via the parameter "sap.max.session.limit" in the Web Dynpro default.properties (for details, see1012065), if it is too small in general.

LockException:

What happens during LockException error?

The error page is shown with a com.sap.tc.webdynpro.services.session.LockException

•    Error code: 408 -Request Timeout

Why does this error occur?

Web Dynpro provides a single-threaded programming model. The user session is blocked for the duration of the request, i.e. there is always at most one thread that has acquired the lock of a user session, as soon as a request for a user session is processed. Concurrent requests which refer to the same user session (i.e. triggered from the same browser process) are serialized and processed one after each other. The other concurrently incoming requests are waiting for a certain period of time that the user session lock is released, if there is a request which blocks or hangs due to some waiting/blocking condition. The waiting thread terminates with a LockException error page, if they can't acquire the user session lock after this time interval. 

How can this error be resolved?

The LockException error page shows a 408 error code and the stacktrace of the thread that holds the user session lock and that is responsible for the blocking/waiting condition. The stacktrace should be forwarded to the development group or CSN component that can help to understand the shown stacktrace and can explain the waiting/blocking condition. An administrator might want to configure the maximum time for which an incoming request will wait if the user session lock is already taken, if there are intended long running requests which hold the user session lock for a longer time. In the Web Dynpro default.properties (for details, see 1012065), this can be done via "sap.locking.maxWaitInterval" parameter. 

SessionExpiredLongJumpException:

What happens during SessionExpiredLongJumpException error?

The error page is shown with a com.sap.tc.webdynpro.clientserver.session.SessionExpiredLongJumpException.
•    Error code:400 - Session Timeout

What is the cause for the above mentioned error?

•    Cause 1: A started application was untouched for a certain period of time and has expired in the meantime. It happens as an asynchronous server event and the client is not notified 
about this happening. The user gets notified about it the next time when a request to the expired application is triggered and the error page with the SessionExpiredLongJumpException comes up.

•    Cause 2: The application that is started on the client is stopped/removed/redeployed on the server. This kind of action leads to a termination of the depending sessions on the server. 
The user gets a SessionExpiredLongJumpException when triggering the next request to the related application. 

How can this error be resolved?

The user should restart the application (browser refresh, or "Refresh" entry in the IView tray menu in the portal).

DispatcherException:

What happens during the occurrence of DispatcherException error?

The error page is shown with a com.sap.tc.webdynpro.services.sal.core.DispatcherException.

•    Error code:500 - Internal Server Error

Why does this error occur?

•    Cause: The requested application is not deployed on the server.
•    Cause: There is a typo in the application URL, i.e. the URL doesn't address an existing and deployed application.

How can this error be resolved?

 A user must check the URL for typos; and should contact the system administrator whether the requested application is deployed at all.

"Failed to process the request: Request refers to an unknown session":

What happens during the above mentioned error?

The error page is shown with message text: "Failed to process the request: Request refers to an unknown session".

•    Error code: 404 - Application Not Found 

Why does this error occur?

The server received a request which refers to an assumingly existing application session which is unknown to the server.

How to get this error resolved?

This error occurs when the client has sent an incorrect request to the server, or the request dispatching mechanism of a cluster incorrectly dispatched a postback/follow-up request to a wrong server node. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to an OSS message. For checking whether a wrong request dispatching is the problem, it should be checked whether the loadbalancing cookie "sap_lb" contains the same value over the sequence of requests. When this is not the case, it indicates that the request was dispatched to the wrong server node during the sequence of requests.

"Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.":

What happens during the occurrence of the above mentioned error?

The error page is shown with message text: "Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session."

•    Error code: 400 - Suspend Error

Why does this error occur?

The server received a request which refers to an assumingly suspended application session which was destroyed because the application is marked as non-suspendable.

How to get this error resolved?

It occurs when a request is sent with previous session parameters. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to 
an OSS message. It should be checked whether the request contains the request parameters "sap-wd-norefresh" or "sap-wd-cltwndid". 


×