ABAP - BOPF Manager
BOPF stellt sogenannte Manager zur Verfügung, die du für das Arbeiten mit BOPF benötigst. Wir zeigen dir heute was sie tun und können.
Inhaltsverzeichnis
Wie du bereits in den letzten BOPF Artikeln sehen konntest, haben wir für die Zugriffe von Außen bereits einige Manager verwendet, die für uns verschiedene Dinge erledigt haben. Heute möchten wir dir zeigen, was es damit auf sich hat und wofür man welchen Manager benötigt.
Funktionsweise
Die Manager dienen zur Verwaltung des Objekts und der Datenströme innerhalb der Verabeitung im BOPF. Zur kurzen Erklärung gibt es die folgende Grafik die das Szenario veranschaulicht:
Die Transaktion umfasst alle Aktionen und Änderungen die auf einem BOPF Modell durchgeführt werden sollen und kann sich als Fluss vorgestellt werden, bei dem immer wieder einzelne Aktionen durchgeführt werden. Dafür werden die Manager gebraucht.
Transaktionsmanager
Überwacht und sammelt alle Änderungen am Modell und bildet eine logische LUW, um die Daten konsistent zusammenzuhalten. Der Manager kümmert sich um die gesamte Transaktion und schreibt am Ende die Daten wieder zurück auf die Datenbank. Deshalb bildet er die Klammer über allem.
Servicemanager
Wird immer für ein spezifisches BOPF Modell erzeugt, damit der Manager weiß, welche Daten er verwaltet. Bietet Aktionen zur Anpassung der Daten, Ausführung von Aktionen auf dem Modell, liest und validiert Daten. Die Aktionen des Managers stehen immer für sich allein.
Serviceschicht
Wird nur durch den Servicemanager beeinflusst und kann nicht mit einer anderen Serviceschicht eines anderen Managers kommunizieren. Nach erfolgten Aktion, geht die Verarbeitung wieder zurück zur Transaktionsschicht.
Beispiel
Im konkreten Fall kannst du also Daten lesen nur mit Hilfe eines Servicemanagers, benötigst aber den Transaktionsmanager, sobald die Daten auch konkret verändert werden sollen.
Bei der Variante ohne Transaktionsmanager werden die Daten per Filter und über die QUERY Methode gelesen. Als Ergebnis erhältst du eine Tabelle mit den betroffenen Schlüsseln und kannst über die RETRIEVE Methode dann die Daten in der passenden Struktur einlesen:
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
).
Bei der Variante mit Transaktionsmanager wird eine Tabelle mit Änderungen erstellt (ein Vertrag mit einer Regel) und per MODIFY Methode übernommen. Wenn es keine Probleme gibt, dann kann der Transaktionsmanager die Daten übernehmen und in den Tabellen anlegen. Im Fehlerfall wird die CLEANUP Methode aufgerufen, die die Schritte seit dem letzten Sichern zurückrollt.
DATA:
lt_mod TYPE /bobf/t_frw_modification.
DATA(ld_key) = /bobf/cl_frw_factory=>get_new_key( ).
" Vertragsdaten
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.
" Regeln
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.
Fazit
Die verschiedenen Manager und Konzepte sind zentraler Bestandteil des BOPF. Aktionen und Änderungen auf dem Datenmodell sollten nur mit ihrer Hilfe durchgeführt werden, da nur so die Konsistenz innerhalb der Daten bewahrt werden kann. Außerdem nehmen die Manager dir einiges an Arbeit ab bei der Verwaltung aller Änderungen.
