Debugging Problems

Sometimes, to the frustration of each developer, the debugger just refuses to start. This guide discusses typical problems that can cause this failure. Documentation is available and recommended reading!

Switching into Source Mode

When debugging BSP page, do not forget to switch debugger into source level mode. Use button, highlighted on figures below.

When debugger appears it shows only layout of the BSP page:

You can also see code of the class generated from BSP layout:

Troubleshooting if the Debugger does not Appear

• You must run your BSP application on the same server where you have set the breakpoint. Check that the server name from the URL is actually exactly the same server on which the breakpoints are set. This is especially important when a SAP Web Dispatcher is used.

• You must use the same user in the browser as for which the break-points have been set. This is especially important in cases where X.509 certificates are used to log you in under a different name from the browser, or in cases where user mapping is used for a URL started from a portal server. In all cases, set the breakpoints for the user under which the BSP application will be run!

• Same client. Especially if you have the same user in different clients. Use sap-client=123 on the URL if you wish to force the BSP application into a specific client.

• If you set breakpoint inside of classes, the breakpoints must be external breakpoints and system debugging must be switched on.

Application only Works in Debugger

For each HTTP request of a BSP application, there is a transition from kernel code to ABAP code. At this moment a "dark" dynpro is started in which context the BSP application is executed in ABAP. However, with this dynpro it is NOT possible to execute any forms of ABAP code that requires a running SAPGUI (for example file downloading, call screen, etc). Thus the code will fail. However, once a break-point is set, the next HTTP request for a BSP page will run in context of the full blown dynpro that is executed in a newly started SAPGUI window. Now suddenly the SAPGUI is available, and all the ABAP code executes correctly. This is a difficult problem to find, as one can not know where in a deep CALL FUNCTION sequence suddenly code requires the availability of a SAPGUI. Effectively only with debugging can one get a feeling of what code is executed, and what would make no sense in the context of a web application running normally with a SAPGUI.

See also: BSP In-Depth: MESSAGE Statement Handling.

Debugging with a Web Dispatcher

The problem is that break points are local to the application server on which they are set. So the BSP application must be tested against exactly this specific application server. Now, if a Web Dispatcher is used with load balancing, it could happen that the Web Dispatcher selects another application server, which means that no break-points work. One idea could be to by pass the Web Dispatcher, and change the URL so that the requested application server is addressed directly. However, if all requests must traverse the Web Dispatcher, it is required to override the loadbalancing and force all our requests must be routed to the specific application server where the break-points are set. For this to work, first the Web Dispatcher must be configured to support a host selection with the profile parameter: wdisp/enable_sap_hostid = TRUE. In addition use the URL parameter ?sap-hostid=boxName_systemName_instanceNr to select the required application server. For example: http:// .../sap/bc/bsp/sap/myApp/myPage.htm?sap-hostid=us4049_B20_21.

For stateful applications, once the application is started on a specific application server, it will stay on that application server. The problem is just forcing the first request for the BSP application onto the specific application server where the break-points have been set.