Show TOC

Debugging Query OptionLocate this document in the navigation structure

Applications can test their OData services by using the debugging query option sap-ds-debug. You use this query parameter to get additional options for accessing the service's data and to get additional information about the processing of an OData client call.

You can activate the debugging query option on a given OData service by adding the query parameter sap-ds-debug=true to the URL.


If you want to attach the document to a support ticket, you can also use sap-ds-debug=download.

Example: http://<server>:<port>/sap/bc/odata_sk/Employees?sap-ds-debug=download

The option ?sap-ds-debug=true instructs the ABAP backend not just to return the plain XML or JSON data to a service client, but to incorporate that data into a dynamically generated HTML page for your convenience. The data becomes more readable and navigation becomes automatically available in the browser because the returned links are generated as HTML links. In addition, this option provides additional technical information on the call itself: Details are displayed on the HTTP request and response, the (HTTP) environment of the call, a small runtime analysis and details on URI options used. This option may vary on different ABAP codelines and is subject to change.

You can freely navigate between the different screen areas with the normal mouse navigation. Alternatively, you can use keyboard navigation (arrow keys) and the tabulator and Enter keys.







To get additional information from the ABAP backend using this URI option, the user performing the data service call has to have ABAP debugging authorization, that is, an authorization for authorization object S_DEVELOP with value DEBUG for field OBJTYPE and value 03 for field ACTVT.

In addition, in your browser, JavaScript has to be enabled.

Exception Handling in OData

Generic exception handling in OData can make error investigation very difficult.

For example, you might have a conversion error in your application coding. The error information in the client browser is not very useful, as it is a general 500 internal server HTTP error. To further investigate such an error, you can use the debugging query option: Simply add the debugging query option parameter to the URL and go to the Stacktrace page. There you can see useful context information and the location where the original dump occurs.

Figure 1: Stacktrace Example