ABAP_to_the_Future

Using BOPF to Write a DYNPRO-Style Program 8.2
<ls_parameter>-low
= id_monster_number.
* This builds a fully dynamic SQL Statement
CALL METHOD mo_service_manager->query
EXPORTING
iv_query_key = zif_monster_c=>sc_query-monster_header-select_
monster_by_attribute
it_selection_parameters = lt_parameters
IMPORTING
et_key
= lt_monster_keys.
* The return is always a table, but we have a unique key, so
* as someone once said THERE CAN BE ONLY ONE!
READ TABLE lt_monster_keys INDEX 1 ASSIGNING <ls_monster_keys>.
CHECK sy-subrc EQ 0.
rd_bopf_key = <ls_monster_keys>-key.
ENDMETHOD. "Get BOPF Key for Monster Number
Listing 8.3 Using a Custom Query to Turn a Monster Number into a Key
In Listing 8.3, you will probably reco gnize the method of creating a generic
parameter table ( LT_PARAMETERS), because you’ve been able to do that for some
time in order to call methods dynamically.
Put a breakpoint before the call to the standard BOPF query method MO_SERVICE_
MANGER->QUERY so that you can see exactly what is going on in the guts of the system.
You don’t have to code this yourself, which is why it isn’t in the code shown
here—but to get a complete picture you need to know what the standard SAP
code does in the background (a fully dynamic SQL statement is getting created).
Also do an ST05 trace while testing this method to see the database read. BOPF
automatically caches object records in a buffer (something you normally always
have to hand code yourself), but it’s important to be sure that when the database
is accessed nothing bad is happening.
As mentioned when talking about generating the database table to store the monster
header record, you need to create an index on MONSTER_NUMBER in the database
table (via SE11) at the time of the table’s creation. This is because, in a query
such as this, the dynamic SQL statement does a read based on MONSTER_NUMBER; if
there were no index on that field, then a full table scan would occur, which is poison
from a performance point of view.
299