ABAP Cloud - Änderungsbelege
Schauen wir uns einmal an, wie wir eigentlich im ABAP Cloud Umfeld Änderungsbelege für unsere Tabellen anlegen können und welchen Prozess wir dafür einhalten müssen. Dazu erweitern wir unsere RAP Anwendung.
Inhaltsverzeichnis
Das schauen wir uns in diesem Artikel an, wie wir die Änderungsbelege in ABAP Cloud verwenden und somit alle Änderungen an unserem RAP Objekt im System protokollieren.
Einleitung
Änderungsbelege sind ein zentraler Bestandteil des Standards, wenn es um die Nachvollziehbarkeit von Änderungen im System geht. Von Wirtschaftsprüfern wird dies oft in wichtigen Anwendungen verlangt, vor allem wenn es um buchungsrelevante Inhalte geht, die für eine Jahresabschlussprüfung relevant sind. In diesem Artikel erweitern wir unsere Sales App und wollen wichtige Inhalte in der Anwendung protokollieren.
Änderungsobjekt
Legen wir dazu im ersten Schritt ein Änderungsdokument an. Dazu auf das Paket im Project Explorer per Rechtsklick den Eintrag "New -> Other ABAP Repository Object" wählen. Dort suchen wir nach unserem Objekt für die Anlage.
Hier vergeben wir einen Namen und eine Beschreibung und lassen das Objekt erzeugen. Im Objekt müssen wir nun die Tabellen/Entitäten aufnehmen, für die ein Logging erfolgen soll. In diesem Fall verwenden wir unsere Sales Tabelle und die Seller, die wir später loggen wollen. Auf Ebene des Objekts wollen wir alle Feldänderungen loggen, solange es sich nicht um initiale Werte handelt. Wenn wir die Konfiguration vorgenommen haben, aktivieren wir das Objekt und die Klasse (ZCL_ZBS_CO_SALES_CHDO) wird für uns im Hintergrund generiert.
Im Änderungsobjekt können verschiede Einstellungen vorgenommen werden, wenn du die einzelnen Tabellen und Strukturen übernimmst.
- Log Multiple Changes - Bei der Generierung der API werden auch Parameter angelegt, um eine Tabelle von Änderungen zu übergeben. Somit muss die WRITE Methode nur einmal aufgerufen werden, um alle Änderungen in einem Änderungsdokument zu schreiben.
- Database Insertions - Sind die Kennzeichen nicht gesetzt, dann wird beim Einfügen nur ein allgemeiner Eintrag geschrieben (KEY) und nicht die spezifischen Inhalte der Daten.
- Database Deletions - Sind die Kennzeichen nicht gesetzt, dann wird beim Löschen nur ein allgemeiner Eintrag geschrieben (KEY) und nicht die spezifischen Inhalte der Daten.
Felder
Damit die Änderungen an bestimmten Feldern geloggt werden, müssen wir im ersten Schritt die Einstellungen auf diesen Feldern setzen. Dazu gehen wir zum Beispiel in die Tabelle ZBS_SASALE und navigieren auf das Datenelement ZBS_DEMO_SA_DATE. Bei der initialen Anlage haben wir vor allem auf Datenelemente gesetzt, da wir dort die Einstellung für das Logging (Change Document Logging) finden. Dazu den Bereich "Additional Properties" aufklappen.
Das Logging aktivieren wir nun in den folgenden Feldern der beiden Tabellen:
- ZBS_SASALE - Partner (PARTNERNUMBER), Sales Date (SALESDATE), Sales Volume (SALESVOLUME)
- ZBS_SASELLER - Seller (SELLERID), Quota (QUOTA)
Mit diesen Einstellungen werden nicht alle Felder der beiden Tabellen geloggt, sondern nur Felder mit den entsprechenden Einstellungen im Datenelement. Nicht immer soll die ganze Tabelle aufgezeichnet werden, sondern nur als wichtig definierte Felder.
Logging
Schauen wir uns in diesem Kapitel an, wie wir Änderungen in das Log schreiben können.
Generierte Klasse
Da wir nun unser Datenmodell vorbreitet haben, können wir die Protokollierung der Änderungen probieren. Dazu verwenden wir die Klasse ZCL_ZBS_CO_SALES_CHDO die als Standardimplementierung vom System generiert wurde. Schauen wir uns die Klasse einmal im Detail an, dann finden wir eine statische Methode WRITE, über die wir die Änderungen persistieren können.
Die Methode stellt verschiedene Einstellungen zur Verfügung, die wir beim Schreiben befüllen müssen, wie einen Schlüssel, Datum und Uhrzeit, sowie User. Weiterhin können wir die im Änderungsdokument definierten Strukturen wiederfinden. Dazu gibt es jeweils eine Old (O) und New (N) Übergabe, sowie den eigentlichen Änderungsindikator (Anlegen, Ändern oder Löschen).
Daten
Nun benötigen wir entsprechende Testdaten, um eine Änderung durchzuführen. In diesem Fall erzeugen wir einen synthetischen Datensatz, übernehmen die Informationen in den neuen Satz und passen einige Felder davon an. In echten Szenarien erhalten wir die Änderungen in unsere Logik oder sind mitten in der Verarbeitung mit RAP.
DATA old_sale TYPE zbs_sasale.
DATA new_sale TYPE zbs_sasale.
DATA object_id TYPE if_chdo_object_tools_rel=>ty_cdobjectv.
old_sale = VALUE #( client = sy-mandt
uuid = xco_cp=>uuid( )->value
partnernumber = '1000000000'
SalesDate = '20260101'
SalesVolume = '23000'
SalesCurrency = 'EUR'
SaleComment = `New year, new sales`
DifferenceAmount = '15000'
DifferenceCurrency = 'EUR' ).
new_sale = old_sale.
new_sale-SalesDate = '20260215'.
new_sale-SalesVolume = '22500'.
Dazu erzeugen wir auch noch eine Objekt-ID, die wir an die Methode übergeben können. In vielen Fällen handelt es sich um den eindeutigen Schlüssel von der Datenbank. Da der Mandant ebenfalls zum Schlüssel gehört, hängen wir alle Informationen aneinander.
object_id = old_sale-client && old_sale-uuid.
Sicherung
Zum Abschluss der Verarbeitung rufen wir die WRITE Methode mit unseren Daten auf. Wir übergeben die Objekt-ID und einige aktuelle Systemparameter. Ebenso befüllen wir die aktuellen Strukturen und setzen das Updatekennzeichen. In diesem Fall verwenden wir Update (U). Ebenso sind Insert (I) und Delete (D) möglich. Leider haben wir keine passenden Standardkonstanten gefunden, um die möglichen Kennzeichen ableiten zu können oder nicht hart kodiert zu übergeben. Weitere Informationen zu den Konstanten findest du in der verlinkten Dokumentation am Ende des Artikels.
zcl_zbs_co_sales_chdo=>write(
EXPORTING objectid = object_id
utime = cl_abap_context_info=>get_system_time( )
udate = cl_abap_context_info=>get_system_date( )
username = CONV #( cl_abap_context_info=>get_user_technical_name( ) )
o_zbs_sasale = old_sale
n_zbs_sasale = new_sale
upd_zbs_sasale = 'U'
IMPORTING changenumber = DATA(changenumber) ).
out->write( changenumber ).
COMMIT WORK.
Nach dem Aufruf führen wir einen COMMIT WORK durch und persistieren das Ergebnis auf der Datenbank. Vom System erhalten wir auch unsere Änderungsnummer.
Lesen
Um nun die Änderungen von der Datenbank lesen zu können, stehen uns verschieden Standardklassen zur Verfügung, die wir in diesem Kapitel verwenden wollen.
Logik
Die eigentliche Leselogik können wir mit der Klasse CL_CHDO_READ_TOOLS abbilden. Diese rufen wir mit unserer Objekt-ID auf, übergeben die Daten von unserem vorherigen Versuch und wollen so alle Datenbankänderungen lesen. Grundsätzlich stehen hier auch weitere Filter, wie Datum, Uhrzeit oder User zur Verfügung, um die Ergebnismenge passend einzuschränken.
cl_chdo_read_tools=>changedocument_read(
EXPORTING i_objectclass = zcl_zbs_co_sales_chdo=>objectclass
it_objectid = VALUE #( ( sign = 'I' option = 'EQ' low = object_id ) )
IMPORTING et_cdredadd_tab = DATA(db_changes) ).
out->write( db_changes ).
Berechtigung
Allerdings kann es passieren, dass wir keine Berechtigungen haben. In diesem Fall arbeiten wir auf dem ABAP Environment und habe keine Berechtigungen die Änderungsdokumente für unser eigenes Objekt zu lesen.
In diesem Fall müssen wir uns erst Berechtigungen zuweisen, wie wir es auch schon bei den Application Logs gemacht haben. Allerdings sind die Standard Berechtigungsobjekte wie S_SCD0 und S_SCD0_OBJ nicht freigegeben, auch wenn sie in der vorhandenen Logik abgefragt werden. Allerdings gibt es hier auch einen Exit, der vorher aufgerufen wird. Das System versucht von unserer generierten Klasse das Interface IF_CHDO_ENHANCEMENTS und die Methode AUTHORITY_CHECK auszuführen. Allerdings sind diese nicht implementiert. Daher implementieren wir die Methode in der Klasse ZCL_ZBS_CO_SALES_CHDO, um so Berechtigungen zu erhalten.
METHOD if_chdo_enhancements~authority_check.
rv_is_authorized = abap_true.
ENDMETHOD.
Grundsätzlich kannst du hier auch eigene Objekte und Berechtigungsprüfungen implementieren, die du dann wiederum in deinen Berechtigungen abbildest.
Änderungen
Führen wir dann noch einmal die Logik aus, sollten wir nun die Änderungen von der Datenbank erhalten. Die Tabelle ist relativ groß, enthält aber die verschiedenen Feldänderungen, wie im Screenshot dargestellt.
Vollständiges Beispiel
Das vollständige Beispiel findest du in GitHub im entsprechenden Paket für die Sales App. Die Änderungen aus diesem Artikel findest du in diesem Commit und kannst damit die Änderungen, plus die Zusatzinformationen, nachvollziehen.
Fazit
Grundsätzlich können Änderungen auch manuell oder über die eigentliche Tabellenänderung protokolliert werden, allerdings sollte zuerst einmal der Standard verwendet werden. Damit ist sichergestellt, dass über die Standardtools auch eine Auswertung der Belege und Änderungen erfolgen kann, auch durch Wirtschaftsprüfer.
