ABAP - BOPF Custom Query
Do you need your own high-performance selection for your BOPF data? Then write your own query for it today.
In some cases you would like to announce interfaces to the outside and give your user the opportunity to perform frequently used queries again and again? There are custom queries that you can define in the BOPF. Today we show you an example of how you can implement something like this.
It all starts with defining the query in the data model. To do this, go back to transaction BOBX to expand the model and create your own query. You store a name and optionally a description and you can have the dictionary object names generated again.
We would like to enable the user to perform a custom and unique query and therefore provide some fields from our data model in a structure, the name of the structure we can also have generated by the system. Before we create the class, we need the complete structure.
Let’s take another look at the data interface of the method before we start implementing it. As you will recognize from some older articles, we already know many parameters. There is again the configuration data of the current node and objects for reading and changing data.
For your own query, the selection (IT_SELECTION_PARAMETERS), which contains the value restrictions for the individual fields, the query object (IO_QUERY) with which we can carry out standard queries, and the return fields ET_KEY and ET_DATA are particularly relevant. If something goes wrong, the message object (EO_MESSAGE) should of course be filled.
You now have to process the following steps: Break down the selection into the individual ranges and do a select on the database. From a performance perspective, you can of course also use a database view or CDS view, which would be a bit more powerful than the JOIN.
In the next step you transfer the data to the query object, which will now select and return the correct data based on the settings and keys.
DATA: lt_key TYPE /bobf/t_frw_key, lt_r_create TYPE RANGE OF crdat, lt_r_partner TYPE RANGE OF bu_partner. eo_message = /bobf/cl_frw_factory=>get_message( ). CLEAR: et_key, et_data. LOOP AT it_selection_parameters REFERENCE INTO DATA(lr_param). CASE lr_param->attribute_name. WHEN 'CREATION_DATE'. INSERT VALUE #( sign = lr_param->sign option = lr_param->option low = lr_param->low high = lr_param->high ) INTO TABLE lt_r_create. WHEN 'PARTNER'. INSERT VALUE #( sign = lr_param->sign option = lr_param->option low = lr_param->low high = lr_param->high ) INTO TABLE lt_r_partner. ENDCASE. ENDLOOP. SELECT c~db_key FROM ztest_d_contract AS c INNER JOIN ztest_d_partner AS p ON p~parent_key = c~db_key WHERE c~creation_date IN @lt_r_create AND p~partner IN @lt_r_partner INTO TABLE @lt_key. IF sy-subrc = 0. io_query->query( EXPORTING is_ctx = is_ctx it_filter_key = lt_key io_query_authorities = io_query_authorities is_query_options = is_query_options io_query = io_query io_read = io_read io_modify = io_modify iv_fill_data = iv_fill_data it_requested_attributes = it_requested_attributes IMPORTING eo_message = eo_message et_key = et_key es_query_info = es_query_info et_data = et_data ). ENDIF.
You see, for your own implementation of a query, not much is necessary and we have equipped you with the appropriate knowledge today. Try to implement your own query in your data model and test your knowledge.