ABAP - BOPF Manager
BOPF provides so-called managers, which you need for working with BOPF. We'll show you what they can and what they do.
Table of contents
As you've seen in recent BOPF articles, we've already used a few managers for outside access who have done various things for us. Today we want to show you what it is all about and for what you need which manager.
Functionality
The managers are used to manage the object and the data streams within the processing in the BOPF. For a brief explanation, the following graphic illustrates the scenario:
The transaction includes all the actions and changes that are to be performed on a BOPF model and can be thought of as a flow, in which individual actions are repeatedly carried out. For this the managers are needed.
Transactionmanager
Monitors and collects all changes to the model and forms a LUW to keep the data consistent. The manager takes care of the entire transaction and at the end writes the data back to the database. That's why he's the staple on everything.
Servicemanager
Always created for a specific BOPF model so the manager knows what data he manages. Provides actions to change the data, perform actions on the model, read and validate data. The actions of the manager are always on their own.
Service layer
Only affected by the service manager and unable to communicate with another service layer of another manager. After the action has been taken, processing returns to the transaction layer.
Example
In this specific case, you can read data only with the help of a service manager, but you need the transaction manager as soon as the data is to be changed concretely.
In the variant without transaction manager, the data is read by filter and via the QUERY method. As a result you get a table with the affected keys and can then use the RETRIEVE method to read in the data in the appropriate structure:
DATA:
lt_sel TYPE /bobf/t_frw_query_selparam,
lt_contracts TYPE ztest_t_contract.
DATA(lo_smgr) = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( zif_tst_bopf_c=>sc_bo_key ).
INSERT VALUE #(
attribute_name = 'CREDITOR'
sign = 'I'
option = 'EQ'
low = '0000123456'
) INTO TABLE lt_sel.
lo_smgr->query(
EXPORTING
iv_query_key = zif_tst_bopf_c=>sc_query-contract-select_by_elements
it_selection_parameters = lt_sel
IMPORTING
et_key = DATA(lt_key)
).
lo_smgr->retrieve(
EXPORTING
iv_node_key = zif_tst_bopf_c=>sc_node-contract
it_key = lt_key
IMPORTING
et_data = lt_contracts
).
In the variant with transaction manager, a table with changes is created (a contract with a rule) and changed by the MODIFY method. If there are no problems and errors, the transaction manager can take over the data and create it in the tables. In the case of an error, the CLEANUP method is called, which rolls back the steps since the last save.
DATA:
lt_mod TYPE /bobf/t_frw_modification.
DATA(ld_key) = /bobf/cl_frw_factory=>get_new_key( ).
" Contract data
DATA(ls_contract) = VALUE ztest_s_contract(
contract_id = '910'
creditor = '0000123456'
creation_date = '20191101'
).
INSERT VALUE #(
node = zif_tst_bopf_c=>sc_node-contract
change_mode = /bobf/if_frw_c=>sc_modify_create
data = REF #( ls_contract )
key = ld_key
) INTO TABLE lt_mod.
" Rules
DATA(ls_rule) = VALUE ztest_s_rules(
lnumber = 1
langu = 'D'
description = 'One rule for all'
).
INSERT VALUE #(
node = zif_tst_bopf_c=>sc_node-rules
change_mode = /bobf/if_frw_c=>sc_modify_create
data = REF #( ls_rule )
association = zif_tst_bopf_c=>sc_association-rules-to_parent
source_node = zif_tst_bopf_c=>sc_node-contract
source_key = ld_key
) INTO TABLE lt_mod.
DATA(lo_tmgr) = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).
DATA(lo_smgr) = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( zif_tst_bopf_c=>sc_bo_key ).
lo_smgr->modify(
EXPORTING
it_modification = lt_mod
IMPORTING
eo_change = DATA(lo_change)
eo_message = DATA(lo_msg)
).
IF lo_msg->check( ) = abap_false.
lo_tmgr->save(
IMPORTING
ev_rejected = DATA(ld_reject)
et_rejecting_bo_key = DATA(lt_keys)
).
ENDIF.
IF ld_reject = abap_true.
lo_tmgr->cleanup( ).
ENDIF.
Conclusion
The various managers and concepts are a central component of BOPF. Actions and changes to the data model should only be performed with their help, as this is the only way to preserve consistency within the data. In addition, the managers take a lot of work off of managing all the changes.
