0% found this document useful (0 votes)
28 views19 pages

OData Error Handling

The document outlines OData error handling, detailing common HTTP response codes for success (2XX) and error (4XX/5XX) responses. It also describes how to use error logs in SAP Gateway and the methods for exception handling, including business and technical exceptions, as well as message container management for conveying errors. Various methods for adding messages to responses are provided, along with examples of handling both single and multiple messages in OData services.

Uploaded by

vishnu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views19 pages

OData Error Handling

The document outlines OData error handling, detailing common HTTP response codes for success (2XX) and error (4XX/5XX) responses. It also describes how to use error logs in SAP Gateway and the methods for exception handling, including business and technical exceptions, as well as message container management for conveying errors. Various methods for adding messages to responses are provided, along with examples of handling both single and multiple messages in OData services.

Uploaded by

vishnu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

OData Error Handling

Common HTTP Response Codes:


When working with OData, understanding HTTP response codes is crucial for interpreting the
results of your requests. Here's a breakdown of common HTTP response codes encountered
in OData.

Success Responses
Success Codes indicate that the request is successfully processed / received. (2XX)
Response Code Information
200 (Ok) Indicates that the request was successful, and the response
contains the requested data. This is common for GET requests.
201 (Created) Indicates that the request was successful, and a new resource
was created. Commonly used for successful POST requests.
202 (Accepted) Indicates that a batch request has been accepted for processing,
but that the processing has not been completed.
204 (No Content) The request was successful, but there is no content to return in
the response body. Often used for successful DELETE requests or
updates where no response body is needed.

Error Responses
Error Codes indicate that there is an error within the request or in the response. (4XX/5XX)
Response Code Information
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.
415 (Unsupported Media Type) The server refused to accept the request because the
message content format is not supported
200 (OK)

201 (Created)

202 (Accepted)
204 (No Content)

400 (Bad Request)

403 (Not Found / Forbidden)


404 (Not Found)

405 (Method Not Allowed)

501 (Not Implemented)


500 (Internal Server Error)

415 (Unsupported Media Type)


SAP Gateway Error Logs
Error logs provide detailed context information about errors that have occurred at runtime,
enabling you to perform root cause analysis, as well as reproducing and correcting errors.

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. You can launch the error log with transaction /IWFND/ERROR_LOG in Gateway
Hub systems. Launch the error log with transaction /IWBEP/ERROR_LOG in your back-end
system.

/IWFND/ERROR_LOG is executed in Central Hub when it is applicable. For embedded


deployment everything is executed in same system. From this transaction, backend error log.

Active Source – The Active Source button enables you to navigate directly to the source code
where the error occurred and the exception rose.
Error Context – For further information, select the line with the error you are interested in.
The error context provides detailed information about the error that occurred
Download to PC – If you are not able to solve the problem by yourself, you can download the
error description by choosing the Download to PC button.
Upload from PC – you can upload the error description to another system in order to check it
there
To reach the Backend Errors, use transaction code /IWBEP/ERROR_LOG in the backend
system or you can reach it from transaction /IWFND/ERROR_LOG by using the
dedicated Backend Monitor button. It will redirect you to the backend system.

Similar buttons can be found here as in the frontend Error Log to get further information about
the error:
• Error Context
• Active Source
• Download to PC / Upload from PC
• Service Implementation
Exception Handling in Odata
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
exceptions /iwbep/cx_mgw_busi_exception and /iwbep/cx_mgw_tech_exception from the
methods.

/IWBEP/CX_MGW_BUSI_EXCEPTION (Business Exception):

This exception is used to signal errors that arise from business logic or business rule violations.
These errors are typically related to the data itself or the business processes being executed.

Examples include:

• Invalid data input (e.g., incorrect date format).


• Authorization failures at the business logic level.
• Violations of business rules (e.g., insufficient stock).

/IWBEP/CX_MGW_TECH_EXCEPTION (Technical Exception):

This exception is used to signal errors that arise from technical issues or system malfunctions.
These errors are typically related to the underlying infrastructure or code execution.

Examples include:

• Database connection errors.


• Type conversion errors.
• Runtime errors in ABAP code.
• System configuration issues.

Message Container:
For raising error messages first, we have to prepare a message container. Message Container
is used to add corresponding success or error messages to the response of the OData service.
We use a standard interface /IWBEP/IF_MESSAGE_CONTAINER to add the messages to the
OData response.

To add a message to the message container, we can use any of these methods in the message
container interface apart from these 5 methods other methods also available.

• ADD_MESSAGE - Adds an error message


• ADD_ERROR_DETAIL – Add error detail to the OData Inner Error section.
• ADD_MESSAGE_TEXT_ONLY – Adds an Error text without Message Details
• ADD_MESSAGE_FROM_BAPI – Adds one message of type BAPIRET2 to the message
container
• ADD_MESSAGES_FROM_BAPI – Adds messages of type BAPIRET2 to the message
container
ADD_MESSAGE: Using this method we can handle both single and multiple messages to
response. ADD_MESSAGE required message class, id and type of the message. For this
we have to create message class in SE91 T-code and have to add messages with message
numbers.

Handling Single Message in response:

METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

lo_msg->add_message(
iv_msg_type = /iwbep/cl_cos_logger=>error
iv_msg_id = 'ZMSG_SSS'
iv_msg_number = '001' ).

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception


EXPORTING
message_container = lo_msg.

ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.

ENDMETHOD.

Output:
Handling Multiple Messages in response:

METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

