ABAP_to_the_Future

8
Business Object Processing Framework (BOPF)
<ls_changes>-node = zif_monster_c=>sc_node-monster_items.
<ls_changes>-change_mode = /bobf/if_frw_c=>sc_modify_create.
<ls_changes>-source_node =
zif_monster_c=>sc_node-monster_header.
<ls_changes>-association =
zif_monster_c=>sc_association-monster_header-monster_items.
<ls_changes>-source_key = lrs_monster_header->key.
<ls_changes>-key = lrs_monster_item->key.
<ls_changes>-data = lrs_monster_item.
ENDLOOP. "Monster Items
*---------------------------------------------------------------*
* Here We Go!
*---------------------------------------------------------------*
mo_bopf_pl_helper->change_data_in_memory(
EXPORTING it_changes_to_be_made = lt_changes_to_be_made
IMPORTING ef_data_in_memory_changed = ef_creation_successful ).
CHECK ef_creation_successful = abap_true.
mo_bopf_pl_helper->change_data_in_database( ).
ENDMETHOD. "Create Monster Record
Listing 8.19 Creating a New Monster Record
The methods that change the data in memory and in the database have been
moved into a helper class, because they’re fully generic and would be used by any
type of BOPF object. Speaking of these two data update methods, I’ve already forgotten
what the first method is all about. Hang on, it’s coming back…oh yes, it’s
all to do with memory.
The change_data_in_memory method implementation is shown in Listing 8.20;
this method is a wrapper for the MODIFY call to the BOPF service manager to
update the data in memory prior to actu ally saving the data. Because the error
handling code is always going to be the same, move it from the business object–
specific CREATE method and put it in the helper class methods, which are going to
be the same for every object. While you’re at it, also rename the externally visible
parameters and local variables of the helper methods to be a bit more meaningful.
METHOD change_data_in_memory.
* Local Variables
DATA: lo_actual_changes_made TYPE REF TO /bobf/if_tra_change,
lo_error_messages TYPE REF TO /bobf/if_frw_message.
338