ABAP - BOPF Custom Query

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.

BOBX

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.

Data interface

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.

Implementation

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.

Conclusion

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.