ABAP_to_the_Future

Using BOPF to Write a DYNPRO-Style Program 8.2
CREATE DATA rdo_data
TYPE (ls_node_confguration-data_table_type).
ASSIGN rdo_data->* TO <lt_data>.
"Have to put the key in a table for some reason
APPEND INITIAL LINE TO lt_object_key ASSIGNING <ls_key>.
<ls_key>-key = id_object_key.
"Off we go!
mo_service_manager->retrieve_by_association(
EXPORTING iv_node_key = id_parent_node_type
it_key
= lt_object_key
iv_association = id_child_node_type
iv_fill_data = abap_true
IMPORTING eo_message = lo_message
et_data = <lt_data> ).
"Error Handling
CHECK lo_message IS BOUND.
"The check method makes sure there are actually error messages
"in the message table that came back
CHECK lo_message->check( ) EQ abap_true.
RAISE EXCEPTION TYPE /bobf/cx_dac
EXPORTING mo_message = lo_message.
ENDMETHOD. "Get Child Node Table
Listing 8.6 Getting the Item Table (Child Node Table)
All throughout the example code, you will notice lots of error handling, which
just throws the error up through the call stack and out of the model class so that
whatever program called the model class can deal with it. Usually, when the read
fails it’s because the calling program gave rubbish data, so the fault lies with the
caller; or perhaps the calling program wants the database read to fail, because it
may be trying to make sure it does not try to create two monsters with the same
number. The latter case is very important in BOPF, because the real primary key
is a GUID—so if your actual primary key is the monster number, then you have to
enforce uniqueness yourself.
In a DYNPRO-type program, the read on th e database is done at the start to get
the monster data to display or to change or (in the case of external numbering) to
make sure no existing monster has the number you’re about to create. In the case
of change, you now need to ensure that nobody else is also trying to change the
monster you’re interested in.
303