In this post you will learn about the errors in OData Services, trouble-shooting tools available and how to debug the service. Before starting with the trouble-shooting it is important to understand what HTTP response codes mean.

Common HTTP Response Codes

Success Codes indicate that the request is succesfully processed / received. (2XX)

Response CodeInformation
200 (OK)Indicates that a request has been received and processed successfully by a data service and that the response includes a non-empty response body.
201 (Created)Create Entity is executed successfully
202 (Accepted)Indicates that a batch request has been accepted for processing, but that the processing has not been completed.
204 (No Content)Indicates that a request has been received and processed successfully by a data service and that the response does not include a response body.

Error Codes indicate that there is an error within the request or in the response. (4XX/5XX)

Response CodeInformation
400 (Bad Request)Indicates that the payload, request headers, or request URI provided in a request are not correctly formatted according to the syntax rules defined in this document.
403(Not Found / Forbidden)Service not found
404 (Not Found)Resource not found
405 (Method not allowed)Incorrect URI & HTTP method combination
501 (Not Implemented)Method is not implemented
500 (Internal Server Error)Indicates that a request being processed by a data service encountered an unexpected error during processing.

Note that these are not exhaustive lists of status codes and those can be found in Microsoft documentation of HTTP status codes.

In the earlier post Testing CRUD-Q operations from Gateway Client, all the success scenarios are covered. Some of the error codes can be simulated as below.

400 (Bad Request) – Extra ‘ character after key-value AI in the request causes the error. When you get a such an error, check the URI.

403 (Forbidden) – incorrect service name in the URI can lead to this error.

405 ( Method not allowed ) is triggered when the HTTP method and URI combination are not correct. The below example shows that a POST method is used with URI that has key information which makes it invalid.

501 (Not Implemented) occurs when the operation is called but relevant method is not implemented in DPC_EXT class.

Error Log Transactions

One of the most important tools to troubleshoot is Error Log. As Gateway can be either embedded or deployed as a central hub, there are front-end and back-end components to SAP Gateway. Similarly, there are front-end and back-end error log transactions.

/IWFND/ERROR_LOGFront-end Error Log
/IWBEP/ERROR_LOGBack-end Error Log
ST22ABAp Short Dump

/IWFND/ERROR_LOG is executed in Central Hub when it is applicable. For embedded deployment everything is executed in same system.

From this transaction, you can go to ST22, or backend error log. You can see the request and response data and replay the request as well.


This transaction shows the error and you can go to the Service Implementation from this transaction.

The error logs can be called from the Gateway Client right after getting the results as well using the error log button.


Trace can be enabled and viewed using /IWFND/TRACES. As the transaction code suggests, it is a frontend component transaction.

  • The trace level can be set using the drop-down for field Error Log Level.
  • Trace is enabled or disabled with the checkboxes

If the trace is required for some other user, the user can be changed using the user icon.

Once the trace is set, execute a request and check the results.

Performance Trace

Payload Trace

Exception Handling

One important aspect of developing the OData service is to use the exceptions correctly to convey errors to front-end consumers.

A typical way to do this is to use the exceptions /iwbep/cx_mgw_busi_exception and /iwbep/cx_mgw_tech_exception from the methods.

We can use the standard interface /IWBEP/IF_MESSAGE_CONTAINER to add the messages to the OData response. It has below methods to help add the error details.



  • Exceptions /IWBEP/CX_MGW_BUSI_EXCEPTION and /IWBEP/CX_MGW_TECH_EXCEPTION are inherited from the same class
  • RAISE EXCEPTION TYPE Or RAISE EXCEPTION NEW (7.52+) statement can be used

Code Sample

DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).
lo_msg->add_message( iv_msg_type   = /iwbep/cl_cos_logger=>error
                     iv_msg_id     = 'ZJP_SO'
                     iv_msg_number = '001'
                     iv_msg_v1     = CONV #( lv_po_number ) ).
"Using earlier syntax
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
    message_container = lo_msg.

"Using new syntax
RAISE EXCEPTION NEW /iwbep/cx_mgw_busi_exception(
    message_container = lo_msg ).

Cash Clean up

Cash clean-up would be required in case changes made to the service are not appearing in the front end or the service response. There are various cache cleanup transactions available, which are explained in note 2319491. Be careful while using this transaction as they may impact performance of the syetem.

Cache Clean Up Transactions

  • /ui2/cust – SAP Fiori–>Data Administration–>Invalidate Caches
  • /iwfnd/cache_cleanup
  • /iwbep/cache_cleanup

Cache Clean Up Programs

  • /ui2/invalidate_client_caches
  • /ui2/invalidate_global_caches
  • /ui5/del_odata_metadata_cache

Apart from this, /IWFND/GW_CLIENT also has menu Metadata to clear / rebuild cache.


Debugging is also explained in an earlier post Building OData Services [4] : Register and Test OData Service. Simply, identify the method which is expected to be triggered and add an external break-point.

Then execute the service request.

Debugger it started with the break-point set.

This way works from Gateway Client, external tool like Postman or from UI5/Fiori Application as well.

What if debugging is not triggered?

  1. Make sure that the code is activated and correct method is selected to place a break-point
  2. External Break-point is selected and not session break-point
  3. Debugging settings for the user are accuarate.

If all these are followed and if the debugger is still not started, then use SICF to activate the debugging. Enter the Service Name and Execute.

On the next screen, follow the menu path Edit > Debugging > Activate Debugging.

Then re-execute the request and debugger would be triggered.

Using all these trouble-shooting tools and instructions – you should be able to figure out and fix something that is not working in your OData Service.

Visit OData Development in SAP to explore all articles on OData.

If you like the content, please subscribe…

Join 4,024 other subscribers

Discovering ABAP YouTube Channel