OData and SAP Netweaver Gateway. Part XI. Query Options & HTTP Status Code Summary

CRUD is the jargon used in OData for the below Operations. Since we are at Part XI of SAP Netweaver Gateway and OData Services Tutorial, we all know it and we do not want to elaborate more.

HTTP Method Description 
GET The GET method is used for FETCHing information from the server using a URI. Requests using GET only retrieves data and would have no other effect on the data.
POST  A POST request is used for CREATing data in the server (SAP Backend). 
PUT  A PUT request is used for UPDATing data in the server (SAP Backend). 
DELETE  A DELETE request is used for REMOVing data from the server (SAP Backend). 

OData Query Options

Query Options means what are the additional parameters/syntaxes can we add to the OData Service URI to perform extra work. These options are the links we prepare and send from front end (SAPUI) client system. Filter, Orderby, Expand or our simple Format are some of the commonly used Query Options.

The OData Query Options supported by SAP NetWeaver Gateway are of 2 Types:

i) Automatically available in the framework, with NO further programming change needed. Example $format, $count etc do not any custom code. They are inbuilt in the framework.

ii) Available, but ABAPers need to make some code change to implement them and make them work. Example $filter, $orderby need to be implemented and custom logic has to be added.

The below table shows, which Query Option needs Coding effort and which can be used out of the box from SAP without any Code change.

OData Query Options Coding Required  What does it mean for ABAPers? 
$select No Field Projection
SELECT <FLDL1> <FLD2> from <DBTAB>
$count  No  SELECT COUNT(*) from <DBTAB> 
$expand  No  Tables join
SELECT * FROM <DBTAB1> LEFT OUTER JOIN <DBTAB2> on <FIELD> = <DBTAB2>.<FIELD> 
$format  No   
&sap-ds-debug=true  No  Navigating in the Service Document. This allows you to easily navigate in the document structure. 
orderby  Yes  SORT <ITAB> by <Entity Property> 
$top  Yes  SELECT <FLD1> <FLD2> UPTO N rows from <DBTAB> 
$skip  Yes   
$filter  Yes  Where clause
SELECT <FLD1> <FLD2> from <DBTAB> WHERE <FLD> = <VALUE>
$inlinecount  Yes   
$skiptoken  Yes   

Hopefully, the above table clarifies that if you want to use $filter or $orderby Query Option in your OData service, then you need to write code to handle it in your Data Provider Class Methods (like in GET_ENTITYSET etc).

If you want to use the $format or $count Query Options in the OData Service, then you can consume it directly without the need to write any custom code/logic.

Please check the below example image to see how the Filters passed from URI can be handled in the Data Provider Class Implementation. This is just one way. There might be better ways to handle the $filter query option.

Look how the $filter query option is passed from the front end (SAPUI5).

Now check the back end code, how the URI filter paramters are Read and handled in DPC method.

Some of the URI changes which happen when we include these Query Options in our OData Service are show in the below table.

OData Query String for GET Method

 DPC_EXT Method OData Query (URI)  DPC_EXT Method Key Parameter(s) 
_GET_ENTITYSET <ENTITYSET Path> = /sap/opu/odata/sap/<SERVICE NAME>/<ENTITYSET Name> Export:
ET_ENTITYSET
_GET_ENTITYSET  <ENTITYSET Path>?$format=json   
_GET_ENTITYSET  <ENTITYSET Path>?$filter=<Entity Property1> eq <value> and <Entity Property2> eq <value>  Import:
IT_FILTER_SELECT_OPTIONS and IV_FILTER_STRING
Export:
ET_ENTITYSET 
_GET_ENTITYSET  <ENTITYSET Path>?$orderby=<Entity Property1>,<Entity Property2>
OR
<ENTITYSET Path>?$orderby=<Entity Property1> desc,<Entity Property2> desc 
Import:
IT_ORDER
Export:
ET_ENTITYSET 
_GET_ENTITYSET  <ENTITYSET Path>?$search=<value>  Import:
IV_SEARCH_STRING
Export:
ET_ENTITYSET 
_GET_ENTITYSET  <ENTITYSET Path>?$top=<value>&$skip=<value>  Import:
IS_PAGING-TOP
Export:
ET_ENTITYSET 
_GET_ENTITY  <ENTITYSET Path>(<Entity Property>=’value’)
OR <ENTITYSET Path>(‘value‘) 
Import:
IT_KEY_TAB
Export:
ER_ENTITY 
_GET_ENTITY  In case if we had association and navigation between 2 entities  Import:
IT_NAVIGATION_PATH
Export:
ER_ENTITY 
_EXPANDED_ENTITY 

/sap/opu/odata/sap/<SERVICE NAME>/<ENTITYSET Name1>(<‘value’)/<ENTITYSET Name2
OR

/sap/opu/odata/sap/<SERVICE NAME>/<ENTITYSET Name1>(<‘value’) ?$expand=<ENTITYSET Name2>

 

Import:
IV_ENTITY_NAMEIV_ENTITY_SET_

NAMEIT_NAVIGATION_PATHIT_KEY_TABExport:
ER_ENTITYSET 

OData Query String: HTTP Status Code

Status Code Text   Cause 
200 OK The request is successfully executed by GET method
201  OK  The request is successfully executed by POST method 
203 OK  The request is successfully executed by POST method 
204  OK  The request is successfully executed by DELETE method 
400  Bad Request  The request could not be parsed successfully because of a syntactically or semantically incorrect URI. 
401  Unauthorized  Authentication is required and has not been provided. 
403  Forbidden  User does not have privileges to access the entity 
404  Record Not Found  The record does not exist for the given query. 
405  Method Not Allowed  A request cannot be used for this record. 
406  Not Acceptable  Self-explanatory 
500  Internal Server Error  Internal Error 
501  Not Implemented  Not Implemented 
502  Bad Gateway  Gateway issue 
503  Service Unavailable  Self-explanatory 

If you look at the above status codes closely, you would realise that all 200 series are Success Codes, 400 series are Frontend Client (SAPUI5) errors and 500 series are Server (Backend SAP) errors.

  • 2xx ->Success.
  • 4xx ->Client errors.
  • 5xx ->Server errors.

In addition, there are 1xx messages which are Information like continue, processing etc and 3xx codes are for Redirection messages like moved permanently, temporary redirect, see other etc. Also note that there are many more 2xx, 4xx, 5xx series status codes. The above table is not the exhaustive list, but it contains the most frequently used codes in SAPUI5 and OData developments.