cancel
Showing results for 
Search instead for 
Did you mean: 

$filter from UI5 - Filter Property name does not match model property

MarcoFreischlag
Advisor
Advisor
0 Kudos


Hello,

we have quite a strange requirement. Due to some drill-downs from other applications it's not possible to specify the sPath of the filter in the filter object properly --> this means the parameter we will hand over will not always match the properties defined in the Odata Model.

We thought of some kind of workaround which might can help us. I have defined a dummy "FILTER" property in the model, which will contain a separate  filter string

--> e.g.

l_filter_string = "$filter=substringof(%27Source_Loc%27,SOURCE_LOC)%20and%20substringof(%27Act_Loc%27,ACT_LOC)%20and%20substringof(%27Del_no%27,DEL_NR)%20and%20substringof(%27Product_ID%27,PRODNR)%20and%20substringof(%27TRACKING_ID%27,TRXID)%20and%20substringof(%27PO_NO%27,PO_NR)%20and%20substringof(%27REason%27,REASON_CODE)%20and%20substringof(UPSsad9999hflhasdfjh,FILTER)%20and%20ONTIME_STATUS%20eq%20%27NOT_OK";

when receiving the data in the /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITYSET I will evaluate the it_filter_select_options which will be used to contruct the select to the DB. Is there a possibility to somehow append and split this filter string in a way that we get the separate values in the /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITYSET I will evaluate the it_filter_select_options table.

at the moment I receive the filter string in the Property "FILTER"

this is what I want to split up and add to the it_filter_select_options table as separate properties:

Thanks for your help.

Regards Marco

Accepted Solutions (1)

Accepted Solutions (1)

kammaje_cis
Active Contributor
0 Kudos

Instead of passing a string, may be you can pass a json string, which can be parsed in ABAP into a table. And from tat table you may build a selection/range table.

Answers (3)

Answers (3)

MarcoFreischlag
Advisor
Advisor
0 Kudos

Thanks for your help!

in the first place I did not really understand your proposal using the json string. Did some tests yesterday and to my pleasure it worked out very well.

we'll compose the json string in our fiori app and pass it via a dummy property in the odata service to the backend - extract this information and use a simple transformation to generate our selection table.

1. our json which is passed within the filter property:

{

    "SELECTIONFIELDS": [

        {

            "FIELD_ID": "TRACKING ID CODE SET",

            "FIELD_TYPE": "8X",

            "SIGN": "I",

            "OPTION": "EQ",

            "LOW": "RES_ID"

        },

and so on.....

    ]

}

2. in the odata service call a simple transformation using the json filter string:

.....schnipp......

CALL TRANSFORMATION id SOURCE XML iv_filter_json

   RESULT selectionfields = lt_selectionfields.

.....schnapp......

3. output = "our" selection table

Thanks & Regards Marco

former_member183924
Active Participant
0 Kudos

didn't checked in detail, but what about io_tech_request_context->get_filter( )->get_filter_select_options( ) table? there you'll get not a string (didn't reproduced your example...)

EDIT: well I guess my proposal for checking filter in io_tech_request_context object is wrong, it might be not filled while using substringof statements....

--

Steffen

kammaje_cis
Active Contributor
0 Kudos

If you can explain the reason why you are not able to pass the actual property names, you might get a better solution.

MarcoFreischlag
Advisor
Advisor
0 Kudos

Hi Krishna,

we are going to call one Fiori-App / one OData-Service in two different ways: 1. via launcher App; 2. via drilldown from an analytical App / VDM. When we call the OData-Service from the VDM we get the Semantic Field Names and they are not the same as the field names on the database or the properties in the odata model (we are still looking for a possibility to read the assigned database table+field for the semantic fields)

Our requirements are the following:

- different VDMs call the same odataservice with a different set of fields e.g. in VDM the property is called Carrier and in the DB the field is CARRIER_NAME - so in the GET_ENTITYSET method we would also call some kinde of mapping function

- we need a dynamic approach to define the odata model. as we have a dynamic approach in our Application (customer can define different parameters for an object, can be different parameters for each object)

my idea was then just to re-use the parser which is already available to parse the $filter string and builds the filter selection table.

If this is not possible we would have to write our own parser.

Regards Marco

kammaje_cis
Active Contributor
0 Kudos

Marco,

Gateway supports 'Source Name's in addition to ABAP names.

Check the property interface. /IWBEP/IF_MGW_ODATA_PROPERTY. There is a method called /IWBEP/IF_MGW_ODATA_ITEM~SET_SOURCE_NAME . This name can be your external name. Once you set those, then, inside the data provider classes, you need to use the io_tech_request_context to get the technical names as Steffen mentioned below. But yes, then when you call the service it has to be in a uniform way. You always need to use the source names.

The parsing of a filter string to select options should to be part of the gateway framework. You might have to debug the /IWFND/* classes to get that.

Thanks

Krishna