Best practice how to deal with action parameters in RAP service

[maartenweijer]

Hi all,

In the past we used to develop quiet a lot of Z-programs. Our goal is that we replace Z-programs by RAP services and make them compliant with the ABAP Cloud development rules. This needs to be done on a S/4 HANA On Premise system. Current version is 2020, in a few months it should be 2023.

One of the questions that was raised was how to deal with parameters where we can have pretty much the same functionality as with select options in a Z-program, so including, excluding, between etc options for the values entered. I am aware that it might not be possible to achieve to exact same thing, but what would be the best approach to handle pretty much what we want?

An example is the below action:

  static action execute parameter ZSC_IO_ODS_TO_FNR_PARAM_INB  result [1] ZSC_WMS_STOCK_ABSTRACT_OUT;

Parameter ZSC_IO_ODS_TO_FNR_PARAM_INB   looks like this:

@EndUserText.label: 'Inbound parameters'
define abstract entity ZSC_IO_ODS_TO_FNR_PARAM_INB
{
    changes_x_days_back : abap.char( 1000 );
    supplier            : abap.char( 1000 );
    supplying_plant     : abap.char( 1000 );
    plant               : abap.char( 1000 );
    product            : abap.char( 1000 );
}

From Postman we would be able to call it like this:

*/sap/opu/odata/sap/ZSC_IO_ODS_TO_FNR_SB/execute?changes_x_days_back='5'&supplier=''& supplying_plant=''&plant='1003'&product=''

With the above structure we could easily pass multiple values of a field separating it by a semicolon.

In the action we would be able to take over the value of ‘plant’ like this (where the part how to deal with the semicolon and split into separate values would still need to be programmed). An application job is then started later. But what if we want that all stores are selected between 1003 - 1099, but not 1050 as an example? Then it becomes a bit more complex.

   LOOP AT keys ASSIGNING FIELD-SYMBOL(<lwa_keyfields>).

      IF <lwa_keyfields>-%param-plant IS NOT INITIAL.

        CLEAR: lwa_job_parameters,

               lwa_job_parameters_value,

               lta_job_parameters_value[].

        lwa_job_parameters-name = 'plant'.

        lwa_job_parameters_value-sign = 'I'.

        lwa_job_parameters_value-option = 'EQ'.

        lwa_job_parameters_value-low = <lwa_keyfields>-%param-plant.

        APPEND lwa_job_parameters_value TO lta_job_parameters_value.

        lwa_job_parameters-t_value = lta_job_parameters_value.

        APPEND lwa_job_parameters TO lta_job_parameters.

      ENDIF.

   ENDLOOP.

Is there a best practice how we can achieve what we want with the parameters where we have a lot of flexibility? 

Kind regards,

Maarten Weijer

[RalfHandl]

OData best practice for filtering results is using the $filter query option and express your desired result as a filter condition on the result structure. Assuming you result is basically an array of objects with a field Plant, you would pass

$filter=Plant eq '1003' or Plant eq '1004'

Worst practice is tunneling your own "query language" through a string parameter: you are in full control of what you do within the single-quoted string value and how to interpret the string as a "command" to do whatever you want - wipe the database, inject some code snippet, or treat it as an ABAP select-option to filter your result. This also means that you have full responsibility for validating and securely interpreting the content of your "command string".