lo_msg->add_message(
iv_msg_type = /iwbep/cl_cos_logger=>error
iv_msg_id = 'ZMSG_SSS'
iv_msg_number = '001' ).

ENDIF.

IF er_entity-c_name IS INITIAL.

lo_msg->add_message(
iv_msg_type = /iwbep/cl_cos_logger=>error
iv_msg_id = 'ZMSG_SSS'
iv_msg_number = '002' ).

ENDIF.

" Collect messages into an internal table


DATA(lt_messages) = lo_msg->get_messages( ).

" Raising Exception if there are validation errors


IF lines( lt_messages ) > 0.
" Raising Exception
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
message_container = lo_msg.

ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.

ENDMETHOD.
Output:
ADD_ERROR_DETAIL: Here we have to pass error detail work area of type
/IWBEP/IF_MESSAGE_CONTAINER=>TY_S_ERROR_DETAIL. Since it is work area, we cannot
pass error details directly to method because we have more than one validation. Instead we
have to assign details to a local work area and then we have to pass that work area into that
method parameter.

Handling Message in response:

METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

DATA: lv_has_errors TYPE abap_bool VALUE abap_false.


" Work Area for Error Detail
DATA : ls_error TYPE /iwbep/if_message_container=>ty_s_error_detail.

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

ls_error-message_text = 'Enter Customer Id'.


ls_error-severity = 'E'.
lo_msg->add_error_detail(
EXPORTING
is_error_detail = ls_error ).
lv_has_errors = abap_true.

ENDIF.

IF er_entity-c_name IS INITIAL.

ls_error-message_text = 'Enter Customer Name'.


ls_error-severity = 'E'.
lo_msg->add_error_detail(
EXPORTING
is_error_detail = ls_error ).
lv_has_errors = abap_true.

ENDIF.

" Raising Exception if there are validation errors


IF lv_has_errors = abap_true..
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
message_container = lo_msg.
ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.

ENDMETHOD.
Output:
ADD_MESSAGE_TEXT_ONLY: In this method no need of passing message class, id, type
instead we directly have to pass message text and type whether it is Error/ Warning/Success.

Handling Message in Response:

METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

lo_msg->add_message_text_only(
EXPORTING
iv_msg_type = 'E'
iv_msg_text = 'Enter Customer id' ).

ENDIF.

IF er_entity-c_name IS INITIAL.

lo_msg->add_message_text_only(
EXPORTING
iv_msg_type = 'E'
iv_msg_text = 'Enter Customer Name' ).

ENDIF.

" Collect messages into an internal table


DATA(lt_messages) = lo_msg->get_messages( ).

" Raising Exception if there are validation errors


IF lines( lt_messages ) > 0 .
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
message_container = lo_msg.
ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.

ENDMETHOD.
Output:
ADD_MESSAGE_FROM_BAPI: We have to pass BAPI work area and also target id i.e, message
class name. since we have to pass work area name to the method first we have to assign BAPI
message detail to work area.

Handling Message in Response:


METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

" Bapi Workarea


DATA: ls_bapi TYPE bapiret2.

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

ls_bapi-id = 'ZMSG_SSS'.
ls_bapi-number = '001'.
ls_bapi-type = 'E'.
lo_msg->add_message_from_bapi(
EXPORTING
is_bapi_message = ls_bapi " Return Parameter
iv_message_target = 'ZMSG_SSS' " Target (reference)(e.g.Property ID) of a message
).

ENDIF.

IF er_entity-c_name IS INITIAL.

ls_bapi-id = 'ZMSG_SSS'.
ls_bapi-number = '002'.
ls_bapi-type = 'E'.
lo_msg->add_message_from_bapi(
EXPORTING
is_bapi_message = ls_bapi " Return Parameter
iv_message_target = 'ZMSG_SSS' " Target (reference)(e.g.Property ID) of a message
).

ENDIF.

" Collect messages into an internal table


DATA(lt_messages) = lo_msg->get_messages( ).

" Raising Exception if there are validation errors


IF lines( lt_messages ) > 0.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING
message_container = lo_msg.
ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.
ENDMETHOD.
Output:
ADD_MESSAGES_FROM_BAPI: This method will add multiple messages in OData response.
For this we have to pass BAPI internal table. Since it is internal table we cannot directly pass
messages to method instead we gave to append message details to internal table first then
we have to pass that internal table to method.

Handling Message in Response:

METHOD customerset_create_entity.

" Read Requested Data


io_data_provider->read_entry_data(
IMPORTING es_data = er_entity ).

" Bapi Internal Table


DATA: lt_bapi TYPE TABLE OF bapiret2.

" Instantiate Message Container


DATA(lo_msg) = me->/iwbep/if_mgw_conv_srv_runtime~get_message_container( ).

" Validations
IF er_entity-cid_no IS INITIAL.

APPEND VALUE #( id = 'ZMSG_SSS' number = '001' type = 'E' ) TO lt_bapi.

ENDIF.

IF er_entity-c_name IS INITIAL.

APPEND VALUE #( id = 'ZMSG_SSS' number = '002' type = 'E' ) TO lt_bapi.

ENDIF.

" Raising Exception


IF lt_bapi IS NOT INITIAL.

lo_msg->add_messages_from_bapi(
EXPORTING
it_bapi_messages = lt_bapi ).

RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception


EXPORTING
message_container = lo_msg.

ELSE.
INSERT zodata_customer FROM er_entity.
ENDIF.

ENDMETHOD.
Output:

You might also like