FROM BusinessPartners

WHERE CompanyName LIKE ‘S%‘

$select and $filter Benefits

 

The benefits of using $select are as follows:

• Less data is transferred
• Depending on the data structure in the SAP Business Suite backend system, less data might have to be consumed. For example, if the data is stored in a view comprising multiple database tables.

 

The benefits of using “$filter” are as follows:

• Less data is transferred
• Less data is retrieved from the SAP Business Suite backend system

 

Feed (GET_ENTITYSET), Filtering

The following code will implement the support to filter products by their category if the query option ?$filter=Category eq '<your category>' has been added to the request URI.

 

*-get filter
lt_filters = io_tech_request_context->get_filter( )
->get_filter_select_options( ).

*-get filter for ProductID
READ TABLE lt_filters
WITH TABLE KEY property 	= 'CATEGORY' INTO ls_filter.

IF sy-subrc EQ 0.
LOOP AT ls_filter-select_options INTO ls_so.
MOVE-CORRESPONDING ls_so TO ls_so_category.
INSERT ls_so_category INTO TABLE lt_so_category.
ENDLOOP.
ENDIF.

* Get data
CALL FUNCTION 'BAPI_EPM_PRODUCT_GET_LIST'
TABLES
headerdata         = lt_headerdata
selparamcategories = lt_so_category
return             = lt_return.

Filter statements used by the client in the request URL are provided by the Gateway framework in the form of ABAP select options.

 

If RFC function modules are called, select options should be filled in order to minimize the data that is retrieved.

 

Filtering for properties where a BAPI does not offer a select parameter have to be handled separately as explained next.

 

Feed (GET_ENTITYSET), Filtering data after retrieval

In OData it is usually expected that data can be filtered for all properties of an entity set.

 

Existing SAP interfaces such as BAPIs or RFCs however do not support filtering for all properties of an interface.

 

Performance can still be optimized by filtering the result set before sending it back to the client.

 

…
Read data with select options provided via $filter
…
*-get filter for Price
READ TABLE lt_filters
WITH TABLE KEY property = 'PRICE' INTO ls_filter.
IF sy-subrc EQ 0.
LOOP AT ls_filter-select_options INTO ls_so.
MOVE-CORRESPONDING ls_so TO ls_price.
INSERT ls_price INTO TABLE lt_price.
ENDLOOP.
ENDIF.
* remove data returned by BAPI that does not match
* the additional filter criteria for price
DELETE et_entityset where price not IN lt_price.

Query Options $top And $inlinecount

Limiting the result set to only the first 6 entries is achieved in OData by using the statement $top=6.

 

The number of entries that the list contains in total is important. In the case of client-side paging, this value is retrieved by using the statement $inlinecount=allpages.

 

Together with the result set the number of all values is provided to the client.

 

 

Query Options $top and $inlinecount and $skip — Example 1

When navigating to the second page we have to leverage the $skip parameter. Again, the client retrieves only 6 items ($top) but skips the first 6 and starts with Business Partner number 7.

 

 

The difference between $count and $inlinecount is as follows: The result of $count is a resource that can be retrieved using the following URI: /sap/opu/odata/sap/ZCD204_EPM_DEMO_SRV/BusinessPartners/$count

 

If instead of $inlinecount, $count is used, you would have to perform two HTTP calls and therefore two server round-trips. Using $inlinecount allows you to retrieve the total number of entries in one single HTTP call. This means there is no need to perform a separate HTTP call by using the query option $count, which would cause an additional roundtrip.

 

Query Options $top and $inlinecount and $skip — Example 2

In the case of client side paging, where the client controls how many values are retrieved, there can be issues when the client tries to retrieve a large amount of data from the backend.