$filter : Clarifications

[Former Member]

Dear Friends,

This is regarding the $filter behaviour in Netweaver Gateway.

I wish to explain a simple use-case in order to get to the question.

(A)

My Entity , namely, SOPartner has the following fields

SOID (key)

PartnerID (key)

PartnerFunction (key)

PartnerFunctionText

(B)

In my Query function module, the query would be similar to "Get Me all Partners for a Given SalesOrder"  (~/SalesOrders('X3')/SOPartners)

(C)

Signature of the FM is as follows

CALL FUNCTION lv_rfc_name

EXPORTING

   iv_sohdr_guid

   iv_partnerfct

IMPORTING

   et_sopartners

Question:

1. I believe, the query with $filter similar to this -> ~/SalesOrders('X3')/SOPartners?$filter=PartnerFunction eq '14' ...can be catered by implementing the filter in the DPC_EXT class.

2. Ideally, PartnerFunction should be range-table in order to support queries like ...?

~/SalesOrders('X3')/SOPartners?$filter=PartnerFunction eq '14' and PartnerFunction eq '15'

3a. What happens to requirements where the $filter needs to be done on NON-INPUT fields? ( say, PartnerID? ).

3b. What is the idea behind "Requires Filter" flag for the EntitySet and "Filterable" flag for the property at the Entity Level?

4. Would there be an XSLT transformation available for filtering the result-set in the case of (3a)?

Many thanks for your time and patience

Cheers,

Suresh

[former_member184867 · Accepted solution]

1. What you have mentioned is correct. In the DPC_EXT you get all the information related to Filter and Navigation. You can write your own code to fetch the matching data.

2.OData version 2.0 does not support Range tables. You can pass multiple values for filter using 'or'(not and).

3a. Gateway Framework does not understand anything called non-input field. It is upto the developer to interpret the non-input field and react accordingly. If your function module does not accept a particular field passed via $filter, you need to either correct the function module or do some filtering on your own after the FM returns the result. 

3b. Requires Filter is a way to impose a mandatory filter condition while accessing the Collection. For example - You do not want a service to expose all the SalesOrders in the system. Because in this case it is like  select * without any where condition which leads to a huge volume of result. You want to force the user to use atleast some filter condition. In this case you can use 'Requires Filter'. The F1 help on the checkbox explains it in great detail.

Filterable on the other hand is applicable to property level. This is to define on which property one might apply a filter.

4. I did not get this question.. however gateway framework internally uses transformations but not for filtering the result set. GW framework expects the developer/RFC to send the filtered data in ABAP structure/internal table format.

[Former Member · Accepted solution]

Many thanks Atanu Malik

4) ..was an extension to the question 3a. Now that we understand , there is no "gateway runtime" transformations to support $filters ( it clearly is a systemquery option and not filtering the resultset once the FM is done with its execution ... also, makes a lot of sense ).

[former_member184867 · Accepted solution]

Exactly.

Gateway runtime transformations are only to transform your 'ABAP structure/internal table' to XML/JSON output. Here 'ABAP structure/internal table' are expected to contain only the desired result. any kind of filtering should be done before the result set is passed back to the framework. Gateway does not filter the data returned by your function module.custom logic.