Was this page helpful to you?
Do you have any additional feedback?
You can use debugging in order to carry out detailed troubleshooting. With the debugger, you check a given section of code in the Request Handler or an ABAP function module for errors.
Basically, there are two different types of debugging:
· With conventional debugging, you can analyze programs that you call up within your own user session on the server, with breakpoints being set at corresponding points in the coding.
· With external debugging, you can analyze programs that are called up by an external user with HTTP. For the purpose of external debugging, special breakpoints (external breakpoints) are set on the target server.
Two variants are available for conventional debugging: the classical variant and the new (2-processor) variant, which creates a separate session for the debugger. At present, external debugging can only be performed with the classical variant.
This section deals especially with external debugging, as it is generally makes sense to call up an external user completely (with all sent parameters) in one step when investigating ICF processes.
Prior to Release 640, the external debugging described below was known as HTTP debugging.
· If you use load distribution for your system environment, the server group (logon group) is reduced to one server before debugging commences.
· Ideally, the user who performs the debugging should not be a collective user.
Note that the troubleshooting method described here can affect your system performance. You should therefore only activate it if you really need it. You are advised to monitor the corresponding settings regularly and to deactivate any functions you no longer require.
In transaction SICF, you can use the external debugger to set external breakpoints and check the debugging of the relevant section of code:
1. Select the required service in the service hierarchy.
2. Choose Edit → Debugging → Activate Debugging.
3. Enter the required data (if you have selected the service previously, the system will propose the service path for you).
The path always begins with the first node below the virtual host.
Example: for service /default_host/sap/bc/ping, enter /sap/bc/ping.
For certain paths, you can also set the external breakpoints directly in the ABAP coding. Procedure:
4. Log on to the application server on which you want to execute the HTTP requests.
5. In one of the Development Workbench transactions (SE38, SE37, SE80 and so on), choose Utilities → Settings → Debugging → External Debugging
6. Under User, enter the user with which you perform your HTTP application.
If you want to perform debugging for a collective user, you should select the IP Matching checkbox. In this way, you can restrict the HTTP session in which the debugging is running to a specific host. Debugging with IP Matching activated works correctly only if the HTTP requests are executed without a proxy, and the requests are triggered from the same computer on which you have set the external breakpoints with the SAPGUI.
7. Use the Set/Delete External Breakpoints button to position the external breakpoints in the required locations in the ABAP code.
For information on debugging under load distribution, see:
For detailed information on the conventional ABAP debugger (classical and two-processor) variants, see:
With trace files, you can check the ICF runtime (especially Kernel functions) if troubleshooting with the debugger does not provide the desired result. For detailed information on trace functions, see:
The following content is not part of SAP product documentation. For more information, see the following disclaimer .