ABAP - BOPF Queries
After creating the test data, we had some minor difficulties reading the data. Today we will show you the solution for this problem.
Table of contents
In this article, we'll look at how we can easily read data. Because we have already seen in the last article, there are only simple accesses via the key, but this must first be determined.
Query
There are queries that we can create and use. The definition of a query takes place in transaction BOBX, where we also create the model. With a right-click on queries, we can define a new query.
Without much effort, we can create two basic queries that the system already provides. SELECT_ALL finds all keys from the BOPF and returns them without restrictions. SELECT_BY_ELEMENT adopts the selection criteria and limits the number of keys. For this, the query requires a structure or field to be filtered.
From experience, we can tell you that depositing the real table is the best way. Although the transient fields from the data are missing, the keys for PARENT can also be queried if, for example, you enter the search via a lower entity.
BOBT
After definition and activation in the model, the two new queries are also available in the test environment. These can now be used for the selection. If you just want to read all elements from the tables, the query SELECT_ALL is sufficient.
If you want to restrict the elements, you will get a popup again. This time, all fields from the structure are available for input, which should make it easier for you to narrow down the data. Now you can also restrict via the vendor.
Technical solution
Surely you are wondering how to perform the query technically? In this section, we'll show you a code example of how to apply the example above.
In the first step, you need an instance of the service manager to perform an action on the BOPF. Then you fill the selection table with the restrictions and in the last step transfer everything to the QUERY method of the service manager. You get back a message object that you should still check for errors, as well as the key table if entries are included. Since you only received the keys, you still need to request the data via the RETRIEVE method.
DATA:
lt_sel TYPE /bobf/t_frw_query_selparam,
lt_data TYPE ztest_t_contract.
" Service Manager Instance
DATA(lo_smgr) = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( zif_tst_bopf_c=>sc_bo_key ).
" Fill selection
APPEND VALUE #(
attribute_name = zif_tst_bopf_c=>sc_node_attribute-contract-creditor
sign = 'I'
option = 'EQ'
low = '0000123456'
) TO lt_sel.
" Get the keys
lo_smgr->query(
EXPORTING
iv_query_key = zif_tst_bopf_c=>sc_query-contract-select_by_elements
it_selection_parameters = lt_sel
IMPORTING
eo_message = DATA(lo_msg_query)
et_key = DATA(lt_key)
).
" Validate errors
IF lo_msg_query->check( ) = abap_true OR lt_key IS INITIAL.
RETURN.
ENDIF.
" Read data
lo_smgr->retrieve(
EXPORTING
iv_node_key = zif_tst_bopf_c=>sc_node-contract
it_key = lt_key
IMPORTING
eo_message = DATA(lo_msg)
et_data = lt_data
).
Hint: As you probably noticed, we use the constant interface of the BOPF model for the creation of the service manager, but also for the accesses. Never store the values as literals in these places, as these could change when the interface is regenerated.
Conclusion
Using the queries, you can now access the data and limit the return quantities. From here, the data model can already be used for evaluations. You see, with the standard queries already many things are possible and you do not always need your own logics.
