Class /IWBEP/CL_V4_ABS_DATA

This is the central abstract data provider class for OData version 4 (V4).

Interfaces:

All data provider method signatures follow the same pattern. They all have the two import parameters IO_REQUEST and IO_RESPONSE and one exception of type /IWBEP/CX_V4_GATEWAY. The request and response objects are different per method, though - there is a specific request and response interface per method.

IO_REQUEST

The import parameter IO_REQUEST can be used by a data provider to retrieve all relevant information for the specific method from the SAP Gateway Foundation framework.

Depending on the corresponding data provider method it contains methods such as the following:

GET_BUSI_DATA to retrieve entity data from the request
GET_ENTITY_SET to retrieve the entity set of the processed entity
GET_ENTITY_TYPE to retrieve the entity type

Most request interfaces have the method GET_TODOS. This method exports a structure with two sub-structures:

The PROCESS sub-structure contains a flag for every request option that the provider application might have to consider for the current operation (for example $filter, $select, $top or $expand).

For example, for method /IWBEP/IF_V4_DP_BASIC~READ_ENTITY the corresponding TODO structure returned by /IWBEP/IF_V4_REQU_BASIC_READ contains a flag PROCESS-SELECT, which is TRUE if the OData request contained a $select – that is, if the corresponding method /IWBEP/IF_V4_REQU_BASIC_READ~GET_SELECTED_PROPERTIES will return a not empty list of properties.
The RETURN sub-structure contains flags to inform the provider application what data it has to return for the current operation.

For example, for method /IWBEP/IF_V4_DP_BASIC~READ_ENTITY the corresponding TODO structure returned by /IWBEP/IF_V4_REQU_BASIC_READ contains a flag RETURN-BUSI_DATA, which is TRUE if business data is needed to build the OData response. This flag would be FALSE for a request like this:”…/TEA_busi/TEAMS/$count”, in which case RETURN-COUNT would be TRUE instead.

IO_RESPONSE

The import parameter IO_RESPONSE can be used by a data provider to provide all relevant information for the specific method back to the SAP Gateway Foundation framework.

Depending on the corresponding data provider method it contains methods such as the following:

SET_BUSI_DATA to return the data of an entity, for example.
SET_NOT_MODIFIED to be called instead of SET_BUSI_DATA if the conditionally requested entity has not changed, for example.

Most response interfaces have the method GET_MESSAGE_CONTAINER providing access to the message container and SET_IS_DONE.

SET_IS_DONE

With this method a data provider informs the SAP Gateway Foundation framework which request options it supports. The import structure with a flag for every request option has the same fields as the sub-structure PROCESS of the export structure in the corresponding IO_REQUEST GET_TODOS method. Calling this method is mandatory for a data provider.

This method ensures that a corresponding exception is thrown if a provider application has not implemented an OData feature of a request.

It ensures that no request is accidentally handled by the provider application for which it has not been designed.
It allows a provider application to inform the framework which feature it shall handle generically (such as paging).

Currently the SAP Gateway Foundation framework handles these request options generically:

$top
$skip
$select

Another scenario could be the following: A provider application has been developed using an older SAP Gateway Foundation version where a certain OData feature was not supported while in a newer SAP Gateway Foundation version it is supported. In this case that feature is ignored by the provider application but instead of a wrong result an error is returned to the client.

If a request option has not been considered by the data provider there are two options:

If possible the SAP Gateway Foundation framework handles the option generically, for example, for $select.
If the SAP Gateway Foundation framework cannot handle it generically it will trigger a NOT_IMPLEMENTED exception, for example for $filter.

An exception is the request option $count: here the application simply needs to use the SET_COUNT method (available for the object IO_RESPONSE).

Sample Code

DATA ls_todo_list TYPE /iwbep/if_v4_requ_basic_list=>ty_s_todo_list.
DATA ls_done_list TYPE /iwbep/if_v4_requ_basic_list=>ty_s_todo_process_list.
io_request->get_todos( IMPORTING es_todo_list = ls_todo_list ).
" $filter to be processed?
IF ls_todo_list-process-filter EQ abap_true.
   "handle the filter request option
[...]
   ls_done_list-filter = abap_true.
ENDIF.
io_response->set_is_done( ls_done_list ).

Class /IWBEP/CL_V4_ABS_DATA_PROVIDER