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 /sap/opu/odata/sap/<SERVICE NAME>/<ENTITYSET Name1>(<‘value’) ?$expand=<ENTITYSET Name2> |
Import: NAMEIT_NAVIGATION_PATHIT_KEY_TABExport: |
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.